interoperability in the 21st century: cost e ective ... · pdf fileoriginal article en19 ......

Original Article en19

Interoperability in the 21st Century: Cost Effective Solutions

and Guidelines for Interoperable Electronic Health Records

Ken Salyards1, Ioana Singureanu2, Kenneth Lord3

1 U.S. Substance Abuse and Mental Health Services Administration, Rockville, Maryland, USA

2 Eversolve, LLC, Windham, New Hampshire, USA

3 MDIX, Lowell, Massachusetts, USA

Abstract

This paper describes the use of standards to enhancethe capability of creating semantically interoperable doc-uments and messages. Over the past few years, manyinformation exchange formats have been created. Whilethe health industry continues to develop new formats thatattempt to simplify or modernize interoperability acrosshealthcare, it is continually challenged by the difficulty ofcurrent applications to exchange documents that can beinterpreted by the receiver of the document. Given the va-riety of standard formats, a framework should be developedthat can bridge across multiple exchanged formats/syntaxand semantics. It should reference the business content ina consistent way that represents clinical best practices andconnects to the clinical workflow that triggers informationexchange. This paper describes the use of model-drivendevelopment to bring balance to the art of data exchangeby supporting semantic interoperability for design and run-time. The proposed model-based approach to mappingaddresses the semantic challenges and allows sending sys-tems to first specify the meaning of their data by relatingit to a defined common data dictionary of business dataelements thus making it independent of other datasets.

The resulting architecture proposes two sets of open-source components intended to provide a clear separationof concerns throughout the development process betweendesign and run-time. SAMHSA is using this approach inits Information Exchange Hub (IExHub), the transforma-tion/interface engine supporting both behavioral healthand physical health interoperability for health informationexchange network (HIEs).

Keywords

Semantic Interoperability; Electronic Health Records; Be-havioral Health; Clinical Document Architecture; Consoli-dated CDA; Fast Healthcare Interoperability Resources; Se-mantic Mapping; HL7 Version 2; Model-Driven Interoper-ability; Model-Driven Health Tools; Information ExchangeHub; IExHub; CDA; C-CDA; MDMI; MDHT; FHIR; MDI;MDR

Correspondence to:

Ken Salyards

U.S. Substance Abuse and Mental Health Services Administration

Address: 5600 Fishers Lane, 13E89-C, Rockville, MD 20852

E-mail: [email protected]

EJBI 2016; 12(1):en19-en27

received: April 19, 2016

accepted: May 1, 2016

published: May 20, 2016

1 Background

Information exchange has existed since the dawn ofman. While the human mind can make inferences wheninformation is missing or presented poorly, such inferencescan be wrong due to missing, incorrect, or poorly pre-sented information. When exchanging information humanto human or augmented by minimal technology such asphone or FAX, the format and content of the informationare often not very rigorous. This presents issues whenexchanging information electronically.

Health information such as narrative descriptions areoften exchanged between providers using a generic elec-tronic format such as PDF and HTML. This is onlymarginally better than FAX and heavily reliant on humaninterpretation of the information received with little to nocomputeraided processing or analysis. A human must re-fer to and interpret the electronic document anytime theinformation can be used in the treatment of a patient.As information exchange relies on both the sending andreceiving clinicians to interpret it in the same way, the se-mantic modifiers such as “resolved,” “major,” “critical,”

c©2016 EuroMISE s.r.o. EJBI – Volume 12 (2016), Issue 1

en20 Salyards K. et al. – Interoperability in the 21st Century

or “severe” that are associated with clinical informationmay be contextual. Thus, better interoperability requiressemantic clarity that goes beyond human decoding of nar-rative information and requires machine processing of free-text and structured data. Similarly, it is important toconvey such information as: “the patient does not reportany allergies,” “we have no information about allergies,”or “tests reveal no allergies.”

Over the past decades, many information exchange for-mats have been created to exchange messages and docu-ments. While the intent of these formats and approachesis to simplify interoperability, it has presented a very com-plex interoperability landscape for implementers to navi-gate. As a Standards Development Organization (SDO),Health Level Seven International (HL7) has developedseveral file formats for exchanging information. These in-clude HL7 Version 2.x, HL7 Version 3, Clinical DocumentArchitecture (CDA), and Fast Healthcare Interoperabil-ity Resources (FHIR). All have been attempts to createmachine-understandable structures with flexible seman-tic content, subject to implementation-specific clarifica-tions. For standards to augment and improve interoper-ability, they must be associated with specific use cases.All HL7 standards have to be constrained (or extended)and combined with clinical terminology to create an im-plementable guide that attempts to eliminate ambiguity.

There are other content standards defined in theUnited States, such as the National Information ExchangeModel (NIEM) and The Accredited Standards CommitteeX12 known as ASC X12 or simply X12. Layered belowthe content standards referenced above, there are trans-port protocols such as SOAP, REST, NwHIN DIRECT,and NwHIN CONNECT which are often tied to a par-ticular information exchange standard and ignore seman-tic clarity. Figure 1 illustrates the complexity faced byEHR systems expected to convey business information us-ing Meaningful Use standards such as C-CDA, HL7 V2,QRDA, or HQMF, or emerging standards such as FHIR.

2 Problem

Healthcare interoperability requires information to besemantically precise to ensure that its meaning is inter-preted in the same way by both the sending and re-ceiving systems. The challenge posed by semantic con-sistency increases exponentially when information is ex-changed across multiple senders and receivers (many-to-many) across a nationwide network.

In the US, the current state of the health care deliv-ery system is fragmented with many poorly implementedhealth IT systems still lagging in data (semantic) inter-operability despite the billions of dollars spent to cer-tify electronic health record (EHR) systems and launchinghealth information exchange (HIE) solutions to integratecommunity-based providers.

The current standard implementations have not ma-tured sufficiently to remove ambiguity from the exchange

standards or ensure consistent semantics across com-munities. There are no required implementation stan-dards for HIE organizations, the key entities that fa-cilitate electronic health information exchange betweenproviders. Additionally, HIEs have demonstrated poorbusiness model sustainability. These issues directly af-fect the interoperability landscape, especially for specialtyproviders such as cardiology and behavioral health. Sim-ply validating the structure of a document or message doesnot ensure the information contained will either be suffi-cient or be interpreted in the same way for decision sup-port and treatment. The current state of interoperabil-ity allows different systems to process and interpret infor-mation differently even though the underlying standardstructure is valid and includes all the relevant businessdata elements.

The U.S. Substance Abuse and Mental Health ServicesAdministration (SAMHSA) is currently exploring ways toreduce the complexity of information sharing across theHIE without compromising patient privacy and confiden-tiality and supporting national regulations such as 42 CFRPart 2 [1]. SAMHSA is also creating opportunities for be-havioral health clients in particular, and patients in gen-eral, to have greater control of their health informationthrough standard-based solutions that ensure semanticsinteroperability across the continuum of care.

Achieving interoperability across the continuum ofcare requires that all systems must have a common un-derstanding of the information shared regardless of thepayload structure or transport. To bridge the differencesamong systems, a common, standards-based canonicaldefinition of information meaning can help translate fromone format to another while maintaining semantic preci-sion. The goal is to allow EHRs and Health InformationExchanges (HIEs) to share information using standardstructures (i.e. messages, documents, resources) and ter-minology as well as leverage standards-based knowledgemodels using standard terminology systems.

This paper describes how interoperability would be en-hanced by model-driven architecture principles to add thescience of semantic data definition and mapping to the artof standardsbased information exchange.

2.1 Why Mapping Fails

Throughout this paper, we emphasize the importanceof semantic mapping and the use of profiles to constrainstandards for precise implementation and transformation.Past attempts to map HL7 Version 2.x message elementsto HL7 Version 3 classes have shown the futility of a mapthat relates an ambiguous concept (e.g., Observation classin V3 to an OBX segment in V2). In most cases, thestructure can be constrained into a profile to exchangea certain type of information (e.g., V3 Observation toCDA Problem or V2 OBX to a device-reported bloodpres-sure measurement). Clearly, attempting to map an un-constrained standard structure to another unconstrainedstandard structure is not useful or reusable. Semantic

EJBI – Volume 12 (2016), Issue 1 c©2016 EuroMISE s.r.o.

Salyards K. et al. – Interoperability in the 21st Century en21

Figure 1: Standard-based Specifications required Meaningful Use certification and billing.

mappings, in contrast, are reusable. They document howbusiness data elements are represented in a structure, forexample, how a vital sign is represented in either V2 orV3—the same content but in two syntactical representa-tions.

Semantic mapping also requires semantic clarity.Through semantic mapping we can distinguish betweenthe dates (1) when a problem was recorded, (2) was ob-served, or (3) the year or age when a problem or symptomstarted. While dates appear trivial, certain qualifiers canclarify the meaning of a business data element and facil-itate the creation of profiles and maps. Similarly seman-tic mapping includes mapping coded data by identifyingequivalent concepts and relating local codes to standards(e.g., SNOMED CT, ICD-10, LOINC, RxNorm, etc.).

There are additional factors that affect mapping onehealthcare format to another. Using the earlier exam-ple, there can be many problems observed by a health-care professional for a patient. In each observation, dataelements for the date, the type of specific problem, theseverity of the problem, and who authored the observa-tion are all recorded data elements. For this informationto be used correctly later, all of the specific data elementsfor the observation must be bound together. Therefore,the semantics of a format are not simply represented bythe semantics of a specific data element, but rather thesemantic clarity of the data element is influenced by howthe data elements are organized or structured (i.e., hierar-chy). There are additional factors that can have an impacton semantic mapping such as relationships and values ofother data elements (e.g., moodCode in CDA and the re-lationship between OBX-3 and OBX-5 in HL7 V2) andthese must be understood to achieve a precise meaningand precise structure.

Therefore, strictly syntactic mappings fail and are gen-erally expensive to implement for a variety of reasons:

• Lack of semantic understanding between data ele-ments

• Lack of semantic clarity for data elements

• Complexity introduced by format structures and re-lationships between different data elements.

The use of a model-based mapping helps avoid thepitfalls of syntax-based mapping, driving interoperabilitytowards semantic consistency across systems and applica-tions.

3 Semantic Consistency across theContinuum of Care

The proposed semantic mapping approach is intendedto add semantic consistency across systems using widely-adopted model-driven architecture principles, similar tothe HL7 Services- Aware Enterprise Architecture Frame-work (SAIF). It adds the semantic versus syntax modelseparation introduced by the Open Management Group’sModel-Driven Message Interoperability (MDMI) [2] spec-ification as a technical approach to model-driven semanticinteroperability. To address the complexity of healthcareinformation exchange, the canonical data elements are de-scribed using the ISO 11179 metadata registry (MDR) [6].The canonical data are then reused to establish seman-tic equivalence across systems, across syntactic models(e.g. HL7 V2, CDA, FHIR, etc.), across knowledge mod-els (e.g. Detailed Clinical Models, CIMI clinical models,OpenEHR clinical models/archetypes) and even across di-verse clinical coding systems (e.g., SNOMED CT vs ICD,local system to standard systems). The maps rely on acommon “model of meaning”, which is a logical represen-tation of payloads that consist of data elements organized



into a well-defined registry or “Referent Index”. Similar toother standards products, the Referent Index would deriveits authority from a consensus-based change managementprocess organized by a SDO.

Using this approach, each side of the exchange mustfirst map its own data to a common data element (i.e., vi-tal sign result). A second map ensures that the standardsyntactical structure (e.g. FHIR Observation, HL7 V2OBX segment, CDA Observation) is used consistently torepresent its data element (i.e. Vital Sign Result). Thisapproach may map not only across standard-based syn-tactic models (e.g., CDA, V3, V3, and FHIR), but alsoacross models of clinical knowledge and requirements suchas Detailed Clinical Models, Open EHR Archetypes, andthe Clinical Information Modeling Initiative (CIMI).

The software architecture required bringing these con-cepts to life, ensuring that semantic mapping provideda clear separation between data semantics and syn-tax/representation. This promotes the development ofreusable maps for well-defined implementation specifica-tions. The success of semantic mapping relies on a com-munity of interest and an SDO that can maintain the dataelements which make up the Referent Index.

The architecture must also provide a means of exe-cuting semantic maps at runtime and requires a sustain-ing effort to develop a reusable registry of data elements.SAMHSA has created the Information Exchange Hub(IExHub) project to build the transformation/interfaceengine supporting both behavioral health and physicalhealth interoperability for HIEs. [3]

4 Benefits of RuntimeModel-Driven Interoperability

Previous standards-based mapping projects aimed tofacilitate transition from one standard sy and syntax toanother (e.g., HL7 Version 2 ASCII Encoded messagesmapped to HL7 Version 3 XML messages). These projectsattempted to map the entire standard to its newer ver-sion without considering that both versions required ad-ditional refinements and constraints for realworld imple-mentations.

Due to the unconstrained definitions or specified op-tionality of the base standards, mapping an entire stan-dard from one format to another has proven to be un-reliable. In programmatic terms, the mapping of onebase class to another base class while ignoring that eachclass must be further specialized prior to instantiationcannot guarantee semantic interoperability. This map-ping approach fails to align semantically equivalent dataelements because the interoperability standards containgeneric concepts and optionality intended for adaptabilityto a multitude of implementations. Therefore, mapping ofbase standards is inherently imprecise, requiring insteada semantics-driven solution.

The proposed solution includes model-driven semanticmaps that are directly executable by the IExHub runtime

environment which supports the bi-directional exchangeof business data and information independent of format:

• CDA R2 (using C-CDA templates)

• FHIR (resources/profiles)

• HL7 Version 2 (use case specific implementationguides)

• Other formats as identified (X12, NCPDP)

Additionally, the IExHub provides a number of con-nectors for specific transport protocol and envelope for-mats to support the exchange of standard-encoded mes-sages and documents:

• REST

• SOAP (IHE ITI Integration Profiles, NwHIN Con-nect/eHealth Exchange)

• S/MIME (NwHIN Direct)

• HL7 Minimal Lower Layer Protocol (MLLP)

5 Semantic Mapping Design forModel-Driven Interoperability

Semantic maps are created using an open-sourceEclipse-based tool - the business analyst’s “workbench”(i.e. MDI Workbench). It integrates existing open-sourcetools (e.g. MDHT MDMI, Art-Decor [7]) to put subjectmatter experts in charge of defining maps and creatingmodel-based implementation guides for information ex-change standards.

The workbench combines standards profiling and se-mantic mapping thus leveraging the work done by theOpen Health Tools community to create the “CDA Tools”for template development and model-based validation.Consumers of CDA-based documents and implementersof CDA and C-CDA are able to generate run-time com-ponents from models of the implementation guides, thusaccelerating and lowering the cost of adoption for this keystandard required in Meaningful Use Stage 2 and Stage 3(MU2/MU3) certification.

During our evaluation of standard profiling tools, theMDHT tools were used to create implementation specifi-cations for information exchange formats beyond the CDAformat such as FHIR profiles. The MDHT tool provides amodel-driven framework for generating a Java runtime ap-plication program interface (API) that supports templateconformance. The API enables construction of instancesthat conform to these templates, ensuring that documentsconform to the relevant constraints. Since it is based onUML 2.0, MDHT can be used to contain any standardstructure and provides built-in support for constraining atemplate/profile to add more specificity if required by animplementation.

For semantic data element mapping to be successful,the metadata registry [6] must be completed before a busi-ness analyst can create a semantic map. The metadata



registry should be curated by an international StandardsDevelopment Organization (SDO). This insures that theresultant Referent Index describes the canonical defini-tion of semantic business data elements. An internationalSDO is best suited to curate the Referent Index so thatthe semantic data elements are not corrupted from addingcontent that is not rigorously defined.

The MDI workbench allows an analyst to create or editmaps that relate local EHR/HIE source data to informa-tion exchange formats using the Referent Index. The mapeditor could also be applied to creating “standard” mapsthat specify how a canonical data element is represented.

This frees the semantic data elements from beingbound to an exchange format until an implementationguide is defined based on a well-defined use case. A logi-cal payload can then be developed, not bound to a syn-tax or representation but derived from concrete businessrequirements. This leads to standards-based implementa-tion guides which satisfy, in a verifiable way, a need forsemantic information sharing. The logical payload sup-ported by an implementation guide consists of data ele-ments defined in the Referent Index and provides imple-menters with the detailed knowledge to represent that log-ical payload in a standard-based syntactic structure (e.g.CDA document, V2 message, FHIR transaction) and ter-minology (e.g. LOINC value sets).

Figure 2 describes how using a model-driven seman-tic mapping uses two semantic mappings which allowsa data element mapped to equivalent information ex-change structures (syntax model) using a common seman-tic model. This approach can be extended and invoked totranslate the EHR data to a variety of formats, for exam-ple, from C-CDA 1.1 to FHIR and HL7 Version 2.x imple-mentation guides. To enable the adoption of standards,the Referent Index should be developed by the SDO tospecify data elements semantically within an implemen-tation guide. Interested stakeholders can reuse the mapsat design-time and generate run-time specifications con-sistent with model-driven architecture principles.

At runtime, the map configured for specific endpointsis executed by dedicated software components.. Thusmapped, the EHR local data can then be representedcorrectly as an implementation guide-specific payload. Astandard set of maps, which will be provided in the opensource project, would describe how business data is repre-sented in a specific CDA template, HL7 Version 2 profile,or FHIR profile (i.e., unit of exchange). As new imple-mentation guides and profiles/templates are developed,the Business Elements could be referenced alongside eachconstraint applied to the standard.

A model-driven approach promotes the reuse of theReferent Index as the canonical representation of all thedata exchanged through any interoperability specifica-tions. The importance of semantic business data whencreating a new profile or template is evident in the wayother open-source tools such as Art Decor begin the devel-opment of a new template by first creating a data model ofrequired data and then applying the necessary constraints

to the underlying standard structure to support the dataset. The model-driven approach promotes the reuse ofbusiness data elements by:

• Helping applications clarify the semantics of theirlocal data

• Helping profile developers clarify how a message ordocument would represent the Business Elements inan interoperable way, using standard constructs andsyntax

Figure 3 illustrates the use of metadata based on clin-ical terminology. This ensures that the meanings of Ref-erent Index Business Elements are not dependent on nar-rative descriptions but instead on a post-coordinated ex-pression that combines the meaning of well-defined stan-dard concepts (e.g. Allergy + observation + date/time).These computable expressions can be used to de-duplicateand navigate the Referent Index for precise mapping andpredictive reasoning.

6 MDI Runtime Transformations

Semantic maps allow information systems to specifyhow their local format/syntax relates to the canonicaldata elements in Referent Index. To transform data be-tween two syntactic models, a second map is required tospecify how the canonical data elements are representedto a target representation. To facilitate reuse each imple-mentation guide may have an associated map that rep-resents the community consensus on how a specific dataitem (e.g. vital sign result) is represented in a standardsyntax (e.g. the Observation value data element of theC-CDA template). This ensures that EHR systems canexchange health information in a manner that guaranteesthat the content of the information is understood acrossdisparate systems, thereby allowing for semantic interop-erability.

A transformation consists of two mapping opera-tions: first from a source structure to a canonical datadefinition and a second from the canonical data defini-tion to the target syntax specified by an implementationguide. The IExHub automatically executes the necessarymap sequence based on the source and target format andimplementation guides invoked at runtime.

MDI transformations allow EHR systems to (1) mi-grate selected interfaces to later versions of the standards,(2) adopt new information exchange formats, and (3)maintain backward compatibility with existing interfacesinside and outside the enterprise. The transformationsalso allow the systems to support more than one exchangesyntax/format for a logical payload.

In addition to executing semantic maps, the IExHubcan also act as an application gateway linking FHIR-based applications with existing SOAP-based HIEs. TheIExHub can map not only data but system capabilitiesand behavior (e.g., the application invokes FHIR Patient



Figure 2: Model-Driven Interoperability using Semantic Mapping.

Figure 3: Data Element Metadata combined using ISO 11179.

“search” to transmit the IHE ITI-47 PDQV3 Query mes-sage supported by the HIE). The transformation includesmapping payloads and transport from FHIR over RESTto HL7 V3 with ebXML over SOAP.

6.1 Transforming Atomic and AggregateData

Most of the transactions and message exchanges cur-rently implemented using standards share three charac-teristics. They aggregate information corresponding to aspecific focal structure:

• Messages (e.g. HL7 Version 2, X12, and NCPDP)

• Documents (e.g. CDA documents, FHIR resource,HQMF, and QRDA)

• Support simple interaction modes:

– Unsolicited notifications (e.g. laboratory re-sults reports)

– Request/Response transaction (e.g. order re-quest message/order response message)

– HL7 FHIR adds support for atomic data ob-jects

FHIR and CDA will coexist for the near future as theyaddress complementary requirements.



• FHIR supports access to atomic elements whileCDA provides access to aggregate objects contain-ing both narrative text and structure.

• FHIR supports queries for discrete data elementswhile CDA supports only queries for documents ordocument sets.

Thus, CDA is ideal for large transactions containing avariety of sections and objects. In contrast, FHIR provideaccess to specific data elements (e.g. lab results, patientrecords, and provider records).

MDI allows the two standards (and other required in-teroperability standards) to co-exist and fulfill the require-ments of various projects. The MDI approach supportstransition from one standard or version of FHIR or CDAwithout affecting the business data content of resourcesor documents. Typically, a CDA document may be repre-sented by two or more FHIR resources (e.g. Compositionin a Bundle with dependencies).

FHIR allows systems to provide new capabili-ties to HIE repositories that persist aggregate mes-sages/transaction or documents. For example, providersmay create CDA documents to be sent to a data storesuch as an HIE, and others may make queries to the HIEand receive FHIR resources (created from data content ina CDA document) in response.

Not only is the document information mapped fromone format to another, it is done with complete semanticintegrity because the Referent Index data element repre-sents the conical definition used by each template defini-tion. Now we begin to see synergy between the differentstandard formats and convergence across the various ar-eas of the health continuum for where the different formatsprovide the most value.

7 Model Driven Interoperability(MDI) Value Proposition

The MDI approach requires more upfront work bydefining the content of semantic data elements. This ap-proach facilitates the exchange of documents in one formator another much faster than waiting until a standard isdefined to determine the semantic content required. MDIstrives to ensure semantic consistency across EHR sys-tems. Errors in data and clinical terminology transfor-mations have caused serious safety problems by creatingerrors in systems attempting to decode the data. Mappingambiguities can lead to medical treatment errors that re-quire a systematic approach to later tackle the root causeof such errors.

Why is true interoperability so difficult to achieve? Of-ten it’s the result of focusing on strictly structural confor-mance to a standard syntax to the detriment of semanticvalidation. If the sending and receiving systems do notshare a common model of meaning, then divergent se-mantic understandings may be derived even if they sharevalid structures.

MDI overcomes these data equivalence issues by pro-moting mappings to and from canonical business elements(e.g. LOINC encoded vital sign observation) rather thansyntax node (e.g. OBX.5). A model-driven mapping ap-proach frees implementers from the burden of dealing withsyntax-based mapping and allowing for focus instead onprecise semantics.

Another business benefit of MDI is managing changesin interoperability standards over time by allowing newstandard maps to augment existing representations ofdata without requiring business analysts to redesign ex-isting maps.

8 Model-driven InteroperabilitySolution for Behavioral HealthProviders

Behavioral health providers are expected to adoptstandard-based information exchanges without the benefitof financial incentives provided by the Centers for Medi-care and Medicaid Services (CMS) to those providers whodemonstrate Meaningful Use of EHR systems. Therefore,these providers require a cost-effective approach to inter-operability that relies on open-source and standard-basedsoftware tools to leverage the collective investments of fed-eral, state, and private sector stakeholders.

To reduce the cost of interoperability, the BehavioralHealth Interoperability demonstration initiated by theSubstance Abuse and Mental Health Services Administra-tion (SAMHSA) implemented software components anddeveloped methodologies to reduce the high cost of health-care interoperability for EHR systems that are sharinghealthcare information using the standards and implemen-tation guides required by the Meaningful Use certification.The certification criteria include adoption of C-CDA fordocument-based exchanges, HL7 Version 2.7.1 Profiles forLaboratory Results and Orders (LRI, LOI) in addition toHealth Quality Measures Format (HQMF), Quality Re-porting Document Architecture (QRDA), and the emerg-ing implementation guides for FHIR.

A model-based, semantic mapping approach separatescontent from syntax to allow the exchange of business dataconsistently. Whether using FHIR, CDA, or HL7 V2, anEHR system is able send or process laboratory results.The laboratory result data content is the same.

For an implementer, the difficulty increases each timea new implementation guide or format is proposed foradoption. Each system must map local business data toa variety of formats (e.g. HL7 Version 2, CDA R2, andFHIR) based on the constraints and criteria defined byimplementation guides (e.g. C-CDA, Laboratory ResultsInterface, and Health Quality Measure Format). The chal-lenge for implementers is not only to understand the infor-mation exchange format, the implementation constraints,and implementation guidance, but also to create semanticrelationships between local data elements and the stan-



Figure 4: Aggregate Transactions and Domains Persisted by HIEs.

Figure 5: Retrieving Atomic Data from Aggregate HIE Database.

dard data element identified in the target implementa-tion guide. If these semantic relationships are incorrect,the resulting CDA document or HL7 Version 2 messagemay pass validation and even certification but may carrythe incorrect business data. These semantic errors mayamplify when an HIE or another data aggregation sys-tem combines information received from multiple senders.Each semantic error further limits the ability of such sys-tems to process the data pertaining to a patient of popu-lation.

The Behavioral Health Interoperability project usedthe model-based approach outlined in this paper to showthat it can address the semantic challenge and financiallimitations facing this domain. Our team showed that

semantic mapping can be applied directly to applicationsemantics to map local data to/from canonical data ele-ments and then use a set of standard maps to representthe application data using the standard implementationguides mandated by national regulation.

9 Conclusions

The inherent complexities in adopting multiple infor-mation exchange syntax models and terminologies in in-teroperability scenarios are mitigated using a MDI ap-proach. The principles and architecture outlined in thispaper require a community of interest to maintain a clin-ically relevant Referent Index and contribute standard-



Figure 6: Semantic Mapping enables Meaningful Use standards adoption.

based maps for implementation guides rather than basestandards. MDI also recognizes the need to supporta variety of interoperability specifications and leverageclinician-designed knowledge and create a framework tosupport these standards without many-to-many syntaxmaps and relying instead of one-to-many semantic maps.

Key benefits of MDI include:

• Simplifying the process of mapping local EHR orother local data to standard semantic definitions us-ing a canonical information representation, ensuringthat information semantics rather than format driveany decision related to mapping data across systemsand organizations.

• Create reusable open-source mapping definitionsthat enable diverse EHR or other systems to con-form to common information exchange formats. Alibrary of mapping/transformation models specificto an information exchange standard implementa-tion guide (e.g. HL7 C-CDA 1.1, HL7 LRI, etc.)would ensure that meaning of business informationis mapped identically across information exchanges.

• Promote mapping to implementation guides, not toa base information exchange Standard/format. Thisis an important principle that acknowledges thathealth information technology standards require ex-planation using additional constraints before a real-life implementation is possible. Therefore, by map-ping to an implementation guide or a profile of astandard, we ensure that the business semantics areclearly addressed and have unambiguous or unique

representations in the payload for each business dataelement. This principle also guarantees that thecomplexity of the “on the wire” representation ofbusiness data is isolated to a specific map and doesnot permeate into an application’s own representa-tion, thus separating concerns of application opti-mization from information exchange optimization.

• Promote model-based development of specificationsfor new profiles and templates traceable to the well-defined, consensus based business data dictionaryleading to an implementation ready specification.

References

[1] Substance Abuse and Mental Health Services Administra-tion. Frequently Asked Questions: Applying the SubstanceAbuse Confidentiality Regulations to Health Information Ex-change. 2010. http://archive.samhsa.gov/healthPrivacy/

docs/EHR-FAQs.pdf

[2] Object Management Group MDMI Version 1.0 references ISO20022 www.omg.org/spec/MDMI/1.0/

[3] HL7 Community-Based Collaborative Care Project Site onInformation Exchange Hub (IExHub): gforge.hl7.org/gf/

project/cbcc/frs/IExHub_Interop_Projects

[4] Model-Driven Health Tools: github.com/mdht

[5] MDMI Reference Implementation: github.com/mdmi

[6] MDR ISO /IEC 11179 Metadata Registry (MDR) standard

[7] ART Template Editor: Art-Decor: https://art-decor.org/

mediawiki/index.php/Main_Page


http://archive.samhsa.gov/healthPrivacy/docs/EHR-FAQs.pdf

http://archive.samhsa.gov/healthPrivacy/docs/EHR-FAQs.pdf

www.omg.org/spec/MDMI/1.0/

gforge.hl7.org/gf/project/cbcc/frs/IExHub_Interop_Projects

gforge.hl7.org/gf/project/cbcc/frs/IExHub_Interop_Projects

github.com/mdht

github.com/mdmi

https://art-decor.org/mediawiki/index.php/Main_Page

https://art-decor.org/mediawiki/index.php/Main_Page