1 / 24

Chapter 14

Ontologies , vocabularies, and data models. Chapter 14. Introduction. Why standard coded data are essential for accurate and reliable execution of decision logic How to unambiguously reference data in the electronic medical record (EMR) from CDS expression

studs
Download Presentation

Chapter 14

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ontologies, vocabularies, and data models Chapter 14

  2. Introduction • Why standard coded data are essential for accurate and reliable execution of decision logic • How to unambiguously reference data in the electronic medical record (EMR) from CDS expression • Alternatives for pre- and postcoordinated representations of data • Representation of patient data as name-value pairs • The relationship between terms and information/data models that provide the context of use • Terminology in the life cycle of CDS programs • The next steps that are needed in standardizing models and terminology for use in CDS modules

  3. The need for coded data • encoded data are required in order to have accurate and reproducible execution of decision logic • oral, take orally, by mouth, per os, via nasogastric tube, po, p.o.,PO, swallow

  4. advantages • coded data can be used to support different report formats for particular users • makes the maintenance of decision logic easier • translate more easily to different languages • Storing codes may save storage space

  5. Referencing data in decision logic • the clinical information must contain sufficient detail and must be structured in a way that the CDS system understands • the clinical information must be transformed from one format to another • The Arden Syntax does not specify the format of a reference to data in an associated clinical application • The curly braces problem

  6. computable syntaxes proposed for representing the form and structure of clinical information • GALEN Representation and Integration Language (GRAIL) (Rector and Nowlan 1993; Rector et al. 1997) • Abstract Syntax Notation 1 (ASN.l) (ISOIIEC 8824-1 1990; ISO/IE 8825-1 1990; ISO/IEC 8825-2 1996) • Archetype Definition Language (ADL) (Beale and Heard 2006) • Web Ontology Language (OWL) (W3C 2004) • Clinical Element models (Coyle et al. 2003) • DICOM template ( EMA PS 3 Supplement 23 1997) • General Purpose Information Components (GPI s) models from CEN (CEN TC 251 2003) • description logics (Wikipedia 2006) • the Health Level Seven Reference Information Model (HL7 RIM) (Health Level Seven 2005c)

  7. Example. ASN 1 MedicationOrder ::= SET { drug Drug, dose Decimal, route DrugRoute, frequency DrugFrequency} MedicationOrder ::= SET { drug Penicillin VK, dose 500 mg, route Oral, frequency Every 6 Hours}

  8. Drug Antibiotic Analgesic Cardiovascular Penicillin Cephalosporin Aminoglycoside Methicillin Amoxicillin Nafcillin Figure 14‑1 A graphical representation of a simple semantic network of drug. The arcs in the diagram represent is-a relationships between the concepts in the network.

  9. the model and its as associated terminology represent an instance of an ontology • a model for a medication reaction MedicationReaction ::= SET { drug Drug, dose Decimal, route DrugRoute, manifestation Manifestation, reactionTimeDateTime } If there EXISTS a MedicationOrder and a MedicationReaction for the patient WHERE MedicationOrder.drug is-a MedicationReaction.drug THEN alert the ordering clinician.

  10. Issues of pre- and post coordination • The problem of referencing clinical data from decision logic is not completely solved even if implementers are using a common syntax and terminologies, since it is possible to represent the same information in multiple ways while using standard terminologies and information models • compositional Completeness • 착한의사 • 치과의사

  11. representations for the concept “Ibuprofen, 200 mg oral tablet.” Example 1 Medication: [RX563605, RxNorm, Ibuprofen 200 MG Oral Tablet] Example 2 Medication: [RX503378, RxNorm, Ibuprofen] Dose: Value: 200 Units: [258684004, SNOMED-CT, mg] Form: [385055001, SNOMED-CT, Tablet (a subtype of Oral dosage form)]

  12. Precoordination • Good points • easier to use due to the fact that they behave more like complete sentences • simplify data entry screens by requiring fewer fields for the user to fill out • easy to reference in decision logic • convenient when the possible number of precoordinated concepts is relatively small and manageable • avoids the problem of being able to combine pieces in a way that is incorrect or nonsensical

  13. Bad points • a precoordinated approach can lead to a combinatorial explosion of the number of concepts needed • As the specificity of the precoordinated concepts increases, so does the magnitude of the combinatorial explosion

  14. Postcoordination • avoid the problem of combinatory explosion • have a dictionary of words from which we can generate an almost unlimited number of sentences • Although the flexibility of this approach can keep the representation of clinical information manageable • it may also allow the creation of statements that do not make sense • To prevent situations like this, postcoordination models need extra metadata and rules to specify which values are allowable under various circumstances

  15. The choice between pre- and postcoordinated approaches • the nature of the concepts • the way they will be used • When the number of things that can be said is relatively small and well-constrained - precoordinated concepts may be the most useful. • When pieces of information can be combined in many different ways - consider using postcoordination

  16. information models • can be thought of as a series of fields with well-defined semantic relationships • Terminologies • the source of possible values for these fields • terminology models and information models often overlap

  17. Data representation using name-value pairs • complete data representation requires the combination of an information model and a terminology • “numbness of right arm and left leg” • “numbness of left arm and right leg” Numbness (44077006) Right (24028007) Arm (40983000) Left (7771000) Leg (30021000) Numbness (44077006) Left (7771000) Arm (40983000) Right (24028007) Leg (30021000)

  18. “numbness of left arm and right leg” in HL7 RIM • name-value pair approach or entity-attribute-value approach • Using a combination of a code that names the kind of observation (the question) and a value that is the actual result of the observation • used in HL7 Version 2, Version 3, and in the HL7 Clinical Document Architecture (CDA) as well as in the DICOM standard. Observation.code: Diagnosis.primary (LOINC code 18630-4) Observation.value: Numbness (SNOMED CT 44077006) Observation.targetSiteCode: Arm (SNOMED CT 40983000) Qualifier.name: Laterality; Qualifier value: Left (7771000 SNOMED CT) Observation.targetSiteCode: Leg (SNOMED CT 30021000) Qualifier.name: Laterality; Qualifier value: Right (24028007 SNOMED CT)

  19. Observation.code: Diagnosis.primary (LOINC code 18630-4) Observation.value: Numbness (SNOMED CT 44077006) Observation.targetSiteCode: Arm (SNOMED CT 40983000) Qualifier.name: Laterality; Qualifier value: Left (7771000 SNOMED CT) Observation.targetSiteCode: Leg (SNOMED CT 30021000) Qualifier.name: Laterality; Qualifier value: Right (24028007 SNOMED CT) Observation.code: Diagnosis.primary (LOINC code 18630-4) Observation.value: Numbness (SNOMED CT 44077006) Qualifier.name: Has-Location: Arm (SNOMED CT 40983000) Qualifier.name: Laterality; Qualifier value: Left (7771000 SNOMED CT) Qualifier.name: Has-Location: Leg (SNOMED CT 30021000) Qualifier.name: Laterality; Qualifier value: Right (24028007 SNOMED CT)

  20. sharing of decision logic does not require that all participants use the same physical database or the same standard codes • it is often best to store enterprise specific codes in the patient database in order to keep errors in standard coded terminologies from being propagated into the longitudinal patient record • whatever terms and models are used in the electronic patient record, they must be able to be mapped to the standard shared models and codes

  21. Terminology in the life cycle of decision support programs • Terminology plays an important role in all aspects of the life cycle of decision support programs. The usual life cycle consists of the following phases: • Initial authoring of the program • Testing of the program using test data, or using real data in a test environment • Revision of the logic based on testing • Deployment of the program into a production system • Monitoring of the program's behavior in the live environment • Repeating steps 1 through 5 as needed • Retirement

  22. In situations where decision logic is shared between heterogeneous systems • Import & Export can occur • Importing decision logic • the local EMR can be designed so that it has services that can answer queries based on standard shared information models and terminologies • the queries in the imported logic must be translated from the standard model to the local model and terminology

  23. the most practical approach is to transform incoming data from their native form into a single canonical form when they are stored in the EMR • This is accomplished by having the interface software be aware of the various expected models for a given kind of data and using a library of model mappings to convert from the inbound form of the data to the canonical EMR model of the data

More Related