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.

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.

I now face the typical Google-plusser dilemma. I want to add to the thread but I also want my thought to be public. So I am posting the blog entry and will cite it there.

There is not yet enough science to determine the one right way to do user interfaces. I doubt that there is enough science to objectively conclude trade-offs between, for example, being able to see everything at once that is on a printed cover sheet vs. using smaller or less costly devices. (It would be easy to see a standard based solely on usability principles proscribing any devices other than wall-mounted HD screens with special glasses needed to prohibit accidental viewing by non-authorized people.) I *AM NOT* making light of usability principles; I am simply pointing out that they represent one set of factors in a trade-off in selecting an EHR.

If we do have some science now,  it should go into lifting the veil of obscurity that vendors place around their usability.

USABILITY MEASURES
I propose the notion of a “usability measure.” Like a “quality measure” it would be specific and might have specific exclusions. In order to be a “measurable measure” it could not usually be generic to the entire EHR. While “all references to a patient should include gender, age and unit number” might well be a good principle, the measure for this principle might enumerate four or five situations where the patient information is displayed such as patient selection, results lists, individual results viewing, ordering and documentation and NIST criteria would include scripts for determining yes-no answers in those situations.

Experience with clinical measures has shown that going from generally agreed-on principles to computable measures is a substantial investment of time.

A public dialogue with minority representation from the vendor community should review proposed measures and categorize them into these groups:

1) So obvious it would be unethical not require this of all EHRs. The criteria for inclusion in this group should be very high.

2) Likely to be important factors; submission to the measure should be required for EHR certification and the average across all submissions be published. If a certified product is purchased by a health delivery organization and the vendor failed to provide its own scores before the HDO was committed to the product, that HDO should be ineligible for receiving the benefit of meaningful use incentives (bonuses now, relief from penalties in the future).

3) Candidate measures; submission to the measure should be required for EHR certification but there is no requirement for EHR vendors to provide their scores. Anonymous scores would be published so that healthcare industry could see the spread of how products performed on the measure.

4) Worthy of further study; the measures should be published as fodder for study, no scripts are prepared and testing does not occur as a part of certification.

OTHER REGULATORY ACTIONS
Given threats to patient safety based on usability, any EHR that is purchased under a contract that includes a “usability gag clause” should be ineligible to benefit under the incentive program. Such a clause would penalize the client for speaking publicly about the usability of the product. Vendors have justifiable concerns about a minority of irresponsible who will make up or exaggerate such issues in order to put pressure on the vendor on some unrelated point. They also have justifiable concerns about “Internet warriors” who take every public dialogue as a no-holds-barred battle for attention and dominance. Nonetheless, the greater good for healthcare and patients is achieved by favoring transparency. All of us are Internet users and we are learning to glean the gems from the crud.

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

The HITECH act requires separate rules for accounting for disclosure under HIPAA when the disclosures are made from an EHR. The notice of proposed rule making (NPRM) is now on public display. It will appear in the Federal Register this week. The 60 day comment period closes approximately Aug 1. Enforcement will begin 8 months after the issuance of the final rule. The final rule could be issued as early as Sept 2011 but may be delayed substantially longer.

It removes certain exemptions on accounting for disclosure if the disclosure occurred through an EHR.

Definition of EHR

The NPRM quotes the following from the HITECH act:

Section 13400 of the HITECH Act defines an electronic health record (“EHR”) as “an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff.” Under section 13405(c), an individual has a right to receive an accounting of such disclosures made during the three years prior to the request.

One gets the sense that the Office of Civil Rights (OCR), which develops rules for HIPAA, believes that certified EHR technology provides a control-point where all outgoing electronic information from a hospital or practice can be logged for reporting on disclosures. This ideal is rarely true. Most hospitals have a dozen or more departmental systems from specialized vendors that are not routinely certified as modules of an EHR under the HITECH rules. Frequently the specialized systems are highly integrated with special imaging hardware for specific procedures such as endoscopy or spirometry.

In the era of meaningful use and ICD-10 it might be worthwhile to catalog the  vendor products that are likely to require upgrades or special new integration in order to meet the new accounting requirements. Then it would be helpful to provide estimates of the cost and staff expenditures required in comments to the NPRM.

Data is far more persuasive in NPRM comments than opinion.

In commenting, give special attention to the possible enforcement deadline, which could be as early as 1 June 2012.

Real usage started about ten months after the project started and continues to grow. The next step is providing more widespread discovery of end-point addresses (a 411 service). The ONC S&I framework team has kicked off an intense effort to find a solution that could be included in an NPRM for Stage 2 of Meaningful Use. As with the original Direct project, the hope is to bust through previous expectations of how long something like that would take by “keeping it simple.” One of the complexities one hopes to avoid is creating a single national resource for looking up providers. While that is a valuable goal it is very complex and potentially expensive. One approach is to allow multiple sources (such as the states) to each offer a resource and develop a standards scheme to “confederate” them so that one wouldn’t have to query many different services each with its own user interface.

A Modest Proposal

I have been talking about this with David McCallie, my co-conspirator in the original push for simple interop. We have been looking for a truly fresh approach. We have a modest proposal here. Like the original simple interop approach, this proposal leverages the strengths of the infrastructure that is already in place in support of many non-healthcare usage. It provides for confederation and a uniform user interface in a novel way.

Requirements

On 24 May in A Strawman HIE Directory Solution John Halamka bloggedset forth the longer-term business requirements suggested by the work of the HIT Policy Committee. I am going to restate them in my own language in part to avoid the use of the word “discover.” This word seems to be adding confusion to the email thread that followed his publication.

• Support directed exchanges (send/receive as well as query/retrieve)
• Provide basic searching to find an organization  – including demographic information and Direct address. Demographic information may be part of the search criteria or may be returned when a target is found.
• Having found an organization support retrieving information about exchange services (e.g., lab orders or results reports) and the standards required by the receiving system (e.g., mail, CCD, HL7 2.xx)
• Having found an organization support retrieving its security information (that is, it’s digital certificate).

The last requirement is a bit controversial. I’ll get that below.

To these stated goals I would add:

• Provide a reasonable assurance that the information that is found is not bogus.

The Proposal

Anyone can put up a Web page that describes his or her practice. (For reasons explained below small providers will probably rely on their HISP.)

The web page is free-form but contains mircroformat information that identifies various demographics, license level (self-declared), Direct Address and perhaps public cert. (Presumably ONC has the clout to get at least Google and Microsoft/Bing to agree on the Microformats.)

The web page must be protected by an Extended Validation Certificate such as is used for Webtrust. (The HISP can spread the cost of this over numerous small providers.)

The web page is freely available which makes it available to major search engines.

Organizational entities can put as many end-point entities as they want on the web page. (People, systems, common receiving queues, etc.) Or they can use one page per entity. There are no rules other than the use of a specific microformat.

Any person can use a search engine to discover a provider’s direct address and the provider’s public cert.

Presumably various folks would develop free-plugins for browsers that would indicate valid or invalid pages according to the extended validation certificates.

Given a definitive search key, such as a direct address, a HISP can discover the digital certification of a provider. It can validate the source of the information by the extended validation certificate. (It is questionable whether this is necessary, as will be discussed below.)

“Happy Paths”

Low-tech healthcare providers can use Web searches to discover the direct address of providers with reasonable assurance that the provider has managed to convince a HISP of its validity. Existing microformat-based integration with address books seems plausible.

HISPs may compete to improve the workflow for low-tech providers but there is no need for standardization in this area.

EHR-based healthcare providers have access to the low-tech approach, copying and pasting direct-addresses into the EHR equivalent of an address-book. If individual EHR vendors want to improve the workflows they have access to the APIs of the search engines and browsers to build whatever workflow they want. There is no need for standardization in this area as long as it is possible to paste a direct address into an EHR screen for a newly identified provider.

“Unhappy Paths”

In theory anyone can put up a web page with an email address and a digital cert. The extended validation certificate makes this an expensive proposition, but certainly within the budget of an organization that has set out to capture and sell protected health information. This concern can be addressed if there are requirements on the digital certificates that assure that they were issued by a trustworthy organization. The current HIT Standards Committee recommendation is that all certificates be traceable to a certificate authority that is cross-certified with the Federal PKI bridge. Under this or a similar approach, the HISP would refuse to forward Direct traffic to the bogus address because it would not have a qualifying certificate.

Spammers would have easy access to all direct addresses. As above, though, a spammer would only be able to use the direct address if it had its own qualifying digital certificate. Such a certificate could easily be revoked in the light of obvious spam.

Consumers would be confused finding email addresses to which they could not send mail. This can be solved by using a microformat that does not require that the direct address be rendered with the HTML page.

Advantages of This Approach

“Federation” is automatic through search engine technology.

Responsibility for creating listings lies with the provider or the provider’s HISP.

Modest investment and minimal development for HISPs. Virtually no investment required for EHR developers.

Does not require a a top-level domain which, IMHO, would take 1-2 years to get set up if there is serious credentialing associated with the issuance of TLD locations.

Except for some minor microformat work this relies entirely on existing technology that has been deployed at scale. In fact it relies on using the current deployments; there is no need to fund and deploy major new services.

Easily describable for the NPRM.

Easily testable for ATBs (assuming there is something to test).

Future Considerations

ONC could sponsor the development of a simple ontology of types of end points and microformats for describing them. Presumably it would want to address the service offered (e.g., receive lab orders) and perhaps some expression of the incoming standards supported. The actual information would be posted on the Web page by the practice or HISP at their own peril if they get it wrong. However, this is the future (i.e., beyond the NPRM for Stage 2 MU).

At that point standards and certification for EHRs would involve validating that the putative destination for a transaction is valid and can receive a transaction with the purpose and in a format that the EHR can send.

EHRs could also be required to offer compatible targets for inbound transactions.

Filling in Some Details

If the reader is not familiar with microformats please read the link. They are incredibly simple rules for formatting information with a web page so that its content can be understood by programs that accept the  HTML web page as data. Try looking up a few recipes that are referenced on the site or some addresses. You will realize how much your smart phones and search engines have been using this technique to make your Web life easier.

In any modern browser if you open up most bank Web sites (e.g., https://www.bankofamerica.com/) you will see a colored padlock that shows up in the browser’s address bar. This is a visible indicator of the extended value certification. While most people (including providers and their staff) don’t know what that means, it would be easy to make plug-ins available for common browser that provide highly visible flags of specious web pages. A specious web page would be one that included this microformat but wasn’t protected with an extended validation cert.

There is substantial controversy on whether the requirement to return a digital certificate is valid. The current Direct software gets this certificate through the Internet Domain Name System (DNS). The most widely used DNS software, the open source ‘bind’ package, supports the current Direct scheme. However the DNS product offered by Microsoft does not. The Hatfields and McCoys of the Direct world characterize Microsoft’s lack of support as being either an insurmountable stumbling block or of little consequence. The open source .NET implementation of Direct works fine because it relies on bind rather than the Microsoft DNS code. Whatever the conclusion of this issue, the main value of this approach is achieved whether digital certs are stashed in the microformat or retrieved through the DNS.

Amended 27 May 1230 EDT to correct a URL.

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

Tell ‘Em What You’re Gonna Tell Them

Here are the conclusions and recommendations included in this post.

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

Tell ‘Em

At page 72 the PCAST Report says

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

This statement has created a great deal of controversy.

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

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

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

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

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

In fact, all of these statements apply:

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

Atoms and Molecules

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

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

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

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

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

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

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

How many molecules and radicals are there?

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

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

What names do the serious folks use for molecules?

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

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

Molecules as Aids to Interoperability

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

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

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

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

Molecules and Documents

What is the relationship of a molecule to a document?

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

Clinical statements in isolation.

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

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

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

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

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

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

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

The Importance of Partially Coded Documents

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

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

Is it More Important To Standardize Molecules or Documents?

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

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

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

Directly after the statement cited above the PCAST Report says:

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

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

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

Tell ‘Em What You Told ‘Em

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

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