Please note: This post by the HIT Standards Committee’s Implementation Workgroup is now closed for comment. Monitor this blog for more posts from the FACA committees and its workgroups as issues develop. Also, please visit the Health IT Buzz Blog to join other Health IT related conversations.
As the HIT Standards Committee and its various Workgroups listen to the experience and advice of practitioners, standards experts, clinical system vendors and technological wizards and contemplate what recommendations to make to the Office of the National Coordinator, we often turn to look at what works in the real world as an anchor. One of the earliest principles the Committee embraced is that the standards being recommended should be in actual use – to be not only adoptable but adopted.
An example of one experience the HIT Standard’s Committee is looking at is my own experience at the Regenstrief Institute. My experiences at Regenstrief have included “lessons learned” applicable to the HIT Standards Committee, and I’ve been asked to share these lessons learned with you now.
The Regenstrief Institute has fostered clinical data standards development for more than three decades. Beginning with standards for electronic messages including ASTM [American Society for Testing and Materials] E1238, Dr. Clement McDonald then Director of the Regenstrief Institute (now director of the Lister Hill Center at the National Library of Medicine) championed the cause of clinical data standards leading to the establishment of the Health Level 7 [HL7] standards development organization which developed HL7 version 2.x which is probably the most widely used clinical message standard in the world. Another colleague of mine, Dr. Gunther Schadow, has been instrumental in designing the HL7 version 3.0 Reference Information Model (RIM). In the early 1990s, Dr. McDonald began to develop LOINC (Logical Observation Identifiers Names and Codes) in order to provide standardized codes for laboratory results, radiographic studies and other clinical observations. Finally, Drs. Schadow and McDonald led development of the Unified Code for Units of Measure (UCUM) which provides human-friendly codes for all units of measures with precise semantics to facilitate unambiguous and computable communication between computer systems used in science, engineering and business worldwide.
Good enough standards
The Regenstrief Institute began developing the Indiana Network for Patient Care almost 15 years ago, using a few simple clinical information standards – HL7 V2.x and DICOM for message formats and LOINC, ICD-9, CPT-4, and NDC for coding information. As the Indiana Health Information Exchange evolves, these same standards serve us well today with a few additions, including NCPDP message formats for prescriptions and medication histories, RxNORM for coding medications, SNOMED codes for results like “positive” and findings derived from pathology reports, and the Unified Codes and Units of Measures for units. Data were and continue to be protected in transit by using virtual private networks which were challenging to get to work in the early days and are now trivial. Of course we welcome the recent development of the National Provider Identifier (NPI), which is starting to simplify provider identification.
We have used standards permissively – applying them as rigorously as possible but adapting to what existing systems and data sources are capable of providing. Our rationale is simply that we can’t wait and the standards are good enough. Nearly every clinical system can send HL7 v2 messages, although we have begun to exchange some data in formats including the CCR. We have implemented and demonstrated our ability to generate and exchange CCDs following the NHIN implementation specifications with others, including federal agencies. However, when we tried to use these specifications to share data with some large, technologically sophisticated healthcare organizations for direct display and integration in their enterprise systems, they quickly asked for a simpler, less cumbersome approach and we returned to our tried and true suite of standards which is working well.
While we are permissive in using standards, we never “dumb down” the data. We work hard to make sure that we never lose information. It is too much work to create structured data but, again, we take data as we are able to get it.
Someone, someday has to do the “heavy lifting” to map local test identifiers and radiology study codes to LOINC codes. We do that work now in order to get the benefit now. No matter when a laboratory or radiology center switches to a new system or re-implements their existing system, this work will have to be done – there is no reason to wait. Even more important, this mapping can be accomplished in a reasonable time particularly if, as my colleague Dan Vreeman has demonstrated, we focus on the less than 10% of laboratory results that account for nearly all results.
Using these simple standards, we connect more than 70 hospitals and 12,000 physicians along with other providers, including laboratories, and process tens of millions of messages monthly. These standards are also good enough to share data between health information exchanges. Data are flowing daily between IHIE and Healthbridge, the first live exchange of information between Health Information Organizations in the country.
Of course there is more work we have to do, even in Indiana, but that is all the more reason that you should not wait for more or better standards.
Good enough tools
Providers who don’t have an EMR application can still benefit through functionality like our clinical messaging system called DOCS4DOCS® which Dr. Mike Barnes developed. Not only does it provide operational efficiencies, but it also serves as an evolving repository of clinical results with a long term archive of patients’ clinical data directed to the provider. The venerable Regenstrief Medical Records System INQuiry application and its newly deployed replacement that we call Patient Results Review, developed by Dr. Doug Martin, provides patient centric, longitudinal comprehensive access to a patient’s clinical results. Anecdotes and large randomized controlled trials have demonstrated that these simple tools are “good enough” to improve the quality and efficiency of care.
In addition to making these data available for care, we proactively monitor the state of Indiana for outbreaks of disease, ensure that reportable conditions and diagnoses are delivered to public health officials in a timely fashion, measure the quality of care that citizens throughout the state are receiving, and provide feedback to providers to help them improve the care they deliver; we monitor for adverse drug events, support clinical trials designed to new treatments, and use the data to develop new medical knowledge.
Good enough standards and good enough tools — improving care.
As the HIT Standards Committee looks to the real world, and share the types of stories we are looking for to inform our recommendations, we welcome your comments or feedback.
– Dr. Marc Overhage, Regenstrief Institute
Tags: FACA, Federal Advisory Committee Act, HIT Standards Committee, ONC
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)