Hearings on Message Format Standards

March 29, 1999

Department of Health and Human Services

Room 705A, Hubert H. Humphrey Building

200 Independence Avenue, SW

Washington, D.C.

Charles C. Meyer

Informatics Standards Liaison

McKesson HBOC, Inc

Voice: (407) 831-8444 Ext. 2191

Fax: (407) 831-9958

E-mail: chuck.meyer@hboc.com

Dr. Cohn, Mr. Blair, members of the work group. My name is Chuck Meyer. I am the Informatics Standards Liaison for Mckesson HBOC, Inc. McKessonHBOC greatly appreciates the opportunity to address the Work Group on Computer-based Patient Records. In my position as Informatics Standards Liaison I am an active member of the several standards development organizations specific to the provisions of administrative simplification defined in HIPAA and monitor a number of other organizations promoting standards within healthcare. I also represent McKessonHBOC on the ANSI Healthcare Informatics Standards Board and the US TAG to ISO TC215. Internally I function as a consultant to our various development organizations on matters pertaining to the identification and implementation of appropriate informatics standards within our product suite. I also work closely with our product management organization to further our goal of seamless system integration.

McKessonHBOC’s Information Technology Business provides a comprehensive set of cohesive systems and services for both the provider and payer environment of the healthcare enterprise. Provider and payer organizations seeking improvements in healthcare quality, delivery, and cost have consistently chosen McKessonHBOC product solutions and services. As the preeminent vendor of healthcare systems solutions, McKessonHBOC continues to be an active participant in the evolution of both administrative and clinical standards for healthcare systems. Taking a pragmatic view, McKessonHBOC recognizes both the value added of supporting industry standards and the cost saved in developing and implementing standard solutions.

Although the vast majority of our products capture and maintain some level of patient information, several are specifically focused on the vast array of diverse information that forms the patient medical record. Of particular note is the Pathways Smart Medical Record^® (Pathways SMR^®); a comprehensive ambulatory patient record for clinical management of information access, patient documentation, workflow, and communication in the physician practice. Pathways SMR provides an extremely rich data entry/data capture environment supporting point-and-click (via pen or mouse), keyboard, voice annotation, images/attached files, sketches or scanned files, and the importation of electronic transcriptions. This ability to capture virtually all patient medical record information is coupled with a wealth of product features (unparalleled access to patient records, a comprehensive medical knowledge base, and clinical decision support among others) to create an application designed specifically to provide a viable tool for electronic health records at the physician practice level, generally the least automated sector of the healthcare environment.

I have conferred with a number of colleagues, including Mark Taragin, M.D. product manager for Pathways SMR and Dan Russler, M.D. vice president for clinical strategy, in an effort to address those issues put forth in your invitation letter of March 17, 1999. In our view patient medical record information (PMRI) encompasses the entire content of today’s ubiquitous patient "chart" in all its various permutations. It is inclusive of literally all healthcare information; from the patient’s medical history and initial assessment to the record of conversations with and/or about the patient to the typically extensive documentation associated with an encounter, visit, or episode. It includes the full gambit of administrative, financial, and clinical data representing a patient.

The work group’s use of the word "comparable" relevant to PMRI is interesting. As a vendor we go to great lengths to establish working standards for our products that will facilitate interoperability. Sharing PMRI across the enterprise is a critical component of improved patient care and cost reduction. We are in reality striving to reach these goals by comparing information. Comparing patient data, comparing procedures and outcomes, comparing data in all its various combinations to support critical decisions about patient care, bring about improvements in healthcare administration, and drive advances in medical research.

However, these lofty goals are attainable only when the data is truly comparable - apples to apples - and achieves a level of precision that promotes trust in the data being compared. PMRI must be discrete data; i.e., recorded at the element level. Only such elemental data lends itself to analysis and comparison. This is not to say that aggregate data doesn’t have its place. However, the process of aggregation must start with elemental data and must be closely controlled to retain the meaningfulness and usefulness of the aggregate. It goes without saying that decisions based on inaccurate or imprecise data may be skewed, glaringly wrong or worse, life threatening.

To be truly comparable such elemental data must be based on a standard terminology geared toward evidence-based medicine. This statement is easily defended based on our experience today; however, it is utopian and clearly unattainable given the state of today’s vocabularies. It is widely recognized that no single vocabulary exists today sufficient to the task of encoding the full spectrum of PMRI. However, we are encouraged by and continue to closely monitor the initiative undertaken by the National Health Service in the UK to create a national health information infrastructure. HIPAA may provide the impetus to undertake a like initiative in the United States. The recommendation of the Secretary, based on information from the NCVHS, will set the stage for continued work in the area of vocabularies. However, we still have significant work ahead of us.

There are a large number of syntax available or evolving that will support the exchange of PMRI. Each must be considered within its inherent domain. Object-oriented technology shows much promise in the client-server/desktop environment; however, it has little or no applicability to the large number of legacy systems still in use throughout the healthcare enterprise. HL7 has developed a rich transaction set for communicating PMRI, but it is by design a transport mechanism; a carrier of information between applications. HL7 is widely deployed and generally provides the format for PMRI employed in a variety of syntax including object-oriented technologies. Its data dictionary is often selected as the initial component upon which PMRI and clinical data bases are constructed. It may be considered the glue that cements the process of PMRI exchange.

However, HL7 Version 2.x is more analogous to Post-It-Notes™ than to epoxy. It provides an agenda for negotiation among applications wishing to exchange PMRI. Even so it was well ahead of the competition and user demand dubbed HL7 a de facto standard long before it achieved accreditation. The private sector, represented by the polyglot membership of HL7, is well along the road to removing the ambiguities and improving the robustness of the standard. McKessonHBOC, as with most organizations involved in HL7, is excited by the progress being made on Version 3.0. It represents a quantum leap toward plug-and-play PMRI exchange. Being technology driven, VERSION 3.0 has chosen Extensible Markup Language (XML) as its primary syntax. This evolving technology is significant in that it allows inclusion of meta-data in the context of the message content. The strength of this functionality was demonstrated in a pilot project at the recent HIMSS conference. The extensive "lessons learned" dialogue arising from this project will go far toward bringing closure to the initial release of the next generation of PMRI standards. As with most current technology, there is some concern over support for XML by legacy systems. Although the parsers for XML are generally available at little or no cost, they are dependent on Java to operate. Not directly supported by most legacy systems, the development and deployment of virtual Java machines has this support to a number of legacy systems and gone far to alleviate such concerns.

As we’ve heard, the bedrock of VERSION 3.0 is the Reference Information Model (RIM) which has been in development, or more appropriately evolution for several years. By demonstrating the data content, grouping, and relationships within the healthcare environment the RIM provides a graphic representation of the enterprise and the basis for the development of messages supporting the exchange of PMRI. McKessonHBOC recognized the applicability of modeling the enterprise early on. Its Healthcare Enterprise Model was one of several public and private sector models that formed the basis for the RIM. We continue to work on improving, integrating, and harmonizing both our own model and the RIM to further the implementation of VERSION 3.0. I highly recommend a review of the HL7 Message Development Framework (MDF), which is undergoing revision for 1999, for an better understanding of how the modeling of data, process, and interaction drive the development of message format standards. The only impediment to extending the scope and applicability of the RIM is the continuing harmonization of the various models available today. The government can support this process through participation. Making the DOD, VA and public health models available and promoting the harmonization of the RIM, the HIPAA data dictionary, and the ASC X12 data model can only improve the development and understanding of uniform data standards, message format standards, and PMRI standards.

As I’ve noted, XML demonstrates great promise as the syntax of choice for the exchange of PMRI. HL7, via the SGML/XML Special Interest Group (SIG), has taken the lead in the creation of a document-centered exchange standard. A document architecture is by the far the most efficient method for specifying a comprehensive, extensible, and flexible set of document type definitions (DTD) supporting shared processing requirements. An architectural approach provides sufficient common structure and semantics for documents to be exchanged and processed without the need to recognize locally defined markups. HL7 has put forward the Patient Record Architecture (PRA) as a scalable document architecture that optimizes the interoperability between documents with diverse characteristics. While providing a basis for the development of consistent DTDs throughout the industry, the PRA has also apparently engendered a competition to control or be the arbiter of the resulting DTDs. Such divisive activities are counter-productive and might easily become disruptive. This arena represents an area primed for coordination. Given the interaction of SDOs necessary to facilitate the deployment of consistent DTDs, it would seem logical for the ANSI HISB to take the lead in mediating a successful closure. This working group and, by extension, the NCVHS can provide leadership through support of a document architecture following due diligence to identify the appropriate candidate.

Another critical area begging coordination, yet much less clear in the process, is the issue of vocabulary, terminology, and code sets. We applaud the efforts of Doctors Chute and Cohn to bring order from chaos in this volatile and, in all candor, politically charged arena. However, as evidenced by the recent ANSI HISB meeting devoted almost exclusively to this agenda, there has been little progress and a decided lack of commitment among those agencies purported to be viable vocabulary developers. It appears that we are in the early stages of an entrepreneurial drive to create the penultimate vocabulary. Each in their own way wants to "own the market." Yet we have seen a cry from the industry, the users of these various coding efforts to focus on the benefits to be gained in patient care and healthcare administration versus control or commercialization of vocabularies or code sets.

HIPAA provides the precedent for identifying standard code sets, regulating their availability, and mandating low cost distribution and implementation. However, there is no clear de facto standard code set or vocabulary specific to PMRI. Does it fall to the government to pick one? I’m not sure the industry can provide that answer, but it is certainly deserving of more research. If the National Health Service of the United Kingdom can settle on a single comprehensive vocabulary for their national health initiative perhaps there’s hope. It does fall to the government to conduct such research and ultimately recommend a process for closure, if not the outright declaration of a standard vocabulary to which all disciplines should contribute and adhere.

I appreciate the time allocated by the working group to consider our opinions. McKessonHBOC remains optimistic of the outcome of these efforts and will continue to promote the implementation of standards supporting improved patient care and healthcare administration. Thank you.