Approaching semantic interoperability in Health Level Seven

Transcription

1 Approaching semantic interoperability in Health Level Seven Robert H Dolin, 1 Liora Alschuler 2 Perspective 1 Semantically Yours, LLC, USA 2 Alschuler Associates, LLC, USA Correspondence to Dr Robert H Dolin, 1368 North Stallion Street, Orange, CA 92869, USA; bobdolin@gmail.com Received 2 August 2010 Accepted 3 November 2010 Published Online First 24 November 2010 ABSTRACT Semantic Interoperability is a driving objective behind many of Health Level Seven s standards. The objective in this paper is to take a step back, and consider what semantic interoperability means, assess whether or not it has been achieved, and, if not, determine what concrete next steps can be taken to get closer. A framework for measuring semantic interoperability is proposed, using a technique called the Single Logical Information Model framework, which relies on an operational definition of semantic interoperability and an understanding that interoperability improves incrementally. Whether semantic interoperability tomorrow will enable one computer to talk to another, much as one person can talk to another person, is a matter for speculation. It is assumed, however, that what gets measured gets improved, and in that spirit this framework is offered as a means to improvement. INTRODUCTION Semantic Interoperability is a driving objective behind many of Health Level Seven s (HL7, communication protocols. Our objective in this paper is to take a step back and consider exactly what semantic interoperability means, assess whether or not it has been achieved, and, if not, determine what concrete steps can be taken next in order to get us closer. We assert that in order to improve, we must carry out measurements, and we propose a framework for measuring semantic interoperability. HL7 International is an international standardssetting organization, having developed communication protocols widely used across the globe. A vendor- and provider-supported not-for-profit organization, its mission is to provide standards for the exchange, management, and integration of data that support clinical patient care and the management, delivery, and evaluation of healthcare services. This encompasses the complete life cycle of a standards specificationddevelopment, adoption, market recognition, utilization, and adherence. The HL7 specifications are unified by shared reference models of the healthcare and technical domains. 1e3 Exchange protocols include the HL7 version 2 messaging standards, the HL7 version 3 messaging standards, and the HL7 Clinical Document Architecture (CDA) family of clinical document standards. 4 The central theme of the paper is the quest for semantic interoperability, which we address through this series of questions: 1. What do we mean by Semantic Interoperability? To begin, we establish an operational definition of semantic interoperability. An operational definition sets the stage for defining concrete metrics that can be used to measure the semantic interoperability-ness of any HL7 standard. 2. How do we know when we are there? Here we assert that semantic interoperability is a journey, not a destination. We are striving for meaningful metrics that show continual improvement. 3. How close are we? Here, we characterize the state of semantic interoperability as it exists today. 4. What are the hurdles, and how do we overcome them? This section examines factors that impede interoperability. A clear understanding of the hurdles is a prerequisite to crafting solutions to get past them. 5. Measuring semantic interoperability. This section lays out a model for testing HL7 communication protocols over time. The model can be applied to existing communication protocols as well as protocols under development. Throughout the paper, we draw a parallel between computer-to-computer and human-tohuman communication, asserting that semantic interoperability is progressing much the same way that human language has evolved. The analogy is presented here primarily as an interesting target for comparison. Note that while this paper is neither sponsored nor officially endorsed by HL7, our hope is that the thought process will ultimately prove valuable to the organization and its evolving strategic initiatives and interoperability roadmap as well as to others who share the quest. WHAT DO WE MEAN BY SEMANTIC INTEROPERABILITY? Definitions for semantic interoperability abound. The Joint Initiative for Global Standards Harmonization ( defines semantic interoperability as the ability for data shared by systems to be understood at the level of fully defined domain concepts. Wikipedia s definition ( is the ability of two or more computer systems to exchange information and have the meaning of that information automatically interpreted by the receiving system accurately enough to produce useful results, as defined by the end users of both systems. Here we establish an operational definition of semantic interoperability, thereby setting the stage for defining concrete metrics that can be used to measure the semantic interoperability-ness of any HL7 standard. We define semantic interoperability J Am Med Inform Assoc 2011;18:99e103. doi: /jamia

2 as the ability to import utterances from another computer without prior negotiation, and have your decision support, data queries and business rules continue to work reliably against these utterances. Reliably is a key word in the definitiondit is well established that decision support rules are not perfect, and that they have sensitivity (eg, the extent to which something that should trigger a rule does) and specificity (eg, the extent to which something that should not trigger a rule does not) characteristics. 5 6 Assuming it is possible to measure the reliability of a decision support rule, it stands to reason that it is possible to measure how the reliability of a rule changes when operating against imported utterances. HOW DO WE KNOW WHEN WE ARE THERE? It is important to recognize that semantic interoperability is not a binary state that is either present or absent, but rather something that can incrementally improve over time, just as a human s ability to understand English utterances improves from childhood to adulthood. Like human language, semantic interoperability will increase at different rates for different computer systems, and it would be a bad idea to expect everyone to speak in rhymed couplets as a precondition for dialog. Just as speech begins with common terms expressing basic needs (eg, Mama! ), semantic interoperabilty for exchange of health information may start with the minimum necessary for useful exchange using fundamentals that put it on a path that can not only improve over time, but also ensure that everyone willing to make the effort can be part of the conversation. In other words, we are already there, or not. There is much we can do today, whereas we continue to drive our systems toward the meaningful exchange of richer and more complex data. The best of friends will have occasional misunderstandings. Communication is never perfect, and semantic interoperability is a journey, not a destination. HOW CLOSE ARE WE? Interoperability depends on standards that can convey shared semantics reliably and safely. Our current suite of standards supports syntactic and narrative interoperability. We have computer representations (eg, data models, description-logicbased terminologies) that span the breadth of the healthcare domain and are highly expressive, but are hampered by ambiguities and other challenges addressed in the next section. As a result, interoperability today is primarily based on predefined profiles, where received data falling outside these profiles cannot be understood. Syntactic interoperability Syntactic interoperability is the ability of one computer system to import the utterance created by another computer system and validate the utterance against a particular grammar and/or set of construction rulesdsuch as where a computer imports an XML document and validates it against a corresponding XML schema. HL7 version 3 messaging standards and the HL7 Clinical Document Architecture family of clinical document standards are encoded in XML. Healthcare computer applications today can import these messages and documents, and validate their syntactic correctness. Narrative interoperability Narrative interoperability is the ability of one computer system to provide clinical content for human readers that is created using a different computer systemdsuch as where a computer imports an HTML document and renders it in a web browser. This narrative might be clinician-authored and legally authenticated text, lab findings, regulatory text, etc. While many simple, non-healthcare-specific standards such as HTML and PDF are application-independent, narrative interoperability for healthcare must ensure safe management of the displayed text. Safe management ensures that receiving applications can index the narrative record, associate it with the appropriate patient and author, and provide a valid dateetime stamp to support specificity and sensitivity for classification and retrieval of the narrative. The metadata associated with the narrative must support an audit trail for replacements and updates, and ensure that a recipient of a clinical document reads the content as it was attested by the document author, thereby ensuring patient safety. The HL7 Structured Product Labeling standard, developed in collaboration with the United States Food and Drug Administration, provides an XML encoding of package inserts. 7 Like the CDA, Structured Product Labeling ensures that narrative constructs, such as tables, are correctly rendered by consumers and requires a minimum data set in the document header to ensure safe management. Healthcare computer applications today can import Structured Product Labeling or CDA documents from previously unknown computers, manage and classify them, and ensure that rendered narrative content is safely displayed as intended by the content author. Growing understanding of computer representation of clinical data A computer s ability to understand clinical data relies on a formal representation of those data. Enabling advanced decision support, unlocking the considerable clinical content often stored in free-text notes, and enabling comparison of data created on systems of widely varying characteristics all rely on a formal computer representation of clinical data. The greater the expressivity in our models, the more we can represent, and the more a computer can understand the data and act accordingly. Formal models of the healthcare domain are the basis for the HL7 version 3 messaging standards and the HL7 Clinical Document Architecture family of clinical document standards. In particular, these protocols are derived from the HL7 Reference Information Model (RIM) ( infrastructure/rim/rim.htm), 1e3 which is a comprehensive model of the healthcare domain that has been widely vetted and continually enhanced since April Embedded within the scaffolding afforded by the RIM are codes drawn from expressive terminologies such as Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), which claims to be the most comprehensive, multilingual clinical healthcare terminology in the world ( As a result, HL7 version 3 messages and CDA documents are richly expressive, in that they can formally represent a significant breadth and depth of clinical content. Use-case and profile-driven semantic interoperability Profile-driven semantic interoperability refers to the ability of two computer systems to communicate a constrained information set based on a common model that has been analyzed ahead of time and agreed to by the parties. Constraints, also referred to as profiles, archtypes, templates or implementation guides, are built in response to particular use cases to limit a specification s variability. As a result, the communicating 100 J Am Med Inform Assoc 2011;18:99e103. doi: /jamia

3 parties can anticipate what might be received, and can parse and extract data from the utterance. As an example, consider how one might communicate that the differential diagnosis includes pneumonia. Several representations are possible using the RIM with the codes provided by SNOMED CT, Logical Observation Identifiers Names and Codes (LOINC), and other code systems. In fact, the potential for variability is such that it can be hard, when receiving an instance, to know that in fact the instance has asserted a differential diagnosis of pneumonia. In such a case, a community of interest can come together and select the way that differential diagnoses will be represented. A communication that follows this agreed upon template is then understandable by the recipient, whereas a communication that does not follow the template is not. Why not just limit the variability to begin with, instead of starting with a more general model and constraining it? This approach is similar to the early work on interoperability. It can work well, but also can lead to a disjoint set of standards that do not support reuse across silos or internal consistency. Health IT requires models of sufficient generality to bridge multiple uses, and this requires an overarching approach to interoperability that is both general and capable of specificity to address new use cases. Such a strategy is being developed within HL7 and is referred to as templated CDA. This approach derives a growing number of CDA Implementation Guides from a library of reusable templates. From its inception, CDA has supported the ability to represent professional society recommendations, national clinical practice guidelines and standardized data sets as templates or constraints on the generic CDA XML. Perhaps the best known example of a templated CDA specification is the HL7 Continuity of Care Document specification, where the standardized data set defined by the American Society for Testing and Materials (ASTM) Continuity of Care Record is used to guide the construction of templates that constrain CDA specifically for summary documents. Other CDA Implementation Guides built on this templated CDA strategy include Consult Note, Diagnostic Imaging Report, Discharge Summary, History and Physical Note, Operative Note, Procedure Note, Personal Health Monitoring Report, Public Health Case Report, Neonatal Care Report, and more. Use-case and profile-driven implementations push the boundaries beyond the simplest exchange and represent the state of the art in semantic interoperability today. Can we go further and communicate without profiles, based solely on a general model and common terminologydin human terms, using a common grammar and dictionary? In the next section, we examine this question, with an eye towards driving greater semantic interoperability outside the bounds of pre-established profiles. WHAT ARE THE HURDLES, AND HOW DO WE OVERCOME THEM? Challenges to profile-less communication with today s model and terminology include ambiguities, lack of complete expressivity, redundant representations that cannot be computationally converted into a common canonical form, implicit semantics, and a less-than-perfect understanding of context. Ambiguity Ambiguity refers to cases where the formal representation of semantics is open to two or more interpretations. Ambiguity exists both in terminology and in data models. For example, SNOMED CT has a code country of origin, which, from a product perspective, might mean place where manufactured, whereas from a public health perspective, this might mean country visited before returning to the United States or country where a person was raised. Resolution is addressed primarily via clear descriptive text and model refinement. Lack of expressivity Not all human narrative can be fully encoded with today s structured terminology and data models. For example, the US Centers for Medicare & Medicaid Services Minimum Data Set 3.0 for Nursing Homes ( contains a question which asks for the number of falls since admission or prior assessment where no evidence of any injury is noted on physical assessment by the nurse or primary care clinician; no complaints of pain or injury by the resident; no change in the resident s behavior is noted after the fall. Resolution is addressed by building incrementally (eg, encode no injury present for now), driving expressivity based on known use cases, and pushing our understanding of the tradeoffs between expressivity and computational complexity. 8 Multiple representations Multiple representations exist where a given clinical concept can be represented in more than one way. The challenge is compounded in HL7 by the fact that the RIM and the terminologies used to populate V3 messages and CDA documents are developed by different groups. Different terminologies have different internal models, such that each terminology overlaps with the RIM in a different way. For example, a family history observation such as father is alive and well can be represented within the RIM by an observation coded with a single SNOMED CT code Family history: Father alive and well, or by an observation coded with SNOMED CT code Alive and well coupled with a code father in the corresponding RIM field. Resolution is addressed through internal model consistency, via rules that govern the overlap between RIM and vocabulary, 9 and through algorithms that enable conversion of various representations into a common canonical form. 10 Implicit semantics Implicit semantics exist where a complete understanding of communicated data relies on knowledge external to the communication. Aggregation rules are defeated by the need to know, for each data element, the specific profile used to communicate it. Implicit semantics can be subtle, such as where a document has sections for discharge diagnosis and encounter details. The encounter details section contains observations on the date of hospital admission and discharge. The discharge diagnosis section contains an observation of myocardial infarction. A human reading the document would implicitly assume that the myocardial infarction is a discharge diagnosis from the hospitalization described in the encounter details section; however, a computer needs this association stated explicitly. Resolution requires that protocol developers create specifications free from implicit semantics such that the full meaning of the utterance can be understood without knowledge of a particular profile identifier. Incomplete context Context refers to those aspects of a clinical observation that potentially bear on or alter the observation interpretation. J Am Med Inform Assoc 2011;18:99e103. doi: /jamia

4 Important contextual characteristics of an observation (such as blood sugar is high ) include the subject of the observation (eg, whether the observation is about the patient or a family member), negation (eg, an assertion that an observation is false or did not occur), observation mood (eg, whether the observation actually occurred or is a criterion for action, should it occur), and temporal characteristics (eg, whether the observation is true at this time vs at some time in the past). Failure to consider contextual aspects of an observation can result in misinterpretation. For example, the RIM has a negation indicator field. Failure to account for this field can result in significant data misinterpretation. Likewise, in the above family history example, failure to account for the father code communicated in a different field can result in an observation about a family member being interpreted as an observation about the patient. Resolution requires that we not only have a clear definition and model representation of context, but also provide guidance for safe querying of healthcare-related data models such as the RIM and SNOMED CT. MEASURING SEMANTIC INTEROPERABILITY The value of an operational definition for semantic interoperability is that it is testable. Here, we suggest a framework based on our definition of semantic interoperability (ie, the ability to import utterances from another computer without prior negotiation, and have your decision support, data queries and business rules continue to work reliably against these utterances ). We call our measurement the Single Logical Information Model (SLIM) framework. The SLIM framework is based on the belief that in an ideal setting, all received communications could be parsed and imported into a single logical data storage model. Semantics would be explicit so that, given guidelines for safe querying, a complete understanding of data, regardless of sender, regardless of interoperability profile, would be possible. Decision support and business rules would trigger and execute as expected, and data from multiple sources would be safely and reliably aggregated. Data from one source could be safely and reliably used in another context. The many silos and data pockets of today would be collapsible into a single meaningful resource. In reality, however, rules executed against imported utterances will perform with a certain reliability, and the SLIM framework Figure 1 Future of semantic interoperability? HL7, Health Level Seven; RIM, Reference Information Model; SNOMED CT, Systematized Nomenclature of Medicine Clinical Terms. proposes that a measurement of that reliability is a measurement of semantic interoperability. Components of the SLIM framework include: 1. Create a reference physical database for storing imported utterances: A RIM-based physical database capable of storing HL7V3 messages and CDA documents, along with transformed HL7V2 messages, would meet this requirement. 2. Develop a library of database queries: Database queries can identify patients for whom a decision-support rule should fire, patients that should be included in a quality measurement population, etc. A community library would allow for contributions from a wide variety of stakeholders. 3. Submit sample utterances into the database: Sample HL7V2/ V3/CDA instances are submitted into the database where they are parsed and stored. 4. Measure query sensitivity and specificity against imported utterances: Measuring sensitivity (eg, the extent to which something that should be retrieved by a query is) and specificity (eg, the extent to which something that should not be retrieved by a query is not) characteristics requires that there be a gold standard way of knowing whether or not an imported utterance provides data that ideally should be detected by a set of database queries. While in many cases, this will be determined manually on an utterance-byutterance basis, it might also be possible to define a gold standard for a class of utterances that are based on a particular profile. CONCLUSION The premise that measurement is required for improvement is well established. As Lord Kelvin (1824e1907) said over 100 years ago, if you cannot measure it, you cannot improve it. Here we have attempted to define an operational definition of semantic interoperability, such that it can be measured, and we have proposed the SLIM framework for that task. In addition, we have identified where we are today and some of the significant hurdles to future progress. As they are addressed, we would expect to see quantitative evidence of improved interoperability. Whether semantic interoperability tomorrow will enable one computer to talk to another, much as one person can talk to another person, is unknown. At the heart of human language communication is the need for a common vocabulary and a common grammar. Do expressive terminologies such as 102 J Am Med Inform Assoc 2011;18:99e103. doi: /jamia

5 SNOMED CT, coupled with the grammar and syntax afforded by the RIM and HL7 version 3 and CDA specifications, provide the same foundation? Dictionaries and grammatical rules evolved over thousands of years, while computers have yet to pass their hundredth birthdaydso there should be no surprise that we still have challenges. Based on a rough analogy to human language evolution, 11 figure 1 suggests what the future of semantic interoperability might look likedwhere, given sufficient computational capacity, a common vocabulary, a common grammar, and a shared syntax, we can communicate meaningfully outside the bounds of pre-established profiles. In this scenario, the computer on the left wishes to communicate information about a patient s diabetes. Semantics are mapped into the HL7 RIM and SNOMED CT, and then communicated via an HL7 CDA document. The computer on the right, upon receiving this information, parses it into its own HL7 RIM-based model where it can then be further acted on, can trigger decision-support rules, etc. Semantic interoperability is a journey. The HL7 International community is driving down the road. Acknowledgments We would like to acknowledge E Hammond, HL7 Past Chair, and C Jaffe, HL7 CEO, for their thoughtful review of earlier drafts of this manuscript, and we would like to thank G Giannone for her review of the final version and the figure. We would like to acknowledge G Schadow, one of the founders of the HL7 Reference Information Model, for his insights into semantic interoperability. Finally, we have never ceased to be amazed by the creativity, innovative thinking, camaraderie, and sense of community among the HL7 membership. HL7 International is a community of people with a shared vision of improving patient care through computer technology, and we gratefully acknowledge the insights they have shared with us over the years, which have helped to shape the positions in this paper. It is an honor and privilege for one of us (RHD) to serve as HL7 Chairman of the Board. Provenance and peer review Not commissioned; externally peer reviewed. REFERENCES 1. Spronk R, Kramer E. The RIMBAA Technology Matrix de/docs/03100_en.htm. 2. RIMBAA: RIM Based Application Architecture php?title¼rimbaa. 3. Schadow G, Mead CN, Walker DM. The HL7 reference information model under scrutiny. Stud Health Technol Inform 2006;124:151e6. 4. Dolin RH, Alschuler L, Boyer S, et al. HL7 clinical document architecture, release 2. J Am Med Inform Assoc 2006;13:30e9. 5. Friedman C. A fundamental theorem of biomedical informatics. JAMIA 2009;16:169e Miller RA. Computer-assisted diagnostic decision support: history, challenges, and possible paths forward. Adv Health Sci Educ Theory Pract 2009;(14 Suppl 1):89e Schadow G. Assessing the impact of HL7/FDA Structured Product Label (SPL) content for medication knowledge management. AMIA Annu Symp Proc 2007:646e Dolin RH. Expressiveness and query complexity in an electronic health record data model. JAMIA Fall Symp Suppl 1996:522e Cheetham E, Dolin RH, Markwell D, et al, eds. Using SNOMED CT in HL7 Version 3; Implementation Guide, Release terminfo/terminfo.htm. 10. Dolin RH, Spackman KA, Markwell D. Selective retrieval of pre- and post-coordinated SNOMED concepts. JAMIA Fall Symp Suppl 2002:210e Lieberman P. Eve Spoke: Human Language and Human Evolution. New York, NY: W.W. Norton & Company, Inc, J Am Med Inform Assoc 2011;18:99e103. doi: /jamia