Interoperability in the Real World....

Over the past year, I have come to understand and appreciate the value, the importance, and the necessity of tooling in achieving health interoperability objectives. On the one hand, many would suggest that this is obvious, for we cannot build systems and deploy solutions without tools. On the other hand, I would suggest that this is profound. Here's why.

The Real World.
When I speak to folks that are working in the trenches -- the ones that have production systems that are in use and deployed, and are struggling with what new parts to buy, how to choose, and how to make those bits work with what they already have -- it becomes clear that it is all about the tooling. We can discuss the value of standards, which most would agree are good things. We identify target technologies which are the future and hold tremendous promise. We even talk about integration strategies -- the ones that will minimize impacts to the organizations while maximizing value and ROI.

I am coming to realize, though, that the above isn't the real world. [Just to be clear, I'm not denegrading any of the above, and will get into the case for these things momentarily]. What I mean by that is that those of us who need to make IT work in the real world can only do so with pieces that exist. Architecture is important. Strategic direction is important. Standards are important. Having a migration plan is important. Sequencing is important. Ultimately, a whole lot of things are important, but if you cannot touch it, feel it, use it, and deploy it, it isn't real

Standards in the Real World
Standards that go unused are un-useful. Those of you who know me know that I am passionate about standards and their incredible importance in helping Health IT achieve its promise to healthcare organizations the world over. That said, one of the core tenets behind good and useful standards work is the drive to have those standards implemented.

There has been a lot of really good standards work to emerge over the past few years in the Health IT space. One of the challenges that I believe the industry as a whole is facing is that of adoption. The vendors with whom I speak follow standards very closely, but ultimately they must make hard business decisions in terms of where to invest their product development budget, and standards are not always the top of the list. Why not? Us!

As consumers, the responsibility is ours to demand of our suppliers those things that we want and care about. If we say standards are important but continue to make purchasing decisions absent any consideration of which and what standards are supported, the fault is our own. Vendors will provide what the marketplace demands. How does this affect the users, the integrators, and the folks in the trenches? Here's how.

When we pick a new, sexy product that has the bells-and-whistles but not the core architecture, the standards, the interoperability "baked in", the onus falls on the poor systems administrator to make the things fit. The result are internal teams that are asked to perform heroic "one-offs" to glue two things together that were never intended to fit. The integration is brittle, inconsistent, and expensive. Matters are even worse when you consider maintenance releases.

So what about the vendors? Why not just make those investments themselves as a competitive advantage. Well, two reasons surface very quickly. First, if purchasers are not incenting their decisions based upon these factors, then it is pretty reasonable to assume that the competitive advantage is not there. Secondly, infrastructure is expensive. VERY expensive. To get these bits right takes a huge investment of time, cost, resources. There are definitely paybacks (such as improved time-to-market and improved ability to fit into a customer environment), but making the business case for those investments can be very problemmatic.

Moreover, infrastructure has a sustainment cost, particularly as core technologies continue to evolve and as new players enter the market. To many vendors, the business case simply isn't there (or hasn't been effectively made) to invest in the newer standards.

Enter Open Source Software
After a tremendous amount of mentoring and hand-holding over the past year or two (special thanks to Skip McGaughey for getting me straight), I have come to understand that open source software can play an instrumental role in filling this void. How? Open source software provides a platform and a cooperation allowing for this expensive infrastructure to be built via co-investment, where all the players with the need share the burden (and the spoils). The end result is an infrastructure that can support the standards the community cares about, source code that vendors can use (for free!), and most importantly, an engagement model allowing allies and competitors to collaborate on the common bits on which they are not competing.

For example, through open source, HL7 tooling is already available (with more coming soon) that can be picked up and used with no IP [intellectual property] encumbrances. It can be used for free. It can be extended for free. It can be made for-profit without patent violation. Vendors can use it. Hospital systems can use it.

When most folks think "open source", software like Linux comes to mind, or licensing such as GNU, which are not commercially friendly. The key to success in our industry is to marry the commercial and free worlds, allowing vendors to share investments but also allowing them to make a living. Caveat emptor. The code is there to use, however it adds value.

Why do we care? As consumers, we want these standards. We need our systems to interoperate. What better way to get vendors on board than to contribute to a core that the vendors can then use. They can contribute to. Contribution doesn't necessarily mean money. It may mean time -- the time of the poor guy or gal that is glueing systems together today -- only allowing that investment to solve multiple challenges instead of just the problem-du-jour.

So, what do we do?
My recommendation is that there are a few steps that organizations should consider as they embark upon major HIT initiatives:

1) Create a roadmap. You can't get to your target objective without having a sense for where that is. While the 3-5 year vision is not attainable today, there needs to be a path to get there. That path must be paved with tools and technologies that exist, particularly for those objectives you hope to achieve in the next 18 months. Either you're using something that is out there or you're building it yourself.

2) Change your purchasing behavior. If there are no ties between your purse-strings and your plan, you have no hope of incenting the marketplace to meet your needs. While no one organization can do this on its own, collaborating withing the community to drive change is viable and achievable.

3) Engage in Standards. It is really easy to take a back seat and bash the standards for not being useful, and not meeting your needs. It is far harder to be part of the solution. The hidden secret is that the way to influence standards is to show up, and a few committed people can move mountains, particularly when they are trying to achieve a real, tangible objective.

4) Consider Open Source. Open source software is not the be-all, end-all, but there are organizations (such as Open Health Tools) that have the structure to allow for community engagement and vendor participation. These efforts will create shared health IT assets that are real, that can be used, that can be implemented, and that can be deployed.

Until next time...

- Ken

Being Conformant...

Over the past several months, I have come to a much deeper understanding around issues of conformance. Simply put, conformance is the ability to make an assertion as to some functional capability which can be rigorously and authoritatively tested and proven. Conformance is a term often bantered about when talking about standards, but I believe that it is subject to widespread variation when it comes to interpretation. Perhaps my our recent journeys in the areas of conformance can shed a little bit of insight.

Asserting Conformance

At a base level, it seems desirable (or even advantageous) to use standards to be able to say 'we use standard X', therefore anytime we need to interface we will be relying upon X. This sounds reasonable. Why, then, doesn't it work?

Most standards define qualities, attributes, or criteria which constitute conformance criteria. The intention behind these processes is to provide the foundation against which the standard may be tested, ultimately determining the compliance of any given implementation in adequately addressing the standard in question. Product vendors and organizations alike then make conformance assertions, effectively public statements declaring which standards and which versions are being supported.

This means that the standard is real, is being used, and has been implemented. The implementation has considered those qualities expressed in the conformance criteria and can adequately and sufficiently address all of the expressed criteria appropriately. Further, if the assertions are accurate, the implementation can be subjected to formal testing (either internally or by a third-party) and the implementation verified to conform. How then can all of these steps still result in non-interoperable systems, especially when the standards are being specifically developed to solve interoperability challenges?

Defining Conformance

One of the reasons it doesn't work explains the very mission behind IHE (Integrating the Healthcare Enterprise). IHE has identified, and rightly so, that many of the standards in place today lack the rigor necessary to allow for strong interoperability and conformance. In other words, it is all too easy for two different products or organizations to both be using the same version of the same standard yet not be able to interoperate. This "wiggle room" is a manifestation of ambiguity within the standard, and creates inherent challenges when interoperating.

There are many potential shortcomings that get highlighted when specifications are examined closely. In some cases, underspecification is the problem (where multiple ways to do the same thing may exist). In other cases, standards fall short by not enumerating how the standard applies to a particular situation or use case, rendering it ambiguous at best or unusable at worst.

So, through means such as profiling as IHE does, don't we have the tools to specify the ambiguous portions and result in plug-and-play interoperability, and achieve our objective of strong conformance? Not exactly.

While IHE does an admirable job of nailing-down ambiguity and creating profiles to support designated use cases, their interoperability and ultimately conformacne assertions are based upon their fitness to support the specified use case. While asserting conformance to an IHE profile, one can have a reasonable expectation of interoperability support for the use cases supported by that profile. The real challenge lies when your business need deviates from the IHE use case. Conformance outside of those use cases is no more rigorous than the base standard.

So, does IHE have it wrong? Not at all. IHE is performance a very valuable service within the industry, and is raising the interoperability bar. That said, IHE alone isn't the entire story.

Engineering Conformance

After working with this issue for several months, I have gained a new appreciation for the complexities of conformance. First off, we must consider conformance along a number of axes: technical, functional, and semantic/informational. [Actually, one can even make a strong case for a business-context as well, and we'll touch on this gently in the section below].

Technical level conformance is perhaps the easiest to understand. Usually tied to a physical or software infrastructure, such as a hardware platform or a software development or operating environment. Technical interoperability is not healthcare's biggest challenges. Far bigger issues lie ahead.

HSSP has based functional conformance around the behavior expected and performed in an interoperability setting. Functional conformance is about two interacting things doing what we expect of them. In defining functional conformance, we are expressing formally and rigorous how a system/component/service will behave. This includes its inputs, its outputs, expected behaviours, and so on. Behaviours that are not specified are inherently not supported. The converse, however, is not true, and that is where the power lies.

Semantic conformance, or information conformance, specifies the information content, construct, and formalism needed for interoperablity. By specifying information content, we can then make conformance assertions that relate to that information (and also test those assertions). For instance, if we indicate that a valid value range for a Systolic blood pressure reading cannot exceed 500, then we can verify that assertion by sending a value of 600 and expect to receive an error message indicating that a value constraint has been violated. Similar assertions can be made around terminology-based content, inter-concept relationships, and so on. In effect, this approach allows us tremendous flexibility to define and support information assertions.

Now we have the building blocks, but we're still missing something. For standards to be successful, they must provide for rigor but also be useful. Part of that utility stems from the ability to be flexible, extensible, and adaptable to a variety of needs and conditions, not all of which can be predetermined as the standard is being developed. The notion of conformance profiles is not new, but this is perhaps a bit of a different approach to them.

In order to engineer conformance, we must consider each of the interoperability perspectives independently, providing a mechansm for rigorous specification, supporting multiple use-cases, supporting extensibility within the specification, but without allowing such ambiguity so as to render conformance pointless. Let me assert that the following approach affords us that opportunity: rigorous conformance while supporting extensibility and flexibility. What would constitute such a profile? Consider the following:

A conformance profile tagged with sufficient metadata so as to be expressable and discoverable. Each profile would have at a minimum an identity, a name, and a version, allowing a vendor or user to assert conformance against it and a consumer to be able to look-it-up and verify it and its rules. A conformance profile is comprised of a functional profile, a semantic profile, and used within an interoperablity paradigm.

A functional profile that identifies the subset of the functions within the standard that are supported by that profile. In other words, the standard itself must specify behaviours so as to clearly define what is permissable within the scope of the standard. Not every function is appropriate in the context of any given profile. Within a particular conformance profile, the functional profile will enumerate exactly which functions (or which portions of those functions) apply. A functional profile allows for significant customization or localization of a standard, but it does not technically extend the standard. In other words, one cannot add new functions not previously supported in a profile. Why? What would happen if we add a function foobar within a profile, and then try to invoke it on another system. Nobody but us knows about foobar. That doesn't mean that a vendor can't do it. It means that those added functions do not fulfil conformance assertions within the standard.

A semantic profile defines the universe of potential information content, the formalism for expression, and enumerates specific information constructs that are supported within that profile. For example, a semantic profile may indicate that valid values are HL7 Version 3 RIM components, expressed in RIM terminologies. The notion of semantic signifiers (also known as "templates", "archetypes", and by a host of other names) are enumerated instances that are supported. For example, a Health Summary semantic profile may include may include semantic signifiers defining a Patient History, Patient Demographics, Vital Signs, Allergies, Medication List, and so on. Each of these signifiers would be formally and rigorously expressed, calling out where terminologies are used and what the valid values and value ranges contain.

An interoperability paradigm effectively allows one to express a context in which a conformance profile applies. For instance, an interoperability paradigm may include technical platform details, business agreements, pre-conditions (such as assumptions patient consent, authorization, authentication), and whatever other details are pertinent to the interoperability context. In effect, the interoperability paradigm is a generalization of the IHE use cases that drive their profiling activity.

What have we learned?

The analysis that led to the above concepts has yielded a number of interesting and counterintuitive discoveries. This journey embarked when we discussed what conformance meant to a generic "Retrieve, Locate, Update" service. What was found, very quickly, was that making conformance assertions about something so generic was effectively meaningless, and did not provide value when asserting, testing, or proving interoperability. The means of expression was simply too juvenile. As the thinking evolved and the understanding evolved with it, we came to the realization that the above building blocks provided tremendous flexibility and specificity. WIthin the context of any given profile, things could be strongly, formally, and rigorously defined. Underpinning the specification, however, was a core set of concepts that were more generally applicable. By incorporating a profiling mechanism as part of the base specification and including the dimensions above, new communities and use cases could be easily served within the core specification suite without compromising rigor.

Roles still exist and are desperately needed to identify profiles, to formalize them, and ultimately to test them and implementation's conformance to them. Between professional societies, standards groups, regulatory bodies, IHE, and other organizations, we believe these tools can be applied to address a significant number of challenges not yet thought of. This approach is not a silver bullet, but it provides a depth desperately needed to understand and address many of healthcare's challenges.

Until next time...

- Ken

Creating a Culture of Success

The Healthcare Services Specification Project (HSSP -- http://hssp.wikispaces.com ) celebrated its unofficial one-year anniversary last week. One year ago, the HL7-side of the HSSP standards collaboration was formally chartered. We have learned a bunch of things during the course of the year, and made our fair share of mistakes.

Ultimately, if HSSP is to achieve its goal of creating viable healthcare SOA standards that are to realize marketplace acceptance, the group creating them must be successful. The energy around this activity has been growing throughout the course of the year, and more activities are presently in the "channel" than we ever imagined would be -- presently six active HL7 functional model specifications under development, and two OMG-issued RFPs to industry soliciting technical specifications based upon already balloted HL7 work.

The following are some of the cultural lessons-learned that I have observed within the group during the past year. I do not believe that we're doing everything right by any stretch of the imagination. That said, I think we are doing a lot of things right.

1) Don't be afraid to fail. The adage "fail early and often" couldn't be truer. We've made a bunch of mistakes along the way. That said, HSSP as a group has been pretty fearless. Ultimately, people are very forgiving folks. We screwed up getting our communications channels right (mixing two mail lists was a horrific failure). We started a little to ambitiously. We didn't have sufficient materials out there for folks to learn and understand what we were up to. The practical guidance to developers trying to solve business problems was lacking.

But we learned. We learned and improved. Problems were corrected. We persevered, and we listened. That listening has made us a better group, and we've done a good job of documenting what we do, improving as we go, and not making the same mistakes twice.

2) Keep the pressure on. Deadlines themselves are good things, not bad things. When we started, we tried to keep "Uncomfortably aggressive" timelines. Nothing so ridiculous that it wasn't plausible, but nothing that would be "comfortable" either. The result is that HSSP continued to push and get things done. Every deadline slipped. That said, I don't believe any have slipped more that one calendar-quarter. Not bad for a project with zero budget and zero dedicated resources.

3) Document your process, and seek continuous improvement. HSSP follows a formally documented process. That process started out with a lot of holes, and still has plenty. Many have been filled in. Inherent in the process, the group, and the culture has been engrained the attitude to do things better, capture those lessons, document them, and then follow our process.

Without a documented process, activities cannot be repeated. Perhaps most importantly, having the process documented means that newcomers can understand what we are doing. A colleague and HL7 attendee whom I very much appreciate and respect said of HSSP "This is [one of] the only groups where you can come into the room and understand what they are doing." The byproduct of having process rigor and operating in the daylight.

4) Let subgroups work autonomously. HSSP created a model where each subgroup must conform to the overall methodology and processes of the project, but they work autonomously. This autonomy allows each effort to establish their own dates, develop their work, meet and discuss, and ultimately custom-tailor to their needs. That said, the overall process ensures sufficient public vetting, quality assurance, and confidence that the work is consistent with the scope of HSSP activities and aligned with parallel work streams.

The upshot is that an increasing number of new work threads are emerging with new communities taking on the responsibilities. HSSP has been able to scale-out and actively collaborate with many HL7 committees, and is even entertaining discussions with newly-interested external standards bodies.

Perhaps most important, this autonomy has created diverse leadership opportunities, where anyone willing to do heavy-lifting can participate and realize business value and recognition for doing so.

5) Keep a relentless focus on business value. Many standards activities are about creating standards, and lose sight of the fact that standards must solve some problem to be useful. HSSP welcomes any point of view, but ultimately makes decisions based upon business value and resource contribution and interest. By aligning standards-development with people's day-jobs, the notion of "volunteers" largely goes away: working on the standard is working on the "day-job."

HSSP since its inception has been constantly striving to connect these two worlds, and has been enjoying slow but steady growth as a result. The business world and the standards world do not need to be in conflict. Recognizing that business needs and interests are strong motivators, there are many work threads that are synergistic to both. Striving to remain in that space is hard, but rewarding.

6) Maintain a high-trust environment. I met Jim Demetriades (Biomedical Engineer and Healthcare Architect, Veterans Health Administration) many years ago and learned a lot from him. One of the most important lessons was the impact of a low-trust vs. a high-trust environment.

In a low-trust environment, we must take on activities ourselves because if you don't, the original intent of your work, how it fits, its success, and progress can be stymied by the world at large. Collaborating is largely risk-mitigation. Ultimately, ownership is of paramount importance, for it provides the enabler to achieve your objectives.

A high-trust environment is very different. It is predicated on the fact that others are focused on their areas of interest, which may-or-may-not intersect with yours. In a high trust environment, you work in the sunlight and expect criticism and feedback that is constructive. Some is, and some isn't, but you learn from each data point on the way.

HSSP has created a culture and in my opinion a high-trust environment. There can be (and are) many very heated, juicy arguments in a high trust environment. That said, the arguments are always technically focused and about improving the work product, and almost always end with the opponents heading off together to lunch or to a watering hole. Built on mutual respect, when each of us expects and demands this from each other we can all be successful together and not at each others' expense.

7) Have fun. I think it was particularly fitting when HSSP concluded its business activities last week in passing a guiding principle that stated, very basically...

...No group would have more fun doing meaningful work than HSSP...

Hard work can be fun, and fun does not have to be irrelevant.



Until next time....

- Ken

Asserting Interoperability

There are an increasing number of activities today trying to address and/or measure interoperability. Organizations such as HITSP (in the US) are defining standards that will be the support structure for interoperability. Groups such as IHE are developing interoperability profiles to tighten areas of ambiguity en route to stronger interoperability. HL7's EHR group has produced materials to guide consumers through the myriad of infrastructure en route to interoperability.

As we have been progressing with the HSSP activities, our work of late has been drilling-down into interoperability, considering what is needed to interoperate. As I think about my earlier posts, and given that some time has passed since my last posting, I have come to appreciate the importance of the multitude of perspectives that must each be considered to be interoperable. Let's delve...

1) Semantics. "The Holy Grail.' At the point we are able to meaningfully exchange business-pertinent healthcare information, at one level we will have achieved success. The challenge is to maintain sufficient information richness and sufficient context for the information to be meaningful and useful to the consumer.

2) Computational Mechanism. If we have the richest business semantics and we are exchanging that information on paper and via fax, have we achieved the potential of EHR's and interoperability? Probably not. While a purist view only requires information exchange, the format matters. Anyone who has travelled and forgotten a power adapter appreciates the difference. How things plug together matters, and the better the infrastructure we put into place to allow systems to interoperate (such as SOA services), the more flexible our organizations are to adapt to changing needs and technologies.

3) Business and Context (credit to HL7 EHR). Maintaining contextual relevance is important to interoperability. Receiving information items such as systolic and diastolic values does not convey enough information for that data to be useful. The same is true with business context. Patient self-entered information may be less reliable than that entered by a healthcare professional. Maybe not. (For example, what if we're talking about a family history). Understanding metadata and contextual information has relevance as we seek to build interoperability bridges across organizations and enterprises.

So, what do we do?
Two very important pieces must converge to address these matters and be able to assert and test conformance. HSSP work already includes the notion of conformance profiles, which comprise many of the datapoints above. By making conformance assertions that address the semantics and the functions (e.g., the computational mechanism), we are taking a more comprehensive view of interoperability.

Alan Honey (Kaiser-Permanente) had a great realization on a teleconference today that I believe ties things together nicely. If we consider the idea of an implementation context, many of these issues come into focus. Including this concept into our perspective of conformance propels this notion forward. We can elect to have an implementation context bringing together the business perspective, policies, and relevant environmental context in play within an organization. We can do the same for a RHIO or National context.

Integrating the notion of a "domain" into comptuational specifications is well established. (This approach was taken in the OMG Person ID Service -- PIDS -- many years ago). Perhaps I'm just now realizing the potential of this very simple idea as it adds a dimension to conformance and interoperability assertions.

What about Localization?
Not everything needs to be standardized and interoperable. Frankly, that is one of the strengths of this approach. In our conformance profiles, we can make assertions about what information, what behaviors, and what contextual elements can interoperate. The "rest" comes along for the ride. So long as we can precisely describe what is and is not interoperable, we have the freedom to extend specifications to include what we need and still be useful.

Many criticize HL7 v2 messaging because of the lack of interoperability that resulted from ambiguity in "Z" segments. On the contrary, HL7 V2 was and remains wildly successful at allowing organizations to interchange information and interoperate. The problem is not in the wire protocol, it is in the conformance assertions.

We have an opportunity now to benefit from the lessons learned from the past, taking the utility and flexibility offered by "Z" segments and tempering them with strong enough conformance so as to give confidence to consumers that things will interoperate within an interoperability profile. The challenge is on us to ensure that the interoperable portion is sufficient.