Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Does XML Schema Earn its Keep?

by Wes Rishel  |  December 28, 2011  |  6 Comments

Keith Boone continues his campaign to make V3 comprehensible with an excellent post on ordering in XML schema and an idea that could overcome one of the fundamental flaws in the “extensible markup language” — the requirement for all parties to switch simultaneously to a new schema version in order to extend the schema. I hope HL7 as a group will consider his idea because the ability to do unsynchronized upgrades is critical to the roll-out of any standard at large scale.

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"},
     [ {"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.
<firstName>John</firstName>  <lastName>Smith</lastName>
    <streetAddress>21 2nd Street</streetAddress>
    <city>New York</city>
  <phoneNumber type="home">212 555-1234</phoneNumber>
  <phoneNumber type="fax">646 555-4567</phoneNumber>
<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"/> 

Updated 12/29 to correct omission of JSON example in original post.


Category: Healthcare Providers Interoperability Vertical Industries     Tags: , , , , , ,

HL7’s Position on CIMI

by Wes Rishel  |  December 15, 2011  |  7 Comments

Gary Dickinson raised an important issue in commenting on my post. He said:

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.


Category: Uncategorized     Tags: , , , , ,

At Last, Data Molecules! CIMI

by Wes Rishel  |  December 13, 2011  |  3 Comments

Last February, I blogged on “data molecules,” low-level models for clinical concept that are not buried in the obscurity by conformance to a grand and abstract uber-model. These models are often called Detailed Clinical Models or Clinical Element Models.

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.


  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.


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


Category: Healthcare Providers Interoperability Uncategorized Vertical Industries     Tags: , , ,

ELINCS: Doing Lab Orders Standards Right

by Wes Rishel  |  December 8, 2011  |  3 Comments

On Wednesday the California Healthcare Foundation published Request for Proposals: Using Electronic Data Standards to Communicate Laboratory Orders.

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


Category: Healthcare Providers Interoperability Uncategorized     Tags: , , , , , ,

Three Steps to US Semantic Interop

by Wes Rishel  |  November 20, 2011  |  Comments Off

Nothing warms a blogger’s heart more than to get meaningful comments to a post. In Semantic Interop, the C32 and the Consolidated CDA I described the results of the biggest U.S. experience to date to achieve semantic interoperability among EHRs with different data architectures. I also said I would write more on what could be done to improve interoperability. I was delighted to see that all the comments anticipated the direction I had in mind. Three important questions are:

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


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.

Comments Off

Category: Uncategorized     Tags: , , ,

Semantic Interop, the C32 and the Consolidated CDA

by Wes Rishel  |  November 17, 2011  |  4 Comments

Gartner Symposium last month had the finest showing of healthcare clients we have ever seen. A signature feature of Gartner symposia is 1-on-1 sessions between individual clients and Gartner analysts; several of mine were eye-opening discussions on the work required to achieve interoperability between multiple EHRs in the joint DoD-VA Virtual Lifetime Electronic Record (VLER) and to achieve interoperability among the early participants in the Nationwide Health Information Network (NwHIN). The clinical specification for exchange was the C32, a HITSP profile of the HL7 continuity of care document (CCD). There were many problems where the parties involved discovered they had each interpreted the specifications differently. In order to get the interfaces running the participants ended up creating a multilateral “harmonized” interpretation of the C32.

As is often the case, errors in interpreting the specifications often are not detected by the receiving EHR. Instead, the receiver simply omits a datum or files it in the wrong place in its database. The errors are only uncovered when someone looks at data on the screen and says “that’s not right” or “they didn’t send us the information the said they would.”

I have since talked to enough other people involved in achieving semantic interoperability based on the C32 to be sure that the problems are endemic to the C32 and not attributable to any one project. In each bilateral or multilateral project it has been necessary to use testing to discover differing interpretations and to have meetings to create harmonized versions.

It is important to emphasize that these differing interpretations of the C32 did not represent incompetent programming. The programming staffs supporting most EHRs were well-skilled with XML and understood how data was represented in their own EHRs. Difficulties arose in interpreting the C32 to decide how to place data within the complex XML used to represent the CCD. Indeed, some times each side had what appeared to be a valid interpretation of the spec. When they differed the process of deciding which was right was a bit like Talmudic disputation, with the rabbis being the analysts of each firm and the sacred documents being the four or five different documents that had to be used simultaneously in order to find interpret the C32.

In Set the Record Straight about NwHIN Experiences There may be more than two dozen EHRs exchanging C32s for semantic interoperability now. However, the process of bilateral or small-group multilateral harmonization is not scalable to cover EHRs serving thousands of health delivery organizations.  Systems A and B have agreed on one harmonization spec and systems C and D have agreed on another, there is no reason to believe that A can interoperate with C or B with D.

Fortunately HL7, IHE and The Story Project http://www.healthstory.com/index.html have been working on a systematic improvement in how CDA documents are specified that. The new approach, called the Consolidated CDA (CCDA) includes a respecified CCD. It is completing ballot and will be available in time for meaningful use Stage 2. It includes numerous improvements:

  • The specs are consolidated in a single document .
  • The specification of X-paths for data items is more specific, reducing the possibility of alternate, valid interpretations
  • There will be an appendix that maps in the specification standard business names, making it easier for a programmers that know their EHR’s database and XML to figure out the appropriate CDA X-path
  • The way specific data is represented is consistent across different document types, so programmers that have developed a CCD will be able to carry their experience over to discharge summaries.

This is excellent work. I hope it works out well. (The tentative nature of this comment is because the only real proof will occur when interoperability testing occurs based on the new approach.)

Kudos also must go to Doug Fridsma at ONC for helping to cut through red tape that gave rise to the multiple documents construct in HITSP.

The CCDA is a big step forward, but it is not the whole story. One senior architect involved in the VLER effort has estimated that projects based on the CCD in the CCDA will find 50% fewer problems during interoperability testing. That is still not enough to reach large-scale interoperability, without bilateral or multilateral harmonization documents.

In future blogs I hope to suggest actions that ONC should take in the time frame of Stage 2 and actions that HL7 should take to further streamline the work of interface writers in the long term.


Category: Uncategorized     Tags:

Occupy Spec Street. Set the Record Straight on NwHIN

by Wes Rishel  |  November 17, 2011  |  Comments Off

Are you tired of government not listening? Here is your chance to set the record straight on the NwHIN. You don’t have to live in a tent or pound a drum. You can sit comfy in a chair and pound a keyboard.

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.


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

Comments Off

Category: Uncategorized     Tags: , , ,

Gartner Symposium: 10,000 of My Closest Friends

by Wes Rishel  |  September 26, 2011  |  Comments Off

Recently I have been peer-reviewing my colleagues’ presentations for Gartner Symposium 2011. Those of you who have attended know that it mostly dedicated to IT in general, attended by roughly 10,000 CIOs and their direct reports across all industries and government. Sunday October 16 in Orlando we are doing a track specifically for healthcare providers and payers.

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.

Comments Off

Category: Healthcare Providers Interoperability Vertical Industries     Tags: , , , , , ,

Can Consumer Friendly Terms Ever be Standardized?

by Wes Rishel  |  September 11, 2011  |  2 Comments

Some involved in the search for an Entity Level Provider Directory are advocating for an approach that relies on search engines like Google and Bing and a modest approach to standardizing data using microdata while others are arguing for a more structured and rigorous approach based on a highly federated use of LDAP.

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?


Category: Healthcare Providers Interoperability     Tags: , , , , ,

Lessons From the Putative Failure of HL7 V3

by Wes Rishel  |  August 16, 2011  |  4 Comments

Graham Grieve, a major participant in HL7 standards writes HL7 needs a fresh look because V3 has failed.

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.


Category: Healthcare Providers Interoperability     Tags: , , , , , , ,