HL7
HL7
–
–
NCPDP e
NCPDP e
-
-
prescribing
prescribing
harmonization: using the v3 HDF for
harmonization: using the v3 HDF for
as a basis for semantic interoperability
as a basis for semantic interoperability
Mark Shafarman
HL7 Chair
Applications Architect, Oracle Corporation [email protected] 1 415 491 8104Harmonizing messaging standards
We will discuss
• How can the HL7 Development Framework (the HDF) process be used to develop semantically interoperable specifications for messaging standards?
• How this may require changes to the standards being harmonized or changes to the RIM itself
• But…an important note: this process does not require
replacing one standard with another, but instead
facilitates the development of a harmonized mapping
that supports semantic interoperability between the
standards being considered.
The HL7 (v3) Development Framework
• The HL7 Development Framework (HDF) is a broader replacement for the original HL7 v3 Message
Development Framework (MDF)
• It extends the v3 interoperability paradigm ‘beyond just messaging’
• It supports the development of additional paradigms for interoperability frameworks including (partial list)
– API’s
– Clinical documents (including templates and archetypes) – Decision Support
HDF: supporting semantic interoperability
• The HDF has a formal methodology to represent an application’s information space that ensures “semantic interoperability”
• A practical definition of “semantic interoperability”
– Not only can the information be transmitted between/among systems, but
– The receiving system can understand and reuse the information in many different contexts, across all healthcare information
application domains
HDF formal specification process
• Why a formal process?
– Only a formal methodology will ensure “semantic interoperability”
• The key to this process is using the HL7 RIM and its related tools and methodologies to create standard
models with standard vocabulary bindings that describe each particular healthcare information domain in terms of the RIM
• The collection of standard models with standard
vocabulary bindings can be described as a “structural ontology” or an “ontology of structures”
An example of Semantic Interoperability
• A given prescription may also appear in a
discharge summary, a current medications
message, and/or a visit note. If it can be
represented in a way that has the same meaning
in each of these four contexts, then the given
lab result can be said to be ‘semantically
interoperable’ among those three contexts.
• If these four contexts are computer applications
then the given prescription can be said to be
‘semantically interoperable’ among those three
An example of Semantic Interoperability
• If the given prescription has the same meaning in
other contexts (and/or in other computer
applications) then it is semantically interoperable
across
all of those other applications/contexts.
• This means that the given prescription may be used
in computations for graphing, charting, decision
support/rules, etc. as well as in other clinical
documents and reports.
Properties of Semantically Interoperable systems
• Note that an application system may use the “semantically interoperable” representation of prescription to support
conformance claims.
• Note that systems claiming ‘semantic interoperability’ for prescription may have many different spatial/temporal
relationships with each other.
– They may be distributed over some form of network (including internets)
– They may be located on the same physical (or logical) system
• But they must all support common representations of prescription
Properties of Semantically Interoperable systems
• Q: How is this different from the common usage of interoperability standards?
• A: because the HDF process is based on the RIM, a standard reference information model, it is possible to create semantically interoperable specifications
– on a much wider basis (city, state/province, nation, global)
And
– Where re-use of information is guaranteed across many differing application contexts (including contexts not specified when the information is created)
Properties of Semantically Interoperable systems
• Thus, in our practical example above, system
“A” might receive an prescription from a visit
note, and then extract the full semantic
content of that observation result from the
visit note, and use it in:
– A chart – A report
– A decision support rule
– A referral letter (or discharge note) – Etc.
Properties of Semantically Interoperable systems
Note: For this discussion we are interested in
semantic interoperability that is “standards-based”
• I.e., a system receiving any one of these contexts
must be able
– to uniquely identify the prescription(including the patient to whom it applies, when it occurred, etc.)
and also
– use it in computations involving reports, rules, graphs, research studies, etc.
Properties of Semantically Interoperable systems
• such systems must be able to use and re-use the
same:
– Identifiers for patients, practitioners, organizations, etc.
– Coding systems which identify the prescriptions – Structures (models) that express the prescription,
including the
• Objects • Datatypes
Further requirements for Semantic Interoperability
• This means that the various systems must have a
methodology that supports large-scale integration that includes all of the above:
– Standard structures (models)
• Complex datatypes for the attributes of the models (I.e. standard “small” models for names, identifiers, addresses, timing
specifications, physical quantities, codes, and text)
– Binding standard vocabularies to standard structures – Built-in support of globally unique identifiers
• And the methodology must support a way to analyze and compare what each system currently supports, and what changes if any must be made to each system (or its interfaces) to support semantic interoperability.
• The v3 HDF (HL7 Development Framework) is such a methodology.
Harmonizing messaging standards
• References:
The HL7 Development Framework, (HDF) chapters 2
and 3
– Chapter 2: Requirements Gathering and Analysis
HDF generic mapping process
Mapping into v3
RIM-derived models UML Domain Analysis
Model (DAM) for
system “X”. Complete semantic content in “the application’s own
terms and structures”
Version 3 Reference Information Model (v3 RIM-based) for
system “X” Complete semantic content in v3 RIM concepts and
HDF generic mapping process
For any application,
– Create a UML model (the “domain application model”) that contains the application domain content. This is best done by domain experts (“in their own terms”). It includes the models (static, dynamic, and accompanying glossary) as well as the information/process flows
– Then with a v3 expert map that model into a v3-based representations (described using the current v3 tools)
– As with the UML model, in the RIM model we will have
• Static models (DMIM, RMIMs, HMDs, MTs) • Dynamic models (Interactions)
• Glossary (drawn primarily from existing RIM structural
vocabulary, and existing “domain” vocabulary, except for new structural vocabulary added via RIM harmonization, and new domains needed for a domain not previously mapped to the RIM)
Some slightly less technical words
• UML (Universal Modeling Language) provides a
graphical formalism for representing complex
concepts as structures. It also supports
object-oriented design paradigms that are extremely
useful in creating complex systems from simpler
ones.
• HL7 V3 bases its methodology on UML and
object-oriented design paradigms.
A still less formal explanation
Knowledge is contained in structures: concept maps
are not enough.
What we’ve learned from the development of v3 is
that representing the semantic content needs more
than just standard coding systems (and
relationships between concepts). It needs a set of
standard structures (models) with ‘placeholders’
(attributes) where standard vocabulary codes are
referenced.
V3 model comparison
Comparison
Version 3 Model (RIM-based, HDF methodology-based) for system “X”
Version 3 Model (RIM-based, HDF methodology-based) for system “Y”
HDF generic mapping process
Comparing both v3-based models will highlight any differences in
• model structures, including
Attributes within classes Datatype constraints Identifier usages
• Vocabulary usages
These detailed comparisons can be used to verify whether or not the two applications can be semantically interoperable, and also to identify any changes needing to be made to either
application (or the messages it supports) to achieve semantic interoperability.
HDF generic mapping process
• If we also compare the resulting models to the
version 3 balloted models, we can achieve a
wider semantic interoperability.
• This requires a comparison of each system’s
v3 domain model with the corresponding
balloted models (standards) from HL7 version
3.
V3 standard model comparison
Version 3 Model for system “X”
Comparison Version 3 Model for system “Y”
Current CDISC and HL7 process
ODM / SDS / etc
*RIM / DMIM / CDA
CDISC UML Problem-Space Model (a la HDF)
* RMIM / HMD / XSD
V3 RIM Model
NCPDP and HL7 v3 semantic mapping
Script v 5 (or 4.7)
*RIM / DMIM / CDA
E-prescribing UML Problem-Space Model (a la HDF)
* RMIM / HMD / XSD
V3 RIM e-Rx Model
HL7 v 2.x / v3 semantic mapping
HL7 v 2.3 (or 2.4-.5)
*RIM / DMIM / CDA
E-prescribing UML Problem-Space Model (a la HDF)
* RMIM / HMD / XSD
V3 RIM e-Rx Model
V3 e-Rx model comparison
Version 3 Model for v 2.x e-Rx
Comparison Version 3 Model for NCPDP/Script v 4.7
A spreadsheet for model mapping
Rim Model columns:
Class
Class Code
Element Type (class, genspec, association, attribute)
DMIM clone name Attribute name Association Index # Definition Multiplicity Datatype Vocab Domain
Domain Analysis Model (DAM) columns:
Element
Element type (class, genspec, association, attribute)
Parent/containing class Definition
Datatype Multiplicity
Looking at an actual example
We note that the mapping may not be 1:1.
Sometimes one DAM element may need several
RIM elements. The reverse is also true.
We also note that the mapping may require
development of one or more transformation
algorithms (programs).
Comparing/mapping between models
• Cannot always be done just by mapping one data
element to another.
• What we need to do is to map one “model
element” to the corresponding “model element”.
• The elements may be classes, attributes of a class,
associations between classes, etc.
• Often a “model element” in one model will map
to a structure of elements in another model. Or
vice versa. And the element mappings may not
always be one to one. And the element mapping
may need to involve a calculation based on the
values (numeric, coded, string) of other elements.
HDF generic mapping process
After completing this process,
• We have created/identified an “set of structures” supporting semantic interoperability for the
application domains being considered, I.e.
• A set of “standard” models (structures), derived from the Reference Information Model, that represents the full semantics of that domain
– With formal bindings of appropriate vocabulary standards to the attributes of the models
– And specification of the identifiers needed for the various structures
NCPDP/HL7 Harmonization
• Note that, in HDF terms
– V 2.x is an “application”
• As are any of its subdomains, such as pharmacy messaging
– Other standards, such as NCPDP’s Script, are also “Applications”
• In fact, the proposed Script information model is also an application
• Thus, the suggestion is to follow the ‘HDF
generic mapping process’ to create a harmonized
mapping between NCPDP’s Script and HL7’s v
2.3 RX messages
NCPDP/HL7 Harmonization
• If we follow the ‘generic mapping process’ for both standards, we will get two v3 models which can easily be compared for similarities and differences
• We will also discover if there is anything in either NCPDP Script or HL7’s v 2 3 RX that cannot be supported in the RIM or its methodology
– If variances are found they may lead to changes in either of these standards, or to changes in the RIM
• There is a formal process called RIM harmonization to change the RIM
NCPDP/HL7 Harmonization
• Finally, we can compare the resulting two
v3 models with the v3 ballot-level models,
and adjust/modify them as necessary to
ensure semantic interoperability of the
information, not just between NCPDP and
HL7 v 2.x, but across the entire healthcare
information space.
NCPDP/HL7 Harmonization
• “standard, expected” areas of harmonization
include
– Trigger events/business flows – Datatypes, especially
• Identifiers (patients, clinicians, organizations, etc.) • Timing specifications (e.g. complex “scripts”)
– Vocabulary bindings
• Drug vocabulary candidates include (partial list) Snomed-CT, NDC, (and in the near future, RX-NORM)
Summary: harmonizing NCPDP and HL7?
• By following the HDF process outlined above, we can identify:
– Any changes to the RIM and it’s associated vocabularies needed to support semantic interoperability between the two standards for the common domain of “e-prescribing”
– Any changes needed to either standard to support semantic interoperability between them.
• The end result (after implementing any changes
identified), will be a precise mapping between the two standards for the messages in their common domain, a mapping that will support the semantic interoperability of their common information domain.
What about the NCPDP/HL7 project?
The HL7-NCPDP Coordination Project is basically at four levels:
• Short term mapping project (bi-directional HL7 V 2.3 and from NCPDP Script prescription) to enable demonstration at HIMSS 2005
• The mapping demonstrations at HIMSS 2005 and NCPDP annual meeting
• Mid term efforts to coordinate HL7 and NCPDP standards including finishing the basic mapping (renewals),
preparation of a “implementation guide”, setting up a Change Management Plan
What about the NCPDP/HL7 project?
• Long term efforts, not defined in current
project plan, will involve “aligning” Version
3.0 and the NCPDP to be developed
messaging model. The latter project is least
well defined and will be influenced by how
NCPDP decides to develop an information
model next month.
• Status: The technical mapping is proceeding
but is not complete
What about the NCPDP/HL7 project?
• The demo at HIMSS 2005 currently involves three “use cases” and four pod participants (EPIC, SureScripts, VHA and Apelon).
• Cleveland Clinic based EPIC system sending an HL7
medication order to SureScripts that will map the message into SCRIPT for transmittal to a community pharmacy. Currently we do not have retail pharmacy IT vendor
although NDC is considering joining. Absent that, SureScripts will show the SCRIPT message.
• The VHA will demonstrate receiving a SCRIPT message (from SureScripts) and mapping it into an HL7 medication order.
What about the NCPDP/HL7 project?
• Apelon will demonstrate the ability to
map/translate commercial (such as First Data Bank) and standard (NDC) drug terminologies into and out of RxNorm.
• In addition to the e-prescribing demonstration at HIMSS, each of the commercial vendors will have a theatre presentation. The NLM, one of the HL7 partners, is very interested in promoting RxNorm and will have a theatre presentation. Presumably, NCPDP will also make such a presentation.
What about the NCPDP/HL7 project?
• We continue to look for participating vendors and
potentially cross-link e-prescribing with EHR systems. We will coordinate overall message and marketing for e-prescribing at HIMSS 2005. NCPDP has assigned a project person to coordinate the demo with us and
replicate it at the NCPDP annual meeting in March 2005. • A walk through of the demonstrations and presentations
