I am delighted to report that the Clinical Information Modeling Initiative (CIMI) is a small group of volunteers led by Stan Huff that is working to consolidate the detailed clinical models of various groups in a way that could be adapted to meet the needs of standards groups in all those areas. Bless their hearts, they have decided an approach that is short on hoopla and focused on actually developing a sizable set of models ASAP. They are working with a minimum set of governance without worrying about the specific requirements of any specific system, technology or standards organization. They are convinced that if they produce valuable, open intellectual property and make it easy to adopt that usage will follow. I personally believe that the ultimate value of their work will extend beyond information interchange to include describing data for clinical decision support rules, sharing metadata used to create data entry templates or reports for specific clinical concepts.

These guys are so focused on results that they don’t even have a Web site yet. They did take some time away from modeling to develop a joint description of their principles and approach. Here is that statement in its entirety.

Public Release

The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November – 1 December 2011, the group agreed on the following principles and approach.

Principles

1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.
2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.
3. CIMI is committed to transparency in its work product and process.

Approach

• ADL 1.5 will be the initial formalism for representing clinical models in the repository.
  • CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
  • Modifications will be required and will be delivered by CIMI members on a frequent basis.
• A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
• A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.
  • Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.
• A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.

Representatives from the following organizations participated in the construction of this statement of principles and plan:

B2i Healthcare www.B2international.com
Cambio Healthcare Systems www.cambio.se
Canada Health Infoway/Inforoute Santé Canada www.infoway-inforoute.ca
CDISC www.cdisc.org
Electronic Record Services www.e-recordservices.eu
EN 13606 Association www.en13606.org
GE Healthcare www.gehealthcare.com
HL7 www.hl7.org IHTSDO www.ihtsdo.org
Intermountain Healthcare www.ihc.com
JP Systems www.jpsys.com
Kaiser Permanente www.kp.org
Mayo Clinic www.mayoclinic.com
MOH Holdings Singapore http://www.mohh.com.sg/
National Institutes of Health (USA) www.nih.gov
NHS Connecting for Health www.connectingforhealth.nhs.uk
Ocean Informatics www.oceaninformatics.com
OpenEHR www.openehr.rog
Results4Care www.results4care.nl
SMART www.smartplatforms.org
South Korea Yonsei University www.yonsei.ac.kr/eng
Tolven www.tolven.org
Veterans Health Administration (USA) www.va.gov/health

Further Information

In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff@imail.org)

The federal policy version of “who will bell the cat” is “who will fund the service.” The LDAP approach assumes that some larger number of LDAP service providers can make a business out of gathering, auditing and maintaining identity data or that the government dole for HIE will continue unabated. This approach assumes we can pay enough to drag this information out of practices even though we have heard testimony that docs are notoriously reluctant to provide one additional datum about themselves over and above what is necessary to be licensed and credentialed.

The other approach puts the onus on practices to create their own identity information, either directly or with help from their health information service provider, electronic health record vendor, affiliated ACO, or professional society. The payment for the rather nominal requirement to create a web page comes from the practice, although it is likely buried in fees they pay practice management of other IT services. Likely sources of the Web page support include for health information service providers  (HISPs), EHR and HIE vendors that incorporate a consumer-facing portal into their products, medical professional organizations, and IPAs.

A microcosm of this “big system” vs “individual” approach can be found in our ongoing discussion on how to represent the practice areas on such Web sites. There are two lists available, the provider taxonomy constructed her HIPAA and a federated list maintained by specialty organizations and coordinated by the A.M.A. Both are designed to support the arcane distinctions necessary for billing or accreditation. We are not aware that either has a consumer-friendly semantic mapping.

To achieve semantic interoperability and consumer-friendliness we need two things.

1. a “golden” taxonomy — one or the other, available free
2. a free semantic mapping from golden terms to consumer-friendly terms — and free updating. “Government-paid” would counts as free.

However, I question whether semantic interoperability is a requirement here. If we follow a consumer search engine approach to ELPD, why not let the practices describe their specialties however they like, as they do now? We might define a data item that contains free text and is semantically described as “consumer-friendly declared practice area (free text, repeated items separated by commas).”

This advice will be better from some source than from others. The sources will compete in the marketplace in terms of overall effectiveness of practice Web pages including but not limited to proper identification of specialty areas. Some might even collaborate to establish and maintain a common list of consumer-friendly terms likely to be effective in consumer-entered searches. Other entrepreneurs might spider through web sites and build up more sophisticated and effective search products.

Some practices might inadvertently or slyly cheat by self-describing practice areas for which they are not licensed or competent. This is not desirable but there are many other methods of regulating the actual provision of care; we do not need to build that into the burden we pay to begin to use Direct more widely.

The whole point of keeping it simple is to get a useful dollop of work done, put it into action and see how economics and innovation shapes the next step.

If we keep it simple we could get this dollop done in a year. If we entangle it in state-by-state programs to mount (and inter-federate) LDAP servers who knows how long it might take, and whether the services will be economically sustainable?

I agree with much of what he says, in particular his distinction between clinical interop and semantic interop. I take it to mean that the level of rigor required for getting to working clinical interop is less than full semantic interop and more likely to be handled with feasible modifications to existing products.

[BTW, a big +1 to Graham for his blog name: Health Intersections. It really captures the nature of interoperability as interfaces at the intersection of different systems, businesses and medical and IT cultures. This is the POV that leads to the distinction between clinical interop and semantic interop.]

I also agree with some commenters that V3 Is Not a “Total Failure.” The RIM is a basic contribution to  healthcare modeling that for the first time captured the role of “role” in relating administrative and clinical data. It’s use of “mood” to capture the alignment of and differences among clinical data throughout the workflow of healthcare was equally brilliant. It is a shame that the developers chose to describe that discovery in terms that played well in academic circles and added barriers to sharing the knowledge with the 95% of IT folks that do the real work. This same pursuit of the perfect abstraction extended into the data types, adding to general difficulty in getting acceptance of V3 artifacts.

V3 Messaging is close enough to having had zero impact as to not merit further discussion. Some RIM-based artifacts, however,  such as the CCD and other documents in the CDA family have achieved centers of use and are at least at the level of “it’s better to use these than to start over.” (That may not sound like much but it is exactly the level of success that HL7 V2 enjoys.)

It’s interesting to explore why CDA has fared better than V3 messaging. Here are some factors to consider:

Fighting a Different War. V3 messaging was the classic case of the generals fighting the last war. CDA explored new territory and looked at interfaces in a manner that was well-understood by clinicians (signed documents). It thereby received support from a class of pragmatists who would not invest a lot of time in improving  interfaces that were working “well enough.”

Detachment from the Communication Paradigm. CDA documents are all about content. They are not tied to how (or even whether) they get transported.

Less Top-Downedness. Because a great deal of CDA development was focused on specific use cases it was sometimes possible to hide the complexities of the RIM in stuff the clinicians and other business experts were willing to accept as “the XML gibberish.”

Implementation Guides. The nature of CDA permitted focus on fairly narrow use cases. This led to the development of implementation guides that allowed implementers to figure out what to plug in among the XML gibberish in order to communicate. Not ideal but able to make  headway for those that are fighting a new war.

Less Bad SNOMED Juju. In the U.S., CAP was seen as interested in financially exploiting its the intellectual property in SNOMED and deeply suspected within parts of the AMIA community. In some other countries SNOMED was seen as a US-only product. HL7 was driven by folks on the side that was suspicious of, if not outright hostile to, SNOMED. As a result most of us in HL7 ignored the intricate nature of the relationship between codes and information structures on the theory that codes were a separate problem. Although SNOMED CT still has many issues, the formation and behavior of IHTSDO has led to the widespread view that it is better to work with IHTDSDO to improve SNOMED than to start again.

[I am honestly not clear on why the CDA group had less hostility to SNOMED. Perhaps it was because it formed later in the history of HL7 and brought in new blood; perhaps it was because it was more focused on specific use cases it had a more utilitarian view. It is also possible I am imagining that there was a difference. The important point is that a "fresh look" in HL7 has to purge HL7 of residual resentment of SNOMED and include cooperation with IHTSDO as a base part of its methodology.]

Applying the Lessons
I am not arguing that CDA was a raging success; I see growing adoption of implementation guides that include CDA documents but the pace of adoption since CDA R2 became a standard does not justify a view that CDA represents a perfect solution to the overall problems in the HL7 V3 series of standards. Nonetheless it is important that the fresh look be fighting the right war, detached from the communication paradigm, less top-down, have tool-based support for the rapid development of implementation guides and squarely aligned with IHTSDO.

What’s in a Word?
Several of the commenters on Graham’s post implied that declaring V3 a failure has negative political consequences. This can be true. Backing for national level programs in their countries may not transfer to the fresh look if they have to acknowledge that what they were backing failed. These are the realities we face working in a world where spending decisions are made by agencies with wide scope and little depth. However, the countervailing concern is that some more comfortable political formulation might leads diehards within HL7 to believe that all that is needed is to tweak version 3. Should that view prevail, the relevance of HL7 will substantially decline.

Visiting the interop showcase over the years I quickly learned to ask “where is this running?” for each demoed standard or profile. Early it was mostly vendors saying “we could do this” not “we are doing this.” Over time some standards and profiles have caught on and it is possible to find some “we are doing this” demonstrations at the Showcase. Most standards that actually get to the plateau of “we are doing” spend a few years in the valley of “we could do” first.

This year, The Direct Project debuts  at the Interop Showcase on the Plateau. Each of the 8 demos in The Direct Project space are either on the Plateau now or are far enough along that they will be very soon. For an effort that was actually announced at last year’s HIMSS this alone makes The Direct Project portion of the Interop Showcase worth a visit.

This is a complex issue, so I will start and end with a summary.

Tell ‘Em What You’re Gonna Tell Them

Here are the conclusions and recommendations included in this post.

• Documents will continue to be at the heart of information flow for patient care and one primary way of bundling clinical information about people.
• It is appropriate to deal with smaller snippets of clinical data outside of such bundles for some uses. However, each such use will have to accept and account for the lost context that comes when snippets are extracted from bundles.
• Although the PCAST report refers to these snippets as “atoms” a more appropriate metaphor is to think of them as “molecules.”
• An evolving universal exchange language (UEL) should first target agreed-on definitions of the molecules.
• The UEL should be used to encode data within documents (or document formats should include embedded UEL).
• No document, however, should consist solely of coded data. They should all include a human-readable representation of the information that has been created
• The UEL should be equally support unbundled use of clinical data for searching, conveying and reasoning on clinical data that is not bundled into documents.
• The UEL should not be as arcane as the current coded form of HL7 CDA documents.
• There is a large reservoir of definitions of molecules available in as many as seven different projects world-wide, including some that are being used as tools in the fourth SHARP grant.
• These definitions can lead directly to XML data representations that are far less arcane than current HL7 CDA.
• HL7 Green CDA is also a step towards less arcane XML (although it still includes the dreaded OIDs). However, HL7′s recent position statement on Green CDA indicates an unwillingness to do anything but permit experimentation on the Green CDA.
• Consistent with PCAST recommendations, every system that has legitimate access to healthcare data may encode it using whatever vocabulary and ontology it wants. Sharing the data, vocabulary or ontology is a business decision made by the operators of a system
• Contrary to PCAST recommendations the government should sponsor specific vocabularies and ontologies that serve as baseline capabilities for a UEL.
• ONC should start an intense project similar to The Direct Project to establish molecular definitions in support of Stage 2 Meaningful Use requirements. This project should leverage the reservoir of molecular definitions that are available to the government now. It could be a fly-off between Green CDA and another less-arcane format.

Tell ‘Em

At page 72 the PCAST Report says

As mentioned, [HL7’s] CDA is a foundational step in the right direction. However, the thrust of CDA seems largely that it be an extensible wrapper that can hold a variety of structured reports or documents, each with vocabulary-controlled metadata. While this shares many features with the universal exchange language that we envisage, it lacks many others. In particular, it perpetuates the record-centric notion that data elements should “live” inside documents (albeit metadata tagged). We think that a universal exchange language must facilitate the exchange of metadata tagged elements at a more atomic and disaggregated level, so that their varied assembly into documents or reports can itself be a robust, entrepreneurial marketplace of applications. [Emphasis added.]

This statement has created a great deal of controversy.

• On the one hand, there is a real danger to patients when individual “atomic” statements about them are taken out of context.
• On the other hand, there are many situations where the risk-value ratio of pulling such statements out of a document favors doing so.

Without techniques that require extracting specific facts from documents we would not be able to plot a patient’s cholesterol trend (documented in separate visits), have automated surveillance, or perform population health studies.  If there will ever be substantial secondary use of data collected as a part of giving care, this extraction is necessary.

The PCAST expresses faith that making data available in a more atomic form than documents will enable innovative new applications. This faith seems well founded to the extent that

• the data is truly deidentified or made available under truly informed and revocable consent, and
• the applications do not fall into the trap of making false inferences based on data pulled out of context.

So far this is easy. There may not have been any furor except but for the phrase “perpetuates the record-centric notion.” One thinks of perpetuating myths, and importance of the context implicit in a document is not a myth.

In fact, all of these statements apply:

• documents will continue to be at the heart of information flow for patient care, AND
• a UEL should be used to encode structured clinical information within documents, AND
• the UEL should be equally support searching, conveying and reasoning on clinical information in clusters that are smaller than entire documents.

Atoms and Molecules

Clearly the notion of what “atomic” means must be teased out. In a recent presentation Stan Huff gave an example that illustrates the danger of being overly atomic.

• A stack of coded items is ambiguous. (SNOMED CT)
  • Numbness of right arm and left leg
    • Numbness (44077006)
    • Right (24028007)
    • Arm (40983000)
    • Left (7771000)
    • Leg (3021000)
  • Numbness of left arm and right leg
    • Numbness (44077006)
    • Left (7771000)
    • Arm (40983000)
    • Right (24028007)
    • Leg (3021000)

Without enough structure to understand the sequence and whether a code modifies the code before it or the code after it these “atomic” concepts are meaningless.

So, let’s assume that the PCAST intended its concept of “atomic” to follow Einstein’s rule, “Make everything as simple as possible, but not simpler.” I prefer to think of the Einstein level of simplicity as “molecular” rather than atomic. The structure includes multiple heterogeneous atoms joined together in a very stylized way. Molecules create a context in which the atoms are meaningful. Simple molecules such as chemistry lab results or blood pressure tests may have as few as a dozen atoms, although many of the atoms are seldom used so the number of vital atoms in common molecules is lower. More complex molecules, such as an initial assessment of a new pregnancy, may have hundreds of atoms. One can carry the metaphor further by pointing out that certain combinations of atoms will exist as chemical radicals, fitting into the larger molecule in the same way a single atom would. For example, a blood pressure “radical” may be a stylized part of many assessment molecules.

To define a molecule it is necessary to achieve consensus on several things:

• What are the fields of data described in the molecule? For example, for a blood pressure reading molecule the data fields include the diastolic and systolic readings, the posture and the method (automatic or manual). Other situations may involve more than a dozen data fields.
• How is the data represented: a number, a string, an image, a code, or something else?
• How are the units of measure represented? Are they assumed or explicitly stated? For example, must the systolic and diastolic pressures be stated in millimeters of mercury or may they also be expressed in millibars? If the latter, how are the units of measure expressed in the molecule?
• What codes from what coding system are used to represent the overall molecule and each of its constituents.
• What codes from what coding system are used to represent any observed values or other data.
• How are the various bits of information structured together logically. For example, a blood pressure reading consists of exactly one systolic and one diastolic reading. A separate molecule might be a differential blood pressure. It might include several pairs of systolic-diastolic readings with specific postures. Here the basic blood pressure molecule may serve as a “radical” in forming the more complex differential blood pressure module.

It is important to note that the choice of codes interacts with the definition of structure. Choosing a pre-coordinated code to identify the molecule results in fewer data fields than is the case with post coordinated codes. (The Wikipedia writeup on SNOMED CT describes pre-coordination and post coordination. A Google search will uncover more rigorous discussions in academic articles and books.)

How many molecules and radicals are there?

That is how many ways can you define the combinations of atoms that make sense and are useful for communicating patient data? Frankly, nobody knows. For one thing, even as they are identified and brought to consensus new ones become needed through advances in science and care approaches. I have heard estimates from 20,000 to 100,000 but a number of physicians seem to agree that a very useful collection of molecules and radicals would contain many fewer than 20,000. Stan’s presentation describes several different parallel efforts to enumerate the molecules using siloed methodologies. The one he is working on as identified more than 4,000.  These are being used as part of the toolset in the fourth SHARP grant.

On Monday 14 Feb John Halamka will add a post to his blog that described five efforts to create molecule definitions.

What names do the serious folks use for molecules?

“Clinical Element Model” and “detailed clinical models” are common terms. HL7 uses the term “Clinical Statements.” OpenEHR and CEN 13606 call them archetypes. Each molecular form is expressed in two ways, as a template that describes how instances are constructed and in many, many instances containing specific data about a subject and constructed according to the template.

I will use the term clinical statement here, meaning an expression of a discrete item of clinical (or clinically related) information that is recorded because of its relevance to the health or care of a subject. (This is less precise than the HL7 definition of the same term and it is generalized to apply beyond caregivng processes and to apply to people who may not be under care as patients.)

Molecules as Aids to Interoperability

In a recent post John Halamka described a clinically important glitch in sharing allergies by way of the CCR and personal health records.

BIDMC’s EHR considers an allergy list entry to be the substance, the reaction, the observer (doctor, nurses, your mom), and the level of certainty.   Google  considers an allergy to be the substance and a mild/severe indictor.  Thus, a transmission of an allergy “Penicillin, Hives, Doctor, Very Certain”  to Google results in “Penicillin” with no other information.    Use of an agreed upon list of data elements (i.e. what constitutes an allergy list) for data exchange would resolve this problem.

A physician viewing the allergy as filtered through the data model of the PHR has significantly less information in deciding how to deal with the patient.

There is a strong argument that getting agreement on the important molecules is more important to interoperability than getting agreement on complete bundles such as the CCD/CCR or a discharge summary.

Molecules and Documents

What is the relationship of a molecule to a document?

Just as it is not possible to interpret the atoms without the context of a molecule there are strong arguments that important meaning is lost if you interpret the molecules without the context of a document.

Clinical statements in isolation.

A lot of physicians believe that in patient care, most clinical statements cannot be properly or safely interpreted in isolation. A statement such as “the patient has been prescribed 10 mg of Crestor qd” may be subject to a different interpretation if another statement is that the patient is not taking the drug because he believes it is causing his myalgia.  ”History of smoking” means something different under “family history” than it does under “patient history.”

One very relevant piece of context is the purpose for which a set of clinical statements was prepared. A health assessment on a patient with no obvious cardiovascular problems is different from a preop workup on a patient by a cardiologist and that is different from a cardiologist’s assessment of a patient who has pain that may be angina.

In medical practice there is a well-established expectation that a collection of clinical statements created for a purpose and signed by clinician does contain enough relevant context to be useful to another clinician by itself. Common practice refers to those collections of statements as a document. The physical act of signing (with a pen or electronically) represents a point at which the signer believes that the collection of clinical statements, taken together, represents a useful set of information about the patient.

(So far, we make no assumption about the form of the document or the method by which the clinical statements are entered. What’s important is that a clinician prepared it with a purpose in mind and, in performing some signing ceremony, took responsibility for it being accurate and not missing glaring context information. Four forms of documents that illustrate the range of forms of documents are: a bit image of a fax of a dictated report; an electronically transmitted dictated report that contains all the natural language as computer text; an electronically transmitted text report that contains images of EKG strips, rashes, audio recordings of chest sounds or other multimedia text; and, reports prepared in computer software so that all the data is structured and coded using clinical standards.)

Secondary uses of data often aggregate clinical statements about many subjects extracted from many encounters or other data sources. These uses involve a controlled loss of context that represents an acceptable level of risk for the purpose. For example, in a study of Crestor vs. Lipitor it may be acceptable to extract the prescribed amounts without regard to reports of the patients’ compliance. (It may even be beneficial.)

To the maximum extent possible all data about a patient should be encoded using a UEL that enables straightforward extraction of their clinical statements. To the maximum extent possible that “exchange language” should be common in all documents (universal). The PCAST report does a service in calling for an exchange language that is universal and supports straightforward extraction of clinical statements (appropriately sized molecules). This can be very important to support searching and secondary use of data, although natural language processing of documents without coded clinical statements will continue to be equally important for many years.

I believe that the UEL should not be as arcane as are the coded form of HL7 CDA documents. However, the need for a simpler UEL in no way implies that maintaining the source document structure is not critical when the data is passed from one clinician to another in the course of patient care.

The Importance of Partially Coded Documents

As a practical matter it is unlikely that all the data in most documents can be encoded. The UEL must include the ability to represent partially coded data. (Or, conversely, the document must contain the ability to include some of its data encoded using the UEL.)

In Testimony for the Enrollment Working Group last June, I expressed very real concerns about “incremental interoperability” to avoid “frozen interface syndrome” a phenomenon where industry gets so comfortable with an existing standard that it becomes economically infeasible to move on. Clearly the PCAST has prescribed an approach to meeting these concerns, but it assumes that the starting point is coded data. In fact, a pragmatic strategy to reaching the PCAST goals must start from a starting point of mixed text and coded data. As a practical matter documents will be prepared on systems with varying ability to encode the clinical statements. They will be consumed on systems with varying ability to decode the structured clinical statements. Documents should all meet a lowest common denominator format where they can be read and displayed by systems that have little ability to interpret the coded and structured data. Even sophisticated systems that receive documents that are extensively coded will need to present the document as it was seen by the signing clinician.

Is it More Important To Standardize Molecules or Documents?

Most standards efforts have been oriented towards defining documents as they come closer to fulfilling the needs of specific use cases. However, the reality is that the definition of use cases are only approximations of the real-world needs and many real-world use cases are going to fulfilled by some combination of structured and unstructured data. The benefit of document definitions as standards is that they provide a convenient way to enumerate what must be sent (usually pretty minimal) and what may be sent (usually wide open).

It is unfortunate that HL7 has produced arcane XML and currently seems uninterested in producing wire standards based on Green CDA other than to “encourage experimentation.”. However, ONC has an alternative that is arguably more closely in line with the PCAST recommendations, seems to lead directly to much less arcane XML and doesn’t involve starting over. ONC should leverage the excellent work that has been done by the organizations that have been defining molecules to create straightforward XML representations of the most important molecules. It should define documents as having a fully human-readable representation of what is transmitted and, to the maximum extent possible, having coded molecules according to one of the fine libraries of molecule definitions that are out there. With a project comparable in interest and intensity as The Direct Project it might have specifications available for the draft notice of proposed rulemaking for Stage 2 of meaningful use.

Who Defines the Molecules: Government or “The Market”?

Directly after the statement cited above the PCAST Report says:

In a similar vein, we view the semantics of metadata tags as an arena in which new players can participate (by “publishing”), not as one limited to a vocabulary controlled by the government.

This statement is important and may invalidate my assertion that there is no real controversy. The PCAST may have been asserting that all clinical statements created about subjects can be interpreted post hoc and the software doing the interpretation could use its own molecular definition or whatever third-party definitions they find appropriate. This represents a major opportunity for innovation and also a major danger that one proprietary interest could ultimately control healthcare data in the U.S. Consider the current market for generalized search engines, such as Google and Bing. The “secret sauce” that establishes competitive differentiation among them is the vocabulary and related techniques that they employ to optimize a user’s success in finding what they want. Neither firm publishes their approach. The AND statements below describe a balanced way to enable innovation while guarding against an information monopoly:

• Every system that has legitimate access to healthcare data may encode it using whatever vocabulary and ontology it wants. Sharing the data, vocabulary or ontology is a business decision made by the operators of a system, AND
• The government should sponsor specific vocabularies and ontologies that serve as baseline capabilities for a UEL.

Tell ‘Em What You Told ‘Em

Here it is again. If you read all the way through to here, think of these as the Cliff Notes.

• Documents will continue to be at the heart of information flow for patient care and one primary way of bundling clinical information about people.
• It is appropriate to deal with smaller snippets of clinical data outside of such bundles for some uses. However, each such use will have to accept and account for the lost context that comes when snippets are extracted from bundles.
• Although the PCAST report refers to these snippets as “atoms” a more appropriate metaphor is to think of them as “molecules.”
• An evolving universal exchange language (UEL) should first target agreed-on definitions of the molecules.
• The UEL should be used to encode data within documents (or document formats should include embedded UEL).
• No document, however, should consist solely of coded data. They should all include a human-readable representation of the information that has been created
• The UEL should be equally support unbundled use of clinical data for searching, conveying and reasoning on clinical data that is not bundled into documents.
• The UEL should not be as arcane as the current coded form of HL7 CDA documents.
• There is a large reservoir of definitions of molecules available in as many as seven different projects world-wide, including some that are being used as tools in the fourth SHARP grant.
• These definitions can lead directly to XML data representations that are far less arcane than current HL7 CDA.
• HL7 Green CDA is also a step towards less arcane XML (although it still includes the dreaded OIDs). However, HL7′s recent position statement on Green CDA indicates an unwillingness to do anything but permit experimentation on the Green CDA.
• Consistent with PCAST recommendations, every system that has legitimate access to healthcare data may encode it using whatever vocabulary and ontology it wants. Sharing the data, vocabulary or ontology is a business decision made by the operators of a system
• Contrary to PCAST recommendations the government should sponsor specific vocabularies and ontologies that serve as baseline capabilities for a UEL.
• ONC should start an intense project similar to The Direct Project to establish molecular definitions in support of Stage 2 Meaningful Use requirements. This project should leverage the reservoir of molecular definitions that are available to the government now. It could be a fly-off between GreenCDA and another less-arcane format.

First Takes are very short by design. In this post I want to expand on the significance of this product as an example of a health information service provider (HISP) as described in the NHIN Direct Abstract Model.

From my early blogs on Simple Interop a fundamental goal has been to carve out a role for technology providers that was much simpler than the complex responsibilities of an HIE. An HISP has to follow special rules because it is handling healthcare data but the rules are much simpler when it is not vehicle for looking up patient data. The HISP has to assure that the sender and receiver are valid healthcare entities and be prepared to disenroll them if they lose that status. However, it does not have to manage a consumer consent role because it is only pushing data from one authorized healthcare entity to another. Consent is determined by the sender according to HIPAA and whatever additional rules it chooses to imply.

Our feeling was that the simplified role would attract companies that would start up without grants and creatively find value propositions to repay their investment. We did not want to overconstrain the role for fear of blocking innovative solutions. In this sense standards that are minimally constraining invite more innovation than “soup to nuts,” full-stacks.

We also recognized that offering provider directories was a substantial challenge, recognized but unmet in the original proposal. Using a tried-and-true incremental Internet approach the plan was to standardize a little and get it into real use, and then come back to the next steps. We felt that NHIN Direct would get initial usage at the community level. Healthcare Internet identifiers would be conveyed on business cards, letterheads, and other out-of-channel means sufficient to get a first bolus of real-world use and, by the way, provide substantial help to healthcare delivery organizations attempting to demonstrate meaningful use of their EHRs by push-based exchange of healthcare information. Not the ultimate solution, but good enough to start.

This notion of enabling free enterprise seems to have paid off. Here is a self-funded vendor stepping up to the HISP role and, by the way, able to leverage a large book of existing physician relationships to accelerate on-boarding and provide national directory assistance for Internet identifiers.

I would not be at all surprised to see other technology vendors enter the same market soon, leveraging their own special assets to attract critical mass. The good news is that if all the vendors support NHIN Direct, exchange among their networks will be straightforward. The challenge that remains is to arrange a directory service that crosses their networks, maintains the integrity of up-to-date information and protects the privacy of physicians.

Under the incremental Internet approach, that is a challenge for a future day.

The ARRA has put us closer to that position than I imagined was possible. Working backward, item (c) is to be achieved by various HITECH programs and the meaningful use incentives; and item (b), the  end-to-end responsibility is at the level of the ONC, not a subordinate  entity tasked with that purpose. Achieving (a) is the topic of this blog post.

ONC has managed to work miracles (when compared to the normal course of government work) to meet  Congressionally mandated deadlines for other programs, but specifyin standards required a more ad hoc approach. At the same time ONC (and particularly Doug Fridsma) have been working in the background to adapt an approach to (a) that has worked in the Department of Homeland Security. This is called the National Information Exchange Model.

Sidebar: to avoid adding wind to any Web-based firestorm here, I would like to say that there is no reason to believe that the program will be run by DHS, will force DHS developed standards on healthcare or well give DHS any legal or pragmatic access to an individual’s healthcare data other than what it already has. ONC is simply adopting and adaption parts of the DHS standard-developing methodology. Ideally the methodology comes with standards-developing tools to implement it.

The final contract for NIEM in healthcare was completed last Saturday. Doug gave a summary presentation at the HIT Standards Commitee meeting that included this slide:

NIEM Overview

These preparations have proceeded without the transparency that we have become accustomed to from ONC. As we begin to learn about the program I will be looking for the answers to these issues.

1. To what extent has the NIEM methodology and tool set had to adapt to the ginormous complexity of codes and value sets that is table stakes for the healthcare standards game?
2. Can the tools and methodology adapt to XML representations that were not created specifically for the purpose of representing standards under the toolset?
3. I can understand why ONC did not want to give a single contractor exclusive knowledge of and influence over the development of these standards. I can also understand why ONC did not want to use potentially vulnerable internal positions to fund the work. But I still have to wonder if using five contractors is a manegable proposition.
4. The program calls for trial implementations. This is good and similar to parts of the unusual approach being used in the NHIN direct program. However, what we really need is an active feedback loop that extends through early real-life implementations. It is hard to see how that level of feedback can be achieved in this approach … but I have been surprised before.

As of now this particular work is being met with a good deal of skepticism, including my own.

That being said, I have been impressed with many examples of innovation that have come from ONC.

In a time when red meat passes for a formal gown and “caterwaulablogging” is as routine as waving howdy, I pledge to express my concerns openly and with as little verbal plumage as I can muster, in hopes that I am contributing to the evolution of these ideas towards the vision I set out two years ago (and the evolution of my own views).

Writing separately, Arien Malec (the NHIN coordinator) has characterized the split as between EHR vendors and others, rather than Sean’s big vs. small categorization. It is hard to tell the difference because only large EHR vendors have the resources to put into big group processes like NHIN Direct has become.

Sean and Arien are lumpers and I’m a splitter. If you look at the assumptions that are driving the participation I saw nine different points of view:

• A better way to make standards. The lesson taken from testimony at the HIT Standards Committee was that assembling a small group of players with a common vision, strong leadership and a plan for early implementation works better than the more ponderous “design by ballot box” approaches of large standards efforts. “Rough consensus and move to code; intermingle completing the consensus with writing code.” A consequence of this approach is that the work product will be judged later by whatever consensus process is necessary to adopt it as a standard; the work product is not preordained to get that far.
• Discard and start again: the EHR market is basically broken and needs to be replaced by products that great innovators could produce if they weren’t constrained by a regulatory process and standards process that is way too willing to embrace complexity. NHIN Direct must lay the groundwork for this.
• The Long View: the primary goal of NHIN Direct is to start a long term process of incremental architecture towards enabling the business innovation. Increment number one should be “messaging” across EHRs and non-EHR users, but that is only a start. The approach must enable future growth of the security infrastructure and the behaviors that can be enabled among participants that go way beyond simple delivery of messages.
• The RESTful Long View: everything that that long-view guy said plus a commitment to the ultimate architecture being RESTful.
• Top-downism the path for health information exchange has been set down by the grant program. Without such an organized approach attempts to interoperate are doomed to failure. NHIN Direct should be limited to those areas that can help the master plan succeed, but it should not create an alternative path to interoperability.
• Minimal Value: EHRs are at least adequate to meet the needs of improving healthcare. The basic problems of interoperability have been solved by IHE, the HIE grants and prior NHIN work. The only reason for NHIN Direct is to get hospitals connected to EHRs owned by community physicians faster than can be accomplished by standing up HIEs.
• Deadline Fatalism(1): the rules of the game are set by the ARRA; this effort is only useful if it allows are clients to more quickly achieve EHR-to-EHR communication in order to qualify for incentives earlier.
• Deadline Fatalism (2): like #1 but it also includes supporting hospitals in communicating with physicians who do not have EHRs that qualify for incentives. This will be important for transitions of care and potentially for meaningful use requirements in Stage 2 or Stage 3.
• There’s gotta be something better, sooner. The vision of nearly universal EHRs communicating through a ubiquitous set of HIEs that are interconnected via the NHIN too far in the future. These folks want to see something a little better than the fax machine as soon as possible. They will be happy if it helps compliance with meaningful use, but the requirement is much more basic and the impact more profound than simply helping to earn incentive money.

The size and diversity of the NHIN Direct is making it more difficult to hold to the “better way to make standards” view.  We have become a group of strange bedfellows where the strangeness is stronger than the fellowship.

The size of the group is partly a result of the attention it has received from ONC. Otherwise, we wouldn’t see the “top downists” and the “limited value” folks who basically believe that the main challenge is to execute on an established direction.  Many believe that the outcome of the NHIN Direct group is automatically destined to be a standard recognized in federal  regulations. ONC has said the opposite but they haven’t been heard or understood.

If those that don’t believe NHIN Direct is mission critical fall way, would any of the established EHR vendors continue to participate? If so, it would be because they fall into the “Deadline Fatalism (2)” or “There’s gotta be something better, sooner” categories.

To their credit the HIT vendors have come a long way in offering to adapt the IHE standards that are used in NHIN Exchange. They have offered a “pure push” approach. They have offered to remove any protected health information from the unencrypted portions of the messages available to HISPs.  The main sticking point seems to be whether the secure backbone protocol is SOAP, WS-* security, supported by the interface discovery capability in UDDI.

Unfortunately, the RESTful Web services movement was founded as a reaction against some of the assumptions inherent in the SOAP/WS-*/UDDI approach. RESTful Web services is a different approach for dealing with complexity. There is substantial justification for this but, but the basic notions of how to design  RESTful Web services is still evolving. The team working on NHIN Direct didn’t get beyond some very simple test code and didn’t demonstrate the deeper values of the RESTful  approach. I personally think those values can be achieved but this will take much longer than the REST advocates believe.

(This debate about RESTful vs traditional Web services sounds a bit like the Astronomy society deciding whether Pluto is a planet. But it is more like cosmologists arguing a theorem. The outcome can profoundly shape future directions.)

Frankly, there is not enough evidence in the world to put to bed the argument about whether the WS-* approach is good enough or better, or whether RESTful Web services  is the way to go. Absent evidence people will back their instincts and their instincts will be guided by their experience (they work they have already done), the amount that they will have to work to adopt a new approach and which of the nine points of view (above) they have.

If it goes to an approach of achieving decisions that are not consenuses (e.g., simply voting) then the process becomes one of which side can muster the most votes. One of the factors that shaped this effort was complaints about the HITSP experience wherein a number of participants felt steam-rollered by a few that they perceived to be an organized bloc with a particular agenda. I am not endorsing this view, just pointing out that thoughts like this are the inevitable outcome of a decision process that is not a true consensus process .

A Path Forward
I have rewritten this blog several times now. The trend has been from trying to find a path to reconciliation towards trying to have purposeful “disreconcilation.” Instead of having the group make a decision the decision is going to make the group.

The group must be reduced to a working size of folks can roll forward enthusiastically instead of feeling put upon because this is a diversion from their important work. So I would urge those who really think that NHIN Direct is unnecessary or unimportant to drop out. We can arrange for better communication beyond the group on what is going on than we have achieved so far, so those folks shouldn’t feel that they lose their insight into what is going on by dropping out. If you like what you see or find more industry acceptance than you imagine, we are doing everything we can to make it easy to get back in again later.

Among the members who do feel that the NHIN Direct idea is needed, we need to split into two or three groups. There still may be a substantial group that supports SOAP+UDDI for the backbone. If so, they should be a group with whatever governance they favor and their own process for getting to a working body of open source code and unfettered, comprehensible specifications. Perhaps IHE would like to host this effort since it so strongly builds on existing IHE work products.

Those that support “RESTful but maybe SMTP” or “SMTP but maybe RESTful” may become one or two groups according to whether they have enough appreciation of the combination of short-term and long-term views to have enthusiastic agreement. If this is one group it should favor an initial implementation using SMTP with a security infrastructure that will also support REST. It should look for another opportunity to use REST for a behavior that is different than pushing packaged messages around.

The deciding rule for forming groups should be to establish the minimum number of groups where the members of the group can work enthusiastically rather than feeling dragged along against their better judgment or when other work is more important.

With one or two smaller groups we can get back to proof by code rather than design by the ballot box.

This not ideal. Maybe all the groups will fail. Maybe they each will continue to split until there is no critical mass. Maybe they’ll all succeed and we’ll have “many standards to choose from.” Those would all be bad outcomes. But the current path is not tenable and the most likely path is that one of the two or three groups will be better able to prove their approach in the next few months and will end up with a strong enough case that others join in.

Isn’t that how the Internet was built?

(Last revision 13 June 2010 10:25 pm EDT)

ONC has followed this topic and offered many favorable comments. As it works out they will be announcing an effort under the rubric “NHIN Direct” at HIMSS. This effort appears to be directed at exactly what the “birds of a feather” might have accomplished, to create a spec using an open process, provide an opportunity for those interested in trying it to do so and coordinate their experiences.

Rather than have two parallel efforts, I am hoping that our friends frocked in familiar feathers will participate in NHIN Direct, as I most definitely will. Who knows, if ONC sees quick uptake and actual usage might we see that reflected in meaningful use or certification Stage 2 regulations? Dare we hope? I think we can have such hope. A consistent theme of Stage 1 regulations has been to back away from elaborately orchestrated specifications. Also, one of the recommendations from the HIT Standards Committee Implementation Work Group has been to start simple.

Risks
Our group, their group, what does it matter? Some folks have expressed the concern that the influence of government will lead once again to gold-plated specifications and approaches that cannot be rapidly deployed. That is a real concern, but frankly, there are some areas where Simple Interop needs to have an evolutionary path higher scale and use cases not enabled by HIPAA authorizations. Attention to these issues, as evolutionary concerns, can be very helpful.

Some folks have also expressed the concern that a few highly vocal and well-funded participants might dominate the process and the outcomes. Something like this clearly engendered dissatisfaction with HITSP deliverables. It might have been easier to keep a birds of a feather approach “under the radar.”

Risk Mitigation
Might expanding the requirements to work with other NHIN programs jeopardize the simplicity? Might some standards-group bullies show up? Sure, it could happen. It’s up to us to use our participation in NHIN Direct to avoid that. If it is truly open and has reasonable governance we should be effective.

So let’s all look forward to the HIMSS announcement and devote some quality time to making Simple Interop the cornerstone of NHIN Direct.

One Regret
As a child of the ’60s I was getting a big kick out playing the role of Speaking Truth to Power. Here was my chance to stick it to “the man,” taunt him with reality. It is nonplussing to have “the man” say, “right, good idea, let’s do it.”

Now I’ve got to find some other way to rebel.

After looking into this I confess that I have added to the confusion. As I have learned, a big part of the confusion is because people don’t mean the same thing when they say “web services.” It’s a bit like a fan from Manchester, NH and a chap from Manchester, England arguing about “football.” For example:

1. To some a web service is any service that can be obtained computer to computer using HTTP.
2. To some, a web service must at least use SOAP.
3. To others, it ain’t a true Web Service unless it is architected like the diagram below
4. Finally, there are those that also require the WS-* protocols.

Web Services Architecture

The Wikipedia article cited above attempts to clarify the set of choices by describing the world as being divided into two camps “RESTful Web Services” (number 1, above) and “Big Web Services” (all other combinations, including numbers 2, 3 and 4). This probably represents the main two camps in the nerd wars very well, but it is clear that the advocates of the RESTful style of architecture would not gladly accept into their camp everyone who confines their use of protocols to HTTP. For example, those that use only the HTTP commands but hide other commands in the URIs are mere pretenders, trying to make their approach look RESTful-ish but not legitimate claimants to all the benefits outlined in the Fielding dissertation.

Rather than some up with a taxonomy of names I think a better approach to Simple Interop would be to look at the capabilities needed to support  computer-to-computer communications outlined in Simple Interop: Issues Associated with Automatic Processing and, for each item on the list, answer these questions:

• Is this capability that Wes dreamed up really necessary for simple interop?
• Is it being done already enterprise-to-enterprise  healthcare apps on the Internet?
• If not in healthcare is this capability being provided broadly in other enterprise-to-enterprise apps that use the public Internet?
• If the capability is used, how much is based on standards and how much is defined ad hoc pair wise or in larger groups by the dominant trading partner?

Almost by definition any encrypted, reliable communications with scalable authentication (X.509 certs) based on “just HTTP” is going to match up with the fourth bullet.  To adopt a bilateral or  dominant-partner specification we need to have some consensus that would permit ONC to recognize it as a standard. I hope to find an approach that is, at least, used with a bunch of trading partners in production. If so, perhaps others will agree that adopting it would be the most expedient way to roll out simple interop to support the meaningful use interoperability measures.

I am explicitly staying away from a separate question, “what standards are available?” My rule is, if you want to pick something that will roll out quickly, pick something that has already been rolled out.

Digression on the term “Computer to computer messaging.”
This term also creates confusion. Aren’t all communications computer to computer? Isn’t a user in a Web browser or a thick client using a computer? What we are really trying to describe is a message that is sent without oversight by a user. So a lab technician approves the instrument result for the last test in a battery and then instantly moves to the next test in a different battery for a different patient. Sometime later the LIS transmits the results to the physician’s EHR, but there is no person in the lab watching it.

This is a lot different than the situation where that same technician is using on-line banking to change his postal address. Typically after one pushes the submit button the browser window goes dead until the bank has sent back another page saying it has accepted the transaction. In the latter case we have a person watching to see that things went well and, presumably,  willing to push Submit again or start over if some disruption in the Internet connection causes the transaction not to succeed.

Another term we have though of is “unattended messaging.”