There was a time — and apparently it still is the time — when XML is the way to roll with the industry in terms of adaptability to existing tooling.

I was partly projecting onto XML itself my disaffection for the HL7 style of using XML.

However, as Graham has pointed out in The XML consensus is breaking down XML has not worked out to be the panacea we all hoped, wedding the data, text and object-oriented worlds. In the early years it offered one promise and delivered — it was a syntax that IBM, Oracle and Microsoft would agree on. That has been a great step forward.

Like most steps forward, once we have achieved it we begin to say “what have you done for me lately?” It appears to me that we are in a state across the IT industry where XML is becoming the “old technology” and people are waiting for a new trend that fixes some of the problems.

What will the new panacea be? I would like to believe that the work being done in JSON now, like the early work in XML circa the year 2000, will be at the heart of whatever develops.

But as Graham suggests what is needed is more than a simpler syntax.

For now I guess we’ll plod along with XML and XML schema and keep an eye on the nascent use new technologies.

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.

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.)

One hopes these efforts include a program of diet and exercise that is effective in reducing OID metastasis.

Through Clayton Christiansen’s work on disruptive technology we learn that designing for the high end of the requirement space is far from being a bonus that tops off a good design effort. It introduces nearly gratuitous complexity that makes the product more complex and therefore automatically less accessible to the majority of the market. OIDs are a clear example of such high-end design.

I applaud my many friends in HL7 for taking this on and Keith for finding the time to participate and report on it in such a lucid manner.

Metaphors gain their power from poetic ambiguity. One of the great things about a metaphor is that it can rally so many folks to believe they agree. They each read the metaphor as supporting their favorite point. The follow-on to a metaphoric rally must be a drill-down to tease out where the metaphor singles out an important common cause and where it papers over differences.  Using a RESTful approach to interoperability is another metaphor. Some of the discussants take it quite literally as the single most important point to agree on; others see RESTful as an example of a broad approach to rapid innovation.

Over the last few days I have come to believe the following “big takes” on this discussion. In another simplification I break the discussants into two groups,  “the Internet crowd” and “the healthcare informatics crowd.” I mean no disrespect to either group and understand that many people have a foot in both camps or at least a foot in one and a toe in the other.

There are implicitly three levels of contention. I will arbitrarily assign them to a vertical stack.

Bottom: Connecting (in the broadest sense). So much has been accomplished with well-layered Internet protocols to create quite complex behaviors and progress has progressed so rapidly that “the Internet crowd” can’t understand why “the healthcare IT crowd” wants to stick to technologies for secure transport that are “so five years ago” but preclude participating in rapid evolution. “RESTful operations” are a token of the deeper conflict, not the actual point of contention. Some of the informatics crowd significantly confuses the issue by presenting discussions on security based on standardized roles and other as yet unproven constructs.

Top: Semantics of Data. Understanding data clearly is a never-ending task. As Bertrand Russell said “Everything is vague to a degree you do not realize till you have tried to make it precise.” The Internet crowd has done very well with a model where semantics evolve as rapidly with experience. They have productivity tools that rely on some unstated but “common sense” approaches such as using business names as XML element names. The health IT crowd has been through this learning curve on clinical data and wants to skip over many learning steps that uncover ambiguities on health data. However the health IT crowd (including HL7) has made it more difficult to propagate its knowledge about health data because they have chosen to package it in self-created modeling formalisms and XML that is obscure to the max and doesn’t work well with common XML tools. They further complicate the issue by not knowing how to package their sophisticated understanding in a way that it can be understood by programmers who know the data of their own application but don’t comprehend the abstract approach.

Middle: The Semantics of Exchange Sequences. To a certain extent saying something is “architecturally neutral” means “it isn’t interoperable in any architecture.”Any attempt to truly achieve interoperability involves a state machine that implies certain sequences of transactions needed to get the job done.

The Internet crowd is used to improvising the sequences of actions that are required to accomplish a task but not standardizing them. The health IT crowd has attempted to establish very loose architectures (i.e., no technology or system factoring constraints) that standardize the sequences enough that two products that are expected to be interoperable could interoperate without continually adjusting the code based on what is going on in the broader community. Thus the Healthcare IT has fought its way to largely agreeing on XDS over a five year period (and XDS has evolved in that period) and the Internet crowd sees XDS as not applicable to their use cases and restricting their ability to improvise.

The Internet crowd represents a culture that employs the power of the Internet protocols in an enterprising, high-energy, innovative and incremental approach that has revolutionized some industries. The informatics crowd really does have the ability to shortcut many learning cycles based on experience and understanding. How can we introduce combine the peanut butter with the chocolate? Oops! There goes anothe r metaphor.

A number of healthcare standards and standards-profiling groups have published not only format standards, but also communications standards. Some do not. One of the reasons that HIPAA transactions were largely a failure is that the regulations included no approved method for communicating X12 transactions. Providers must conform to many dozens of different various specifications for the physical transport of data in order to get their bills paid. Alternatively they can pay a substantial click fee to clearinghouses to cater to the communications-spec whims of the payers.

I did not at all mean to suggest that the ONC in its role guiding the implementation of the ARRA should allow the same thing to happen again.

The HTTP Side

To a certain extent the specifications that are most disputed now relate not directly to HL7 standards but to specifications created by Integrating the Healthcare Enterprise (IHE) and adopted by the Health IT Standards Panel. Those poor fellas at IHE started working on an approach to cross-enterprise data sharing in about 2004 and believed IBM and Microsoft that Web Services would be the way to achieve secure, reliable, technology-neutral inter-enterprise interoperability. At the same time they adopted ebXML as a then-proven approach for store-end-forward messaging.  IHE members dumped a ton of sweat into puzzling through the specs, developing selective profiles of them that might actually interoperate, conducting repeated multi-may inter-vendor testing sessions and honing their specifications. Now that they made this investment they are naturally reluctant to give it up. There are actually live implementations now using these protocols, we learned last week.

Oh how times change! During the five years that have passed new entrants such as Google and Amazon have joined the ranks of market-dominating vendors, serious concerns have developed about the complexity of Web services and everybody’s favorite new approach is RESTful Web services‎. This approach is, indeed, simple and layers well. There is a lot of real-world use of RESTful Web services. Security is very simply provided by using the security associated with HTTPS.  Other requirements important to healthcare, such as non-refutability transmission and receipt, can be handled equally well. Probably many of the big firms already are.

In fact, I would venture that each of Amazon, Google, Microsoft and other dominant players each have one or more specs built around the concept of RESTful Web services each of which is simple, particularly because it was catered to the needs of their specific applications. Like providers sending in HIPAA bills, software developers have to develop interfaces that are generally the same but differ in enough specifics that they either align with one vendor or re-develop their interfaces for each.

Is that the best we can do for healthcare interoperability? Somehow I had hoped for more. I don’t really care about RESTful Web services or the other kind. I do care that N x M interoperability work for medium sizes of N and M. For example, if a vendor or care delivery organization (CDO) is developing a clinical solution that needs to interoperate with some other HCOs, labs, multiple PHRs, public health and quality measurement agencies, I would like to believe that they could do so, without getting into a “my business is bigger than yours ” contest. It is clearly not the case that every CDO needs to talk to every other CDO. More and more they will outsource the communications to their vendors, a trend that is underway. So, would each vendor have to be a clearinghouse? Would a new vendor coming into the market face a daunting challenge because it needs to develop a body of intellectual property to communicate with all the labs, PHRs, payers, health agencies and quality measurement organizations, each of which uses a different approach to RESTful Web Services?

Let’s suppose that all the various supporting specs needed for healthcare interoperation already exist in one or the other of the big vendors’ use of RESTful Web services. Is there really a standard for all that that is standard as, say HTTPS or HTML? If so, great let’s go full time ahead. If there is no standard but a lot of good experience, can we somehow put together a tiger team that looks at what’s in use and agrees on a common approach? Such a team would have to follow much of the advice we heard at the HIT SC testimony last week including:

• focus solely on the most immediate needs for fulfilling meaningful use requirements
• focus on reusing what is widely being done across many industries
• spec a little, implement a little, test a little, spec some more until you reach a stopping point
• create open source specs and code that has been tested for interoperability.

The “HTML Side”

There is also work that needs to be done on the side that is the equivalent of HTML in our metaphor. This side includes the specs that represent the payloads communicated through HTTPS for healthcare interoperability. Perhaps the most critical thing is to revisit the specifications to see whether they intermix information needed for the communications with information needed for business processing of the payload. This is a tricky business, because there is overlap. I don’t really know how much IHE and HITSP have already done to create the correct separation. Perhaps it is already done. But if not, could a “tiger team” on the payload side work closely with the communication side to sort out these issues and provide an urgent interface back to the standards bodies if any changes are needed?

Can We Create the Trust to Get This Done?

Like Sean, I see this as an opportunity to get the U.S. healthcare industry to make a leap forward on interoperability that could meet the challenge of the ARRA meaningful use criteria.

For something to come of this, various parties will have to trust a small team to do the work without the formal governance of an SDO. Developers will have to be prepared to accept solutions that require changes to their software. SDOs will have to accept the challenge to change their standards to catch up with the work of the tiger team.

The biggest problem will be antibodies created by the bile and spittle of numerous commenters in this area. Every time an advocate for a more RESTful approach refers to Electronic Health Record Association and IHE as being a cartel working to restrain trade it becomes that much harder to bring the mainstream EHR vendorsto the table. On the other side, HITSP, IHE and others need to do a better job of understanding the advantages of totally separating the two layers and be willing to give some in order to bring in the Health 2.0 crowd.

If this is going to work, all parties are going to have to accept that we need some change and we have a singular opportunity to accomplish it. They are going to have to accept that the parties they disagree with won’t go away. They must refute even their supporters who continue to play the name-calling game.

In the words of comedian Judy Tenuta, “Hey! It could happen!”

This posting was revised on 1 November based on thoughtful feedback from several people.

Soothsayers, however, should say a different sooth. Congress is clearly not looking to go back to the drawing boards. The ARRA encodes in law the approach adopted by the Bush administration through executive orders and administrative actions.

Some believe that the current approach is doomed to failure because of the lack of the aforementioned systematic framework for current interoperability efforts. Others, including me, believe that applications integration is always messy, if for no other reason than that the goal will always be to integrate systems that are in different points in their life cycle and have different information models. Successful application integration depends entirely on identifying specific scenarios that are in easy reach for a majority of systems in usage or have such a clear and measurable value to the owners of the system (not the vendors) that they will pay for the re-engineering.

In other words, national interoperability in the U.S. can not rise above rough-cut precision in the short term (say, ten years).

One can only hope that the US gets that far. Interoperability under HIPAA has been successful in a few cooperating communities but generally a disaster. HIPAA absolutely proved that the full Federal regulatory process is too lugubrious for promulgating IT standards.

The current U.S. approach is faster than HIPAA, but it suffers from one of HIPAA’s main problems, that the entity responsible for producing the specifications is not responsible for their being implemented. For some time, I have been speaking about the notion of a profiler-enforcer organization (PEOs). (Gartner clients can read a more detailed piece on this topic here.) Organizations such as Connecting for Health in England and Infoway in Canada take multiple standards, develop harmonized profiles and see the process through contracting with HIT vendors to implement them. Their charter is to get HIT implemented and standards are a part of the process. IHE is similar in that it at least takes responsibility for a full cycle through Connectathons.

The fundamental point is that interoperability is not achieved by a waterfall process, but by recycling. Early deliverable specifications are rough drafts to be tuned by implementation experience. Unless the entity responsible for creating the specs is responsible for them being used well, the feedback loop will remain open and confusion will prevail.

In the U.S., the work is split between HITSP, CCHIT, the NHIN Trial Implementation project and perhaps other implementation projects. The feedback loop is broken.

The ARRA allow a hopeful person some justification for short-term and long-term optimism for healthcare interoperability. In the short term, the language includes support for rejiggering the U.S. process so that the goal of creating actual interoperation might be under a tighter span of control.

Long term hope arises from language directing NIST to award academic grants for multidisciplinary “centers for health care information enterprise integration.” We can hope that NIST develops the grants in a way to support a more systematic look the challenges of healthcare interoperability. One also hopes potential applicants for such grants will work immediately to bone up on the excellent if incomplete work done by HL7, the Object Management Group and the National Cancer Institute in establishing a more rigorous basis for interoperability. Principles developed there can find their way into the architecture of HIT systems over time and can get us from rough-cut to a smooth finish, if not to finely honed cabinetry.