HL7 NCPDP e-prescribing harmonization: using the v3 HDF for as a basis for semantic interoperability

Transcription

1 HL7 NCPDP e-prescribing e harmonization: using the v3 HDF for as a basis for semantic interoperability Mark Shafarman HL7 Chair Applications Architect, Oracle Corporation [email protected] August 2004 Copyright 2004, HL7 1

2 Harmonizing 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. How this relates to clinical statements and CDA. 23 August 2004 Copyright 2004, HL7 2

3 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 Reference implementations of EHR functional requirements 23 August 2004 Copyright 2004, HL7 3

4 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 Including documents, reports, and rules for decision support 23 August 2004 Copyright 2004, HL7 4

5 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 23 August 2004 Copyright 2004, HL7 5

6 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 computer applications. 23 August 2004 Copyright 2004, HL7 6

7 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. 23 August 2004 Copyright 2004, HL7 7

8 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 23 August 2004 Copyright 2004, HL7 8

9 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) 23 August 2004 Copyright 2004, HL7 9

10 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. Without any loss of information. 23 August 2004 Copyright 2004, HL7 10

11 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. 23 August 2004 Copyright 2004, HL7 11

12 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 State transitions/events 23 August 2004 Copyright 2004, HL7 12

13 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. 23 August 2004 Copyright 2004, HL7 13

14 Harmonizing messaging standards References: The HL7 Development Framework, (HDF) chapters 2 and 3 Chapter 2: Requirements Gathering and Analysis Chapter 3: Requirements Normalization and Harmonization 23 August 2004 Copyright 2004, HL7 14

15 HDF generic mapping process Mapping into v3 RIMderived 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 structures. 23 August 2004 Copyright 2004, HL7 15

16 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) 23 August 2004 Copyright 2004, HL7 16

17 Some slightly less technical words UML (Universal Modeling Language) provides a graphical formalism for representing complex concepts as structures. It also supports objectoriented 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. 23 August 2004 Copyright 2004, HL7 17

18 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. 23 August 2004 Copyright 2004, HL7 18

20 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. 23 August 2004 Copyright 2004, HL7 20

21 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 August 2004 Copyright 2004, HL7 21

24 NCPDP and HL7 v3 semantic mapping E-prescribing UML Problem-Space Model (a la HDF) *RIM / DMIM / CDA V3 RIM e-rx Model Script v 5 (or 4.7) * RMIM / HMD / XSD NCPDP e-prescribing Application 23 August 2004 Copyright 2004, HL7 24

25 HL7 v 2.x / v3 semantic mapping E-prescribing UML Problem-Space Model (a la HDF) *RIM / DMIM / CDA V3 RIM e-rx Model HL7 v 2.3 (or ) * RMIM / HMD / XSD HL7 v 2.x e-prescribing Application 23 August 2004 Copyright 2004, HL7 25

27 A spreadsheet for model mapping Domain Analysis Model (DAM) columns: Element Element type (class, genspec, association, attribute) Parent/containing class Definition Datatype Multiplicity Rim Model columns: Class Class Code Element Type (class, genspec, association, attribute) DMIM clone name Attribute name Association Index # Definition Multiplicity Datatype Vocab Domain 23 August 2004 Copyright 2004, HL7 27

28 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). Jump to model mapping spreadsheet example. 23 August 2004 Copyright 2004, HL7 28

29 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. 23 August 2004 Copyright 2004, HL7 29

30 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 23 August 2004 Copyright 2004, HL7 30

31 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 23 August 2004 Copyright 2004, HL7 31

32 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 23 August 2004 Copyright 2004, HL7 32

33 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. 23 August 2004 Copyright 2004, HL7 33

34 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) 23 August 2004 Copyright 2004, HL7 34

35 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. 23 August 2004 Copyright 2004, HL7 35

36 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 23 August 2004 Copyright 2004, HL7 36

37 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 23 August 2004 Copyright 2004, HL7 37

38 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. 23 August 2004 Copyright 2004, HL7 38

39 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. 23 August 2004 Copyright 2004, HL7 39

40 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 NCPDP has assigned a project person to coordinate the demo with us and replicate it at the NCPDP annual meeting in March A walk through of the demonstrations and presentations will occur at the winter working group meeting. 23 August 2004 Copyright 2004, HL7 40

41 What about the CDA and clinical statements? If the prescription can be represented using the v3 clinical statements model, then it can be used within a CDA rel-2 document at the entry/clinical statements choice box. Upon receipt of a CDA rel-2 document with a prescription (or several) as clinical statements, the receiving system can extract the prescriptions from the document, and send them (electronically) as v3 messages to the (inpatient or outpatient) pharmacy to be filled. 23 August 2004 Copyright 2004, HL7 41