Nick, that is exactly the point. We only have one year to do this. Creating libraries, testing and agreeing on terminologies and then testing on a large scale will take longer than a year.
There is an optimal size of company that could quickly adapt to new standards. Companies that are too small to have a few person-months available will fail to meet the deadlines. Companies that are too big and currently operate thousands of interfaces based on existing standards (like national labs), face different challenges and will most likely also be unable to convert in time.
Then there are the terminology issues that seem to also add unnecessary hoops. We have to switch from ICD-9 to ICD-10, knowing full well that we will need to move to SNOMED shortly thereafter. How efficient is that?

I just don’t see the need for constantly placing more and more hurdles in the road. As it is, most studies show that very few provider organizations will be able to meet the interoperability requirements in the allotted time.
Assuming we really want interoperability to be widespread and adoptable by big and small entities at short notice, there is no better way than using the current means and infrastructure to make a start.

If you want to get from point A to point B as fast as possible and the roads are narrow and rather old, you don’t blow up the old mountain road and build a 4 lane highway before you undertake any travel. You rent transportation that can move on the existing road, even if it means ridding donkeys for a while.

Hot debate. What do you think? 13  10 (+3)

In the testimony of the implementation panelists to the Implementation Workgroup of the HITSC, I commented, as did many other panelists, that the biggest barrier to interoperability is not the data formats, but what Adam Bosworth called the encodings — the core medication, problem and lab terminology. If we have the encoding correctly defined, you can give me an active medication list. That active med list can be expressed in CDA, in HITPS 32 formatted CCDs, in a CCR, in an RDE HL7 V2 message, in a custom JSON format, in an NCPDP SCRIPT RXHRES, in a CSV data set, if you and I agree that this is an active medication list, and you and I agree on the encodings, we can do really interesting things to improve health care.

An active medication list is not a deep concept. If I have to understand the RIM to send and receive an active med list, we are placing large barriers to the developer community. My position on this is: let’s agree on the encodings, let’s agree on the simplest representation of the high value components (med list, medication allergies, problem list, clinical results), and build our systems on that. If we can routinely accomplish continuity of care with a unified, reconciled record containing medication, med allergy, clinical results and problems for most of the patients in the US, then we can move on to more interesting things that require a sophisticated model based approach.

Agree or Disagree: 16  9 (+7)

Dr. Overhage’s preference for standards that have been proven in actual use is a very important and practical consideration. In a strategy of taking simple, achievable steps, each of which provide value and move us in the direction of our ultimate goal, such standards are excellent candidates.

Two of the steps for a Standard on the road from shelfware to having tangible benefit in the healthcare system, are getting it correctly implemented by vendors and then released in products.

IHE has two databases which may provide some useful data for tracking those steps.

http://connectathon-results.ihe-europe.net/

IHE has been testing conformance to interoperability standards at annual events called IHE Connectathons since 1999. The European branch of IHE maintains a database of successful tests of various IHE Profiles over the last 9 years, including North American, European and Japanese events. Roughly 300 companies are represented in the testing.

The Advanced tab lets you filter, slice and total the data a few different ways so you can, for example, observe the rate of vendor adoption for a specific profile over the years, or see where current attention is focussed, or see which profiles have had good traction and which have not.

The early years focussed on data sharing and workflow in medical imaging using DICOM since it was considered lower hanging fruit due to fewer issues with differing message structures and nomenclatures. Subsequent years expanded testing to systems related to IT Infrastructure, Lab, Cardiology, Radiation Oncology, Eyecare, and Patient Care Coordination data. Most recently testing has begun for patient care devices and quality metrics.

http://product-registry.ihe.net/

IHE Integration Statements document the support of specific IHE Profiles in specific versions of specific released products (as opposed to the Connectathon results which include products, prototypes and middleware).

Although searching the Internet for the phrase “Integration Statement” will turn up a large number of such documents, it can be difficult to isolate particular types of systems and tedious to tabulate the rate of adoption.

IHE has established a Product Registry database to make that easier. Since the registry was just opened, it is sparsely populated, but we expect it to fill out over the coming year.

The HIT Implementation Workgroup may have a unique opportunity to collect information on the subsequent steps of standard implementation, i.e. tracking system installations, usage of features, efforts to adapt local workflows and quantified impacts on healthcare.

Regards,
Kevin O’Donnell

Agree or Disagree: 23  15 (+8)

Hi David,

I don’t agree with your analogy. Cars and Trucks can generally use the same roads. I think a better analogy in this case would be 2 trains systems, one with 24″ rails, and one with 20″. The 24″ trains might use slightly more fuel (and hold more cargo). However, the fuel cost is worth it. In general, supporting 2 rail systems requires that there are 2 sets of train tracks everywhere. In some cases possible to build a type of train that has both 20″ and 24″ axles (eg CCD), but its a lot of extra work, and it means that those people that only have access to a 24″ track, can’t send stuff to a person who has 20″ track, and vice/versa.

Those that have done both CCD and CCR tell me that the difference in development effort is perhaps about 10%. This is the extra ‘fuel cost’ for a few developers but saving that 10% can hardly justify the effort for the bulk of readers and most senders (not to mention dependent standards) to support both because they can’t count on the other guy being able to speak the same language.

In short, having 2 standards here means that you no longer have a standard. It destroys the capability to communicate and/or increases costs dramatically.

Agree or Disagree: 31  24 (+7)

Dear Colleagues: Let’s not lose sight of the fact that the goal of all our efforts around standards for health data exchange is to improve patient care, the quality of care, the safety of care, and the efficiency of care. There’s an imperative here that is inescapable: if health data are more easily accessible across institutional and business boundaries, not just within the walls of large enterprises, then health care decisions are more likely to be informed by current and up-to-date information, mistakes will be reduced, waste will be less common, and quality will improve. Information MUST become capable of crossing health care institutional boundaries, because that is what patients/consumers want and need, and that is what will lead to a national health information network that is cost-effective and scalable.

I applaud the Obama administration’s health team including staff at ONC and HHS to revisit health IT standards with an eye toward what works in other sectors of the economy, and to bring up the question as to who will get to control health data exchange: everybody including consumers and their doctors, or just large provider organizations. The public debate will be necessarily couched within the terms of privacy, security, and the adequacy of current exchange standards. But what really matters is who gets to make the decisions about our health data whereabouts, accessibility to the data, how much exchange will cost, and how long it will take to become routine. In other words, the fundamental notion we’re debating is how far to democratize health information, why this direction might well improve care and lower costs; and who will benefit and who will not.

The CCR standard vs. CDA CCD debate is symbolic of two mutually interdependent and complementary systems of care, the first representing the broad use of the Internet and World Wide Web for health data exchange principally concerned with wellness, prevention, and chronic illness management, and the second representing the institutional and enterprise settings where complex and critical care is delivered. Both these environments ought to be permitted to flourish with regards to health data and informational exchanges, but neither ought to be able to impose its requisite informational exchange conventions on the other, because that would not be in the public interest.

To make an analogy, the CCR standard is like a small and efficient hybrid auto, good for scooting around when the goal is safe transportation on all sorts of roads. The CDA is a large pick up truck, which uses up more fuel and isn’t very agile, but can carry a lot of different payloads, some of them quite heavy, e.g. inscribed masonry. One of the payloads the CDA is capable of putting into its pickup bed is the agile, lightweight CCR. Fine. But it makes no sense to come along and require that the ONLY way the CCR can be used is when its being carried by the CDA. Different tasks, different environments, different but complementary standards.

All in all, the market’s experience with health data exchange in open systems like the Internet is still early and immature, and so it makes little sense for the government to overdetermine the content, messaging, or transport standards that are available for use and continued experimentation.

Kind regards, DCK

Agree or Disagree: 44  38 (+6)

HL7 has proven very effective for GetWell as we’ve supported our 60+ hospital clients in leveraging their ADTs, EMRs (currently interfaced to most major Orders and Documentation systems), eMARs and other systems to create a meaningful connection to patients at the bedside. Our solution transforms the television in the patient room into an interactive tool. With the benefit of information coming through interfaces and read/write capability, Interactive Patient Care enables patients to become more involved in their care process. Further, our technology allows staff to prompt the patient to get involved in their care (e.g., communication regarding discharge planning, education on Joint Commission/CMS requirements, etc.).

Beyond the comment regarding HL7, I want to emphasize the importance of ensuring that standards and frameworks incorporate accessibility of information/process in the patient room (whether through the patient television or otherwise). In the absense of interactive tools at the bedside there are two alternatives (1) patients will continue in vacuum and removed from their care or (2) interaction will remain fully dependent upon human intervention (in a world of declining resources and increasing demands on inpatient staff).

Agree or Disagree: 13  7 (+6)

In theory the XSD files are not normative, but in practice that’s what everyone uses (at least as a starting point). In some cases the XSD files are slightly modified while still maintaining consistency with the underlying specification.

Hot debate. What do you think? 12  9 (+3)

There are still a bunch of “myths of the marketplace” concerning HL7 v3. I will arrange to have a presentation of mine from 2007 posted at a convenient website so folks can look at these, and my explanations of the mistakes and misperceptions about HL7 v3 that each ‘myth’ is based on.

Agree or Disagree: 12  7 (+5)

CCD contains the same basic data constructs and similar valuesets to CCR, but I disagree that this is completely mappable via XSLT. The idea of bi-directional lossless transforms was discussed in the development of CCD, but this was explicitly excluded from the scope. This was because there were fundamental differences in data models that could not be resolved. I don’t remember the explicit examples, but do recall that some values were structured in CDA, which were unstructured or precoordinated into the terminology in CCR and vice/versa. Also, CDA allows for a richer expression of null values as I recall. I have heard some say that they can map about 90%. But, don’t expect that you can move back and forth without data loss.

Agree or Disagree: 21  17 (+4)

CCR seems like kind of a dead end. It only addresses a single limited use case, and is still fairly complex. Why put effort into CCR when with just a little more work you can support CDA (including CCD) and have a solid foundation for the future? For most implementers it won’t even be necessary to support the complete CDA R2 specification, a large subset is enough for most use cases.

Agree or Disagree: 34  17 (+17)