BTW, we had that problem knocked in 1987 with HL7 version 2 but we lost ground going to XML Schema in V3.

Keith’s post made me wonder, does HL7 (or any application standards effort) really get enough bang for the buck to justify using XML schema at all? While XML schema does nail down some structural issues it  has not proven effective as the sole method of validating HL7 message content. It has to be supplemented by xpath-based rules to begin to validate the content.

Switching to simply using well-formed XML with xPath-based validation would (a) make extensibility easier and (b) open up the possibility of evolving to JSON.

The XML v. JSON example below shows the difference. (It is not HL7 XML syntax, just illustrative.)

In theory, JSON is about as powerful as well-formed XML. Some differences between JSON and XML are:

1. No concept of attributes as distinct from elements, which has always been a word-class, time wasting distinction without a difference in XML.
2. No use of unneeded and repetitious tags to close elements. Closing tags was of vestigal value when people created SGML by hand, but does nothing but take up space in XML.

Does the concise nature of JSON add value? You can pretty much get into a fight in any HL7 biker bar by raising the issue of concision.

Those who argue for it say that it gets you the value of the XML schema language, which is as important as you think Schema is valuable. They also argue that the extra characters don’t matter much in these days of cheap disk storage, high network bandwidth and enough processor speed to fuel the extra parsing overhead.

The pro-concision folks argue primarily that it makes a difference to people who ultimately have to look at instances in order to develop and debug code. It also matters when working with subject matter experts, who stubbornly want to look at instance examples to understand what they are being asked. Secondarily, they add that when you look at the pragmatic issues around using V3 for high-volume messaging the overhead in XML (and V3′s use of XML) is a pragmatic problem in the short-term, which is the term in which people actually build and use interfaces.

I had a religious conversion in the mid-90s and went from indifferent to concision to pro-concision. It came when I was working with SMEs in the insurance industry.

JSON (white space outside of quotes is completely ad lib.

{"person" :
  {"firstName": "John",
   "lastName" : "Smith",
   "age"      : 25,
   "address"  :
     {"streetAddress": "21 2nd Street",
      "city"         : "New York",
      "state"        : "NY",
      "postalCode"   : "10021"},
   "phoneNumber":
     [ {"type"  : "home",
        "number": "212 555-1234"},
       {"type"  : "fax",
        "number": "646 555-4567"}
     ]
   }
}

Two Styles of XML: the second example make more use of attributes and is therefore less extensible. White space outside of quotes is not entirely ad lib.

<person>
<firstName>John</firstName>  <lastName>Smith</lastName>
  <age>25</age>
  <address>
    <streetAddress>21 2nd Street</streetAddress>
    <city>New York</city>
    <state>NY</state>
    <postalCode>10021</postalCode>
  </address>
  <phoneNumber type="home">212 555-1234</phoneNumber>
  <phoneNumber type="fax">646 555-4567</phoneNumber>
</person>

<person firstName="John" lastName="Smith" age="25">   
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021" />
  <phoneNumber type="home" number="212 555-1234"/>
  <phoneNumber type="fax"  number="646 555-4567"/>
</person>

A fact check might have better served your endorsement of CIMI.

First Stan makes the statement that “the group agreed on [CIMI] principles and approach” and later lists a group of organizations. While these organizations may have participated in formative discussions at one point or another, they did not in fact all agree to CIMI principles and approaches.

Here are the specific facts.

HL7 attended the meeting in London where a consensus was developed that represents a draft of the statement that CIMI issued. Upon seeing the final draft HL7 specifically requested that its name be placed on the list of signatories to the document.

The document was carefully worded with respect to commitment. The specific wording is “Representatives from the following organizations participated in the construction of this statement of principles and plan.” Neither HL7 nor any other signatory SDO specifically endorsed the plan or give any indication that it would participate in preparing detailed clinical models or use them.

As I included this wording in my original post I don’t think that Gary’s implication of a factual error is well-founded.

Here is my  opinion.

After 14 years of working the current basic model of the RIM, HL7 has not effectively addressed a huge percentage of the detailed clinical models that CIMI undertakes to address. (Blood pressure is but one specific example. All HL7 says is that blood pressure should be sent as an observation.) There is reason to believe that CIMI will create that content tout suite because it is really about consolidating existing work that has been done over the last twenty years and used operationally in a few important venues. It would be appropriate for HL7 to suspend judgement until it sees whether CIMI actualy can get through “storming, forming and norming” rapidly and produce a body of work that is valuable because it (a) covers a lot of material, and (b) is available to all parties in an electronic form that can easily be adapted to the tools used to build standards.

Once CIMI has had a chance to produce tangible models, HL7 (and other SDOs) can choose among these options:

• bend the modeling approach and governance a little in order to take in this big gulp of specific detail needed for interoperability
• decide that the gulp is really not that big, not worth giving up any control by bending, or
• redouble its efforts to independently arrive at the same body of work.

I strongly urge HL7 NOT to take a preemptive, doctrinaire “not invented here” position until the actual value of CIMI work product can be evaluated.

As an old-timer, who remembers when HL7 was much more about producing results than methodology, formal governance or standards-world diplomacy, I admire the CIMI approach. It will produce its better mousetrap first and let the world decide whether to beat a path to its door.

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)

CHCF actually lives up to an important but seldom-followed precept of standards: producing a spec is only the start of getting a working standard. Someone has to nurse it through initial implementations, reflect on the lessons learned and amend the standards accordingly. Connectathon-like testing is moderately useful, but doesn’t get to many real-world issues that come up in deployment.

Ambulatory lab orders have a high potential ROI but are especially tricky. The basic informatics issues are straight-forward but the issues of patient identity, getting orders from a different place than the specimen is collected and dealing with unsynchronized order catalogs are baffling. ELINCS put together a consensus group that included reference labs, integrated delivery networks and vendors. They hashed out the workflows and developed an implementation guide based on HL7 v2. CHCF is now offering $300K in funding assistance to be spread among six or eight sites to test the draft spec. The learning from this effort will go back to a finalized ELINCS ordering spec.

Hopefully, HL7 and the S&I Framework will adopt the final implementation guide virtually as-is since by then there may be dozens of interfaces operating using the spec. It is always hard for a consensus group to accept the consensus of another group, as was demonstrated by the barriers HL7 put up to adopting the ELINCS results specs. Unless a standards organization sets the specific goal of facilitating the use of third-party work the US will never follow what is supposed to be a fundamental principle guiding ONC work: Standards are not created they are adopted.

In the mean time I recommend the CHCF specs to IDNs, EHR vendors and HIEs that are ready now to grapple with lab orders. It won’t be be perfect now, but it is better a better start than a blank sheet of paper. To the credit of CHCF, it stood up to the rough handling it had at the hands of HL7 and came away with a defined path to ease the current orders work. Thanks to that effort HL7 is now talking the talk; CHCF orders will give HL7 be a chance to walk to walk of valuing tested standards  and working with outside consensus groups.

(Updated 12/8 to correct link.)

• What further might be done to disambiguate and simplify the CCDA?
• What is the role of certification in ensuring interoperability.
• What mechanisms are available other than having a great spec to ensure the maximum compatibility among interoperating EHRs?

Disambiguation and Simplification

Robert Parker’s comment was helpful. He is one of the people who helped me to understand the issues around C32. He and others who commented privately points out that there will be continued areas of ambiguity in the CCDA that will need to be resolved.

This is the reason the estimate is that CCDA is only a 50 percent improvement. The world’s absolutely most perfect spec wouldn’t assure 100 percent interoperability out of the box, the question is what feasible in the next two years that would make a big difference.

Robert Worden commented that Green CDA could help close the misinterpretation gap. Indeed, Green CDA could greatly reduce the time spent developing and debugging interfaces. However, the current Green CDA ballot produced only an informative document which really just described the “Green CDA process” and did not contemplate its being used to transmit information “over the wire.”

In order for it to really help, the Green CDA process would have to be applied to the specs for selected documents defined in the Consolidated CDA producing new specifications, schemas, X-paths and validity assertions directly in business names that are currently hidden in an appendix of the Consolidated CDA. Otherwise Green CDA is simply an additional complexity layered on top of the already complex RIM-based specifications. Furthermore, the work products containing the green specifications would have to be specified in a regulation.

Certification

Stanley Nachimson’s post about testing clearly identifies one of those mechanisms. There are two kinds of testing. One is certification (as, for example, is required to qualify for meaningful use incentives). Some of the challenges that the certification program faces include:

• Because certification is a regulatory requirement, ONC must give careful attention to the cost, which is borne by vendors and end users. Extensive interoperability testing as a part of certification could dramatically raise the time required by system developers and inspectors for the certification bodies. This would dramatically raise the cost.
• Long cycle times in preparing, submitting for public review and freezing the certification rules, scripts and auxiliary data
• The requirement to incorporate clarifications and adjustments into Interop specifications as issues are discovered in testing and use.

Other Mechanisms: Testing and Dealing With Interpretations and Ambiguities

What might be done outside of a certification program? Keith Boone approached this issue by saying “One of VLER’s challenges was the loss of the organization maintaining the C32 at the time it was being deployed. That lack meant that many questions on interpretation had no place to be addressed. At least with CCDA, that problem will also be addressed.”

I hope he is right, although I don’t know exactly what program he has in mind. We need a program that is more agile than certification where those who will participate in US semantic interop can test their products more extensively pre- and post-certification. Such a program must provide a forum to record ambiguities in specifications as they come up in testing and usage, determine and publish guidance on how to resolve them and quickly reflect the resolutions in test suites. This must be agile in the sense that it can repeat this cycle quickly. I dither on whether such a program should be government-sponsored or whether we can find a way that multiple, private-sector firms could offer similar services. I hope to un-dither some by writing more about this.

During the summer and fall, an ad hoc work group of the HIT Standards Committee analyzed some of the specifications used in developing the first implementation of the Nationwide Health Information Network (NwHIN). During that work, it became apparent that there was a reservoir of experience available on using the specs. After all, the participants in the NwHIN include Centers for Disease Control and Prevention, Community Health Information Collaborative (Minn), Department of Defense, Douglas County (OR) Individual Practice, HealthBridge, Inland Northwest Health, Kaiser Permanente, Marshfiled Clinic (Wisc), MedVirgina, MulitCare Health System (WA), NCHICA, Oregon Community Health, Regenstrief (IHIE), Social Security Agency, South Carolina Health Information Exchange, Southeast Michigan Health Information Exchange, Utah Health Information Network, Veteran’s Health Administration and Western New York Clinical Information Exchange (HealtheLink).

Not everyone was invited to testify and not everyone that was invited was available on short notice. Public comments during the HIT SC meetings made it clear that some people felt that the public record was inadequate.

Most processes that advise the government are controlled under regulations that were developed in the era of the Selectric typewriter. They require months to schedule an extra meeting or announce a request for comments. Fortunately the Obama administration has pioneered the use of blogs as a low overhead means of enabling open and transparent public comment. Accordingly we on the HIT Standards Committee requested an entry on the ONC Federal Advisory Committee Blog, requesting further input. HITSC Seeks Comments on Exchange Specifications by December 15, 2011 was created on Nov 9, with the hope that people who participated in the NwHIN efforts would publicly comment.

So far, comments have been light and added no information on the topic at hand.

Come on, folks. Be a movement. Occupy the Internet. Give us the facts. Answering the questions posted there describing your experience implementing the specs.

Thanks!

Modified 17 Nov at 22:40 US Eastern time: nonsubstantive, factual change.

I will be speaking on the readiness of HIE vendors to support HIE, particularly care coordination and analytics. This is a kind of HIE where the value proposition is clear. It will be fun watching as the vendors estimate the important features and move their products from PPTware to paper mache and from there to solid brickwork.

It is interesting to note that the yin-yang of “best of breed” vs. enterprise products gets played out in one market after another. The race is all but over in electronic health records and pretty far along for payer transaction systems. My colleague, Joanne Galimi, will use survey data to position this issue for payer business intelligence systems. Hint: it’s still wide open.

When I had surgery in 2004 every nurse and resident at Stanford carried a BlackBerry, so I was astounded seven years later to read the presentation of Barry Runyon. He finds that only a few hospitals have traded their pagers in wholesale for smart phones. When will our devices support our hopes of improving our care processes? Barry will triage roles vs device requirements, but it is clear that clinicians must have a single device for codes, calls, alerts and collaboration.

For those of you attending be sure to sign up for 1-on-1 sessions with me and your other analysts on the Web before arriving. Many of us are totally booked up before day 1.

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.

Of course, the post was prompted by the buzz that ONC has been generating on this topic. The next shoe has dropped in Rich Elmore’s post Distributed Population Queries – A National Priority. It is equally significant to note that Rich has taken a leave of absence from AllScripts and is carrying an ONC business card while he works on this. In this post Rich announced the “summer concert series,” apparently an environmental scan designed to bring a common information base to interested parties.

This beast is obviously not a biped; Rich also announced that a third shoe will drop in September with the formation of Query Health under the S&I Framework. It is significant that Rich was a key player in the Direct Project, at the time a unique combination of a small investment in government time and money with a lot of volunteer work, organized by principles that have been successful in open source communities. These include

1. all activities are open anyone can observe and follow through a public wiki
2. those that are committed to implementations get to speak and influence the decisions
3. rough consensus, running code, final specification
4. a lack of formalized governance rules.

Query Health is different than the Direct Project in that it will be handled under the I&S Framework.

Although I hear the monthly briefings on the Framework I confess to being confused exactly what it is. It is easy to understand the projects that lead directly to meaningful use regulations but Query Health deals with an important scenario that may not find immediately available standard that have widespread use.

Maybe ONC wants a way to launch multiple projects with the representative participation, innovation and group dynamics of The Direct Project and yet still have a way to ensure that the purpose and work products of the individual products are well coordinated.

The twin goals of achieving spontaneity and innovation while achieving government-level coordination seem like an oxymoron. Rich will have his hands full. On the other hand, he is an able consensus builder with a great software background, and ONC  has walked the tightrope between innovation and the government regulatory apparatus better than any other government interop agency that I have ever seen.

I look forward to seeing the “fourth shoe drop” when the Query Health begins running with live patient data sometime soon.

The utility to public health and some kinds of research could be substantial and it may be possible to get started with an intense, voluntary effort similar to The Direct Project.

Public health covers a lot of territory. Some concepts for gathering data are enshrined in law and regulation and, therefore, are stable. “Reportable diseases” are typically enumerated and it is conceivable to build filters into lab systems to “send the data to the question (asker).”

But what of the requirements for situational awareness during an epidemic. Would public health officials want to ask about presenting symptoms, ED diagnoses, lab or micro results, pathological findings? As their understanding of the disease process grows how often would they want to change their inquiries to add data or refine the selection criteria? Pretty darn frequently, I’d wager.

How might it work?
In general, the sources of clinical data (EHRs, stand-alone labs, ePrescribing networks, etc.) would “sign up” to receive queries from requesters such as public health departments, researchers or other carefully identified requestors of information. It is critical that the identity of both ends of the transaction are established mutually authenticated each time data is transmitted. It seems that the security about the institutional asker’s of questions may require a higher assurance level.

Once a relationship has been established the sources of data might receive requests for data from time to time such as “tell me about encounters you have had with high fevers and vomiting as a ratio to the total number of encounters you have had for the same period.” The request would also include (or imply) information on where to send the data and how to associate it with a specific request.”

Requesting aggregates rather than individual data is a two-edge sword. On the one hand, it avoids policy issues around sending individual health information. On the other hand there is no way for the recipient to weed out duplicates from multiple sources so the statistical inaccuracy will rule out fine-grained measurements. Furthermore, because the statistics are generated at the source fine-grained pattern discovery based on sophisticated analyses of millions of records does not seem possible. This is an area where the perfect should not be an effective enemy of the good. Any pragmatic scheme to get even crude data into the hands of public health officials is better than a more precise scheme that would take years to get going.

In the un-PCAST world that we occupy today, it is unlikely that the data-source organizations would respond automatically. Some officer of the organization will likely approve each individual request. However, it would be ideal if that officer didn’t have to schedule the time of a programmer to determine if the request is feasible and, if so, code it up. In other words, it would be ideal if fulfilling the request was automatic and there was a workflow for the officer of the source organization to know about requests, and decide whether to authorize the release.

“Same old stuff” or a new day?
We all know the reasons that this can’t work. The policy issues are difficult but the biggest issue is that EHRs and other clinical data systems have different internal data schemas, so it is hard to frame a request and know that it is compatible with source systems and it is hard to fulfill the request without custom programming.

As that legendary scientist and explorer, Jean-Luc Picard, once said, “things are only impossible until they’re not.” It’s time to decide if we are approaching a cusp of possibility with regard to this issue. We have new resources (more EHRS, a fundamental secure communications infrastructure and standard coding systems in support of meaningful use requirements).

It is time to assemble a group of users and vendors willing to look at this issue intensely, follow the principles of building on available standards and, if pragmatic solutions exist, support them with an approach similar to the Direct Project, which is, “rough consensus, open source code implementations, final specifications.”