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