Domain Specification and Code Use within HL7 Messages

Download Report

Transcript Domain Specification and Code Use within HL7 Messages

Development of a Standard
Terminology to Support
Medication Messages
Stanley Huff, MD - Intermountain Health Care
James J. Cimino, MD - Columbia University
Carol Broverman, PhD - First DataBank
Timothy McNamara, MD, MPH&TM - Multum Information Services
Stuart J. Nelson, MD - National Library of Medicine
HL7 Medication Messages
and Goals
Stanley M. Huff, M.D.
Intermountain Health Care
HL7 Mission
“… to create flexible, cost effective approaches,
standards, guidelines, methodologies, and
related services for interoperability between
healthcare information systems.”
HL7 Medication Transactions
(from HL7 Chapter 4)
1. ORM/RXO
Ordering
System
1. ORM/RXO
2. RDE/RXE
2. RDE/RXE
3. RDS/RXD
Pharmacy/
Treatment
Supplier
4. RGV/RXG
5. RAS/RXA
5. RAS/RXA
Nursing
System
HL7 Encoded Medication
Order
MSH|...
PID|...
ORC|NW|1000^OE||||E|^Q6H^D10^^^R
RXO|RX1001^Polycillin 500 mg
TAB^L|500||MG|||||G||40
RXR|PO
Problem: No Standard Code
• Site 1:
RXO|RX1001^Polycillin 500 mg
TAB^L|500||MG|||||G||40
• Site 2:
RXO|PH2345^Polycillin 500 mg
TAB^L|500||MG|||||G||40
HL7 Vocabulary TC
Purpose:
To identify, organize and maintain coded
vocabulary terms used in HL7
messages.
Why HL7 Vocabulary?
• Decrease time and cost of implementations
• Approach “plug-and-play”
• Enable data sharing
– Mergers due to managed care
– Regional or national clinical studies
– Disease prevention and control
• Enable sharing of decision support modules
– Alerts
– Protocols
– Clinical pathways
HL7 Vocabulary Development
• Reference existing vocabularies
• Collaborate with other SDO’s
– DICOM
– ASTM
– X12
• Add value by creating linkage between HL7
messages and existing vocabularies
• Only add items that do not already exist
• Collaborate with vocabulary developers
Vocabulary Technical Committee
Drug Information Model
James J. Cimino, M.D.
Columbia University
Drug Terminology Efforts in HL7
• Need for medication terms
• Much source data generated by
pharmacy systems
• Pharmacy knowledge base vendors
are exploring ways to place their
terminologies in the public domain
• Vocabulary TC convened meetings to
explore ways of collaborating
Disclaimer
• Nothing is a balloted standard yet
• TC has not yet proposed a formal model
• TC has not yet proposed a plan of action
• TC is still defining scope and goals
Drug Terminology Modeling
• Some agreement on the concept
of a "clinical drug"
• More-specific terms
• Less-specific terms
• Dosage forms
• Routes
Clinical Drugs
• Active ingredients
• Dosage form
Trademark Drugs
• Active ingredients
• Dosage form
• Trademark
Manufactured Components
• Active ingredients
• Dosage form
• Trademark
• Inactive ingredients
• Dispensing and Inventory
• Manufacturer (may not be
the same as supplier)
Country-Specific
Packaged Product
•
•
•
•
Size
Units
“Free of”
Package-specific devices (e.g.,
applicator, syringe, etc.)
• One or more packaged components
• Country
Active Ingredients
• Chemical
• Strength
- Amount
- Units
- In Volume
- In Volume Units
Drug Model Hierarchy
Packages
Medications
Drug Class
Chemicals
International
Package Identifiers
is-a
Not-Fully-Specified Drug
Ingredient
Class
is-a
Country-Specific
Packaged Product
Clinical Drug
is-a
Ingredient
is-a
is-a
Trademark Drug
is-a
Manufactured
Components
is-a
Composite
Clinical Drug
is-a
Composite
Trademark Drug
Orderable Drugs
• Clinical drugs
• Trademark drugs
• Composite clinical drugs
• Composite trademark drugs
• Manufactured components
• Packaged product
• “Not Fully Specified” drugs
“Not Fully Specified” Drugs
• Things that can appear in orders (e.g.,
written prescriptions)
• Must have some ingredient specified
– Chemical
– Chemical class
– Ingredient set
– Trademark
• Additional attributes optional
– strength
– dose form
• Locally-acceptable order sets may
appear (e.g., “antibiotic of choice”)
Next Steps
• Gain an understanding of the complexities
• Clarify the scope of the committee's work
• Begin some experiments to explore practical
methods for achieving interoperability
Towards Interoperability of
Drug Knowledge Bases:
Feasibility Assessment
Carol Broverman, Ph.D.
First DataBank
Problem Statement
• Goal: Develop a single reference standard for
medication terminology
• Reality: Historical evolution and wide deployment
of different medication terminologies makes this
challenging at best
• Recommendation: Aim for achievable subgoals
that will enable future convergence
– standardize some of the components first:
routes and dose forms
– recognize business issues
The Problem with the Problem
• Request: Using a newly-defined reference
terminology, establish mappings between
drug terminologies that are “good enough” for
interoperability.
• Premise: When different sources are mapped
via a single reference concept, something is
lost in the translation. Depending on the
usage, this “loss” may be critical.
Mapping and Interoperability
Clinical Drug (DKB1)
?
• 22361
Venlafaxine HCl
150 MG Cap
Controlled Release
Clinical Drug (DKB2)
• 034379
?
Venlafaxine HCl
150 MG Capsule
Sustained Release 24HR
Question: Can these concepts be interchanged?
Answer: DEPENDS on the purpose of the interoperability.
Reference Terminologies
• Reference terminology: a formally-defined
concept-based terminology, founded on an
underlying information model
–
–
–
–
Concepts have definitional attributes
Value sets of definitional attributes come from a
consistent canonical domain (e.g. the list of “dose
forms” is known/enforced)
Concepts have defined/constrained relationships
Formalization allows for automatic classification
Merging Reference Terminologies Into
a Single Reference Terminology
• Each of several existing deployed drug knowledge
base is based on a different established reference
terminology
• Task of building a single populated reference
terminology from these
– merging/mapping different reference
terminologies
• Position: It is not feasible to preserve several
different sets of rigorous meanings concurrently
within a single model. (one concept per meaning!)
What is a “Good Enough” Mapping?
• “Good enough?” has to be asked in context -what is the purpose of the “interoperability?”
–
–
–
–
–
–
–
Good enough for report generation?
Good enough to support drug interaction
detection?
Good enough to do allergy detection?
Good enough to support dispensing from order?
Good enough to support nursing/administration?
Good enough for dosing suggestions?
Good enough for “decision support” (decision
support can be any of these use cases, and more)
Factors for Evaluation / Use Cases
Type of identifier
Type of Message
Ingredient
Patient history
Clinical drug
Trademarked drug
…
order
dispense
inventory
Order/dispense
order/drug interaction
administration/nursing
feed data repository
...
“Unifying concept”
Interoperability use case
dosing
Loss/Blurring
of information
Source concept Source concept Source Concept
vendor1
vendor2
vendorN
contraindications
reimbursement
...
Possible Process to Validate Mappings
• Compose each case for evaluation:
–
–
–
each pair of different source concepts (s1, s2)
among (N) source terminologies for a given unifying
concept (U)
the associated “loss of original meanings” (L)
the type of message containing the concept and its
interoperability context within a use case (C)
• the expectations of both the producer and
consumers of the message
• Evaluate/tag mappings with approved contexts
–
this must consider multiple opinions
Evaluation Combinatorics
(Worst-case)
• Evaluate ((s1, s2… sn), U, L, C):
–
–
–
–
–
–
each pairing from 7 source vocabularies (21)
2 possible orders of translation (and loss of meaning) (L)
number of concept instances (~250,000 +)
~ 300 usages (~15 different message senders/types *
~20 possible receivers)
(2 * 21 * 250,000 * 300) = 3,150,000,000 assessments
Ongoing as new data comes in
• This is clearly a “worst case” analysis
• Some definitions will be the same
–
Hard to gauge true complexity without doing all the work
a priori
Implementation Issues
• Challenge to do it all
• Must be understandable and implementable
by the end-user
• Most benefit may be gained from order
communication use case (order/dispense)
• Decision support usages are complex
–
Actual “context” not known a priori when message
is constructed and sent
Recommendation:
Set Achievable Subgoals
• Establish reference terminology for routes
and dose forms; process is the same
• These are sub-terminologies of the end goal
• Will put us on a “path towards convergence”
• Recognize business realities
–
–
–
existing/different terminologies will persist
business case must be established by end-users
terminology providers will be liable for mappings
so must do the work to guarantee reliability
A Standard Drug Vocabulary
Timothy McNamara, MD, MPH&TM
Environment
• $76.6 billion in ADE-related medical
bills annually
• 60,000 to 140,000 ADE deaths per
year (JAMA, 1995)
• 11% of admissions (up to 30% in
the elderly) are due to ADEs. (J
Intern Med, 1990)
Environment
• Little Physician Usage of Clinical Systems
because
• Few System have Succeeded in
Automating Physician Processes
because
• Lack of Standards for Describing the
Services, Products, and Terms that
Physicians Use
Characteristics
• Code set should be maintained by a central code-assigning authority.
• Code set should be available in the public domain at low/no cost.
• Code assignment process must open for review, comment, and public
participation.
• Code set must be continuously updated as new drugs enter the market.
• Updates to the code set must be made available to the public on a
weekly or even daily basis. Web-based distribution of updates should
be supported.
• Once a code is used, it must never be removed from the code set.
• Each code assigned must be unique.
(continued…)
Characteristics
(...continued)
• No code should carry meaning.
• The code set should support multiple levels of abstraction. At a
minimum, the code set should provide codes representing the
following abstractions: therapeutic category, drug description, clinical
drug description, and manufactured drug description.
• The code set should be "backwards compatible" with the NDC system
but not reliant on the NDC system.
• The code set should be designed with a long-range view toward
compatibility with evolving international standards for representing
drugs and drug products.
• The code set should include information regarding the "regulatory
status" of drugs.
• The code set should deal exclusively with drugs.
Nomenclature Granularity
Fruit Stand 1
Nomenclature Granularity
“Apple”

“Macintosh”
“Red Delicious”
“Granny Smith”
“Golden Delicious”
“Gala”
“Jonathan”
Nomenclature Granularity
Fruit Stand 1
Fruit Stand 2
Nomenclature Granularity
Nomenclature Granularity
Drug Vocabulary in the
Unified Medical Language
System
A model for future HL7 efforts?
Stuart J. Nelson, M.D.
UMLS Purpose
• Retrieve and integrate relevant information
from:
– computer-based patient records
– factual databanks
– bibliographic databases
– full-text sources
– expert systems
• Provide path for adding new vocabularies
and new terms.
UMLS Metathesaurus
A Vehicle For
• Distribution of vocabularies in a common
format.
• Linking these vocabularies to each other.
• Representing multiple subsets and
hierarchies.
• Ensuring a forward migration path to an
eventual standard.
What Drug Vocabulary Should
be in UMLS?
• Variable Representations
– MeSH
– READ
– SNOMED
• Possible Additional Sources
– Multum
– Micromedex
– First Databank
– Medispan
– Index Nominum
Examples of Current UMLS
Representations
• Aspirin and Aspergum (1 concept)
• Septra Suspension, Septra Grape
Suspension (2 concepts)
What is UMLS Doing?
• New Semantic Type: Clinical Drug
– A pharmaceutical preparation as produced by the
manufacturer. The name usually includes the
substance, its strength, and the form, but may
include the substance and only one or the other
two items.
• New Allowable Relationship: Has_ingredient
– Reciprocal: Ingredient_of
– Contains as a component of a preparation.
What about Finer Levels?
• NDC Codes- Not in Metathesaurus
– Mapping should be maintained by PKBVs
• Clotrimazole Cream 1%
– Topical, Dermal -- 100897
– Vaginal
-- 100898
Further Needs
• Value Set for Dose Forms
• Value Set for Routes of Administration
• Manageable Differences in Data
Representation between PKBVs
A Model for Further Efforts?
• NLM Closely Following Standards Efforts
• Representation of Value Sets
• Foster Cooperative Environment
Discussion