Development of a Standard Terminology to Support Medication Messages

1. 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

2. HL7 Medication Messagesand Goals Stanley M. Huff, M.D. Intermountain Health Care

3. HL7 Mission “… to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.”

4. HL7 Medication Transactions(from HL7 Chapter 4) 1. ORM/RXO 1. ORM/RXO 2. RDE/RXE 3. RDS/RXD 2. RDE/RXE Ordering System Pharmacy/ Treatment Supplier Nursing System 4. RGV/RXG 5. RAS/RXA 5. RAS/RXA

5. 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

6. 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

7. HL7 Vocabulary TC Purpose: To identify, organize and maintain coded vocabulary terms used in HL7 messages.

8. 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

9. 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

11. Vocabulary Technical CommitteeDrug Information ModelJames J. Cimino, M.D.Columbia University

12. 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

13. 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

14. Drug Terminology Modeling • Some agreement on the concept of a "clinical drug" • More-specific terms • Less-specific terms • Dosage forms • Routes

15. Clinical Drugs • Active ingredients • Dosage form

16. Trademark Drugs • Trademark • Active ingredients • Dosage form

17. Manufactured Components • Inactive ingredients • Dispensing and Inventory • Manufacturer (may not be the same as supplier) • Active ingredients • Dosage form • Trademark

18. Country-SpecificPackaged Product • Size • Units • “Free of” • Package-specific devices (e.g., applicator, syringe, etc.) • One or more packaged components • Country

19. Active Ingredients • Chemical • Strength - Amount - Units - In Volume - In Volume Units

20. Drug Model Hierarchy Packages Medications Drug Class International Package Identifiers Chemicals is-a Not-Fully-Specified Drug is-a Ingredient Class is-a Country-Specific Packaged Product Clinical Drug is-a is-a is-a Ingredient Composite Clinical Drug Trademark Drug is-a is-a Manufactured Components Composite Trademark Drug

21. Orderable Drugs • Clinical drugs • Trademark drugs • Composite clinical drugs • Composite trademark drugs • Manufactured components • Packaged product • “Not Fully Specified” drugs

22. “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”)

23. 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

25. Towards Interoperability ofDrug Knowledge Bases:Feasibility Assessment Carol Broverman, Ph.D. First DataBank

26. 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

27. 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.

28. Clinical Drug (DKB1) 22361 Venlafaxine HCl 150 MG Cap Controlled Release Clinical Drug (DKB2) 034379 Venlafaxine HCl 150 MG Capsule Sustained Release 24HR Mapping and Interoperability ? ? Question: Can these concepts be interchanged? Answer: DEPENDS on the purpose of the interoperability.

29. 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

30. 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 singlepopulated 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!)

31. 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)

32. Factors for Evaluation / Use Cases Type of identifier Type of Message Interoperability use case Ingredient Clinical drug Trademarked drug … Patient history order dispense inventory ... Order/dispense order/drug interaction administration/nursing feed data repository dosing contraindications reimbursement ... “Unifying concept” Loss/Blurring of information Source concept vendor1 Source concept vendor2 Source Concept vendorN

33. 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

34. 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

35. 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

36. 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

38. A Standard Drug Vocabulary Timothy McNamara, MD, MPH&TM

39. 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)

40. 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

41. 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…)

42. 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.

43. Nomenclature Granularity Fruit Stand 1

44. Nomenclature Granularity “Apple” ¹ “Macintosh” “Red Delicious” “Granny Smith” “Golden Delicious” “Gala” “Jonathan”

45. Nomenclature Granularity Fruit Stand 1 Fruit Stand 2

46. Nomenclature Granularity

47. Nomenclature Granularity

49. Drug Vocabulary in the Unified Medical Language System A model for future HL7 efforts? Stuart J. Nelson, M.D.

50. 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.