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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NIEM Overview

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

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

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

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

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

This is a sexy presentation and a  great use of simple and effective collaboration. More important, it is a massive job to get this data and keep it up to date. I know from my HL7 days how bloomin’ hard it is to compile information like this. Gartner clients should know that this is one of the data sources I used in preparing some technology profiles for our Hype Cycle update that will come out this month.

I encourage folks using CDA or XDS to collaborate through the means Keith has set up.

As with excellent surveys done by the eHealthInstitute the most significant one must always keep in mind that this is self-reported data. This means that networks will be shown as operational sooner than some might like. For example,  some networks might show green as soon as PIX is operational before there is substantial data. An additional challenge is dealing with the odd project that gets dissolved or significantly reworked and renamed. There is little motive for the folks that originally provided information to update the poll. eHI has developed a methodology for pinging and treating unresponsive networks in a special status.

Picky analyst issues aside. the map is a great resource. Keep up the good work.

On the outside chance that someone does not know Kieth, he blogs at http://motorcycleguy.blogspot.com/

The question is how SMTP as the preferred transport mechanism reconciles with the EHR certification criterion (in the IFR) that requires certified EHRs to use either SOAP or REST for HIE (i.e., §170.202 Transport standards for exchanging electronic health information).

Just sign me “Puzzled in Peoria”

Dear P in P,

First, let’s be clear. I speak for no-one. What I am saying hear does not cite an official position of the ONC, it is not a consensus position of the NHINDirect org, and so on. I speak as an individual who is a self-avowed cheerleader for NHIN Direct.

The certification requirements do not limit healthcare organizations to using the standards on which software is certified. They really only say that if a healthcare delivery org buys or builds software and wants to get incentive money for meaningful use the software has to be capable of using the standard (i.e., pass certification tests).

For example, MU requires a provider to get 50% of the lab results in structured form. An HDO could meet the requirement by sending CDs by courier and still qualify for the MU incentive money, as long as they uses software that could have accepted data according to the certification requirements were it asked. Certainly all the people that currently receive data through sources that do customized links to their EHRs are not going to have to re-implement their interfaces in order to get MU incentive money.

Part of the positioning of NHIN Direct is that it is metaphorically a “try before you buy” opportunity. ONC is facilitating activities that produce specifications  they might choose later. The “buy” would happen, for example, if a stage 2 certification rule were to incorporate the actual specs developed by NHIN Direct. The “try” is what happens when NHINDirect participants put the interfaces in place and actually begin to use it. If the “try” shows rapid uptake, the “buy” is more likely to happen.

It is also important to keep in mind that NHIN Direct is not directly comparable to existing standards that are certified. It is designed to encompass cases of “clinician to clinician” (rather than “clinician’s EHR to clinician’s EHR” over email and “physician to patient” (via PHR). It is also designed to require less elaborate governance and less complex technology because it sidesteps many of the consent issues that encumber HIEs.

(signed) Abigail van Bureaucrat

Dear Abby,

The convergence proposal accepts SOAP and REST at the edge as inputs from the EHR, so the convergence proposal is completely consistent with the IFR as written.

(signed) Halamka from the Hub

Dear H from H,

OMG! How cool. Wish I’d thought of that.

BFF Ab van B’rat

Revised 26 June 2010