3M Healthcare Data Dictionary (HDD)

From Concept Hub

3M Care Innovations Software

This diagram illustrates how the HDD receives messages from multiple disparate systems, translates, normalizes, encodes, and sends the structured and encoded data to the CDR for storage. (Copyright © 2008, 3M HIS. All rights reserved.)

The 3M Clinical Data Repository (CDR) is currently being used by both the Department of Defense (DoD) and commercial facilities. It is the back end to the DoD’s Armed Forces Health Longitudinal Technology Application (AHLTA) (formerly CHCS II ; US DoD military health system) and consists of a number of relational tables and several services that allow read, write, maintenance, and modifications of the tables. An Enterprise Master Patient Index (EMPI) and the Healthcare Data Dictionary (HDD) support the CDR.

• The CDR holds the instance data, which is organized into a complete longitudinal patient record that can be shared among all the members of an integrated service network.
• The EMPI uses advanced matching logic to assign a unique global identifier to each patient across the enterprise.
• The HDD houses the metadata that is used to encode, standardize, and normalize data stored in the CDR.

The HDD is a relational database. These HDD tables provide a way to store data with consistent meaning and allow the creation of various semantic (meaningful) links among concepts. The dictionary is not a process or an application. Rather, it serves as a reference source for other programs, specifically the interface programs and the data storage and retrieval services. These programs use the information stored in the HDD to transform data as it passes into and out of the CDR. In its role, the HDD is sometimes referred to as an interlingua.

Three Key Components of the HDD

Information Models

An information model describes the relationships among clinical events and terminologies in a fashion that gives them meaning and context. While it enforces accepted truths, it allows uncertainty and even errors. An information model cannot and should not prevent a clinician from making what seems to be an incorrect or uncertain diagnosis, but it will help prevent the storage of illogical or impossible findings such as “fractured hair”. Information models mediate between data gathering software and databases and are supported by terminologies. Terminologies provide the coded content for values instantiated in the patient record by the information model. In addition to being clinically correct, a good information model must be complete, flexible, extensible, supported by vocabulary, and obeyed by the data gathering software. ^{[1] [2]}

Information Model Example

The 3M Medical Information models are written in Abstract Syntax Notation 1 (ASN.1). The following is a simplified ASN.1 definition of a medication order, followed by sample instance data.

ASN.1 Definition: A MedicationOrder event is defined by a set of observations

MedicationOrder ::= SET {
   drug                Drug,
   dose                Decimal,
   route               Route,
   frequency           Frequency, 
   startTime           DateTime, 
   endTime             DateTime,
   orderedBy           Clinician,
   orderNum            OrderNumber}

CDR Instance Data: The ASN.1 model references the HDD when a coded element is specified in the definition and stores (NCID codes)

MedicationOrder { 
   drug                Ampicillin (NCID 1234), 
   dose                500, 
   route               Oral (NCID 5678), 
   frequency           Q6H (NCID 9123), 
   startTime           09/01/95 10:01, 
   endTime             09/11/95 23:59, 
   orderedBy           John Doe MD (NCID 8123), 
   orderNum            A234567 } 

Knowledge Base

In this example the brown links represent hierarchical relationships: "Sodium is a Lab Result, Chem 4 is a Lab Test." The green links represent a type of non hierarchical relationship: "Sodium is a component of a Chem 4." (Copyright © 2008, 3M HIS. All rights reserved.)

The knowledge base defines the domains referenced by the information models. Domains are the logical sets into which concepts are grouped (example: Clinical Specimen, Lab Test). Domains are created and populated by the web of relationships among concepts. Semantic relationships fall into two broad categories: hierarchical and non hierarchical. Hierarchical relationships are parent child or "is a" types of relationships (example: Influenza is a Virus, Oral is a Route of Administration). Non hierarchical relationships are all the other meaningful ways that concepts can be linked. The HDD's knowledge base is capable of supporting multiple hierarchies. Consequently a single concept can participate in many domains. Having this capability allows the dictionary to remain concept based. Without multiple hierarchies a new concept identifier would have to be created for each domain that the concept participated in

Vocabulary

The vocabulary identifies medical concepts and organizes them to support synonyms, multiple surface forms, and other lexical characteristics. The HDD is a controlled medical vocabulary that follows best medical informatics practices such as concept permanence, multiple hierarchies, and meaningless identifiers.^[3] Each unique concept in the HDD is assigned a Numeric Concept Identifier (NCID) code.

References

1. ↑ Huff SM, Rocha RA, Solbrig HR, Barnes MW, Schrank SP, Smith M. "Linking a medical vocabulary to a clinical data model using Abstract Syntax Notation 1." Methods Inf Med; Nov 1998 (Vol. 37, Issue 4-5, Pages 440-52)
2. ↑ Huff SM, Carter JS. "A characterization of terminology models, clinical templates, message models, and other kinds of clinical information models." In: Chute C, editors. Proceedings of International Medical Informatics Association-Working Group 6 Meeting (Health Concept Representation and Natural Language Processing); 1999.
3. ↑ Cimino JJ. "Desiderata for controlled medical vocabularies in the twenty-first century." Methods Inf Med; Nov 1998 (Vol. 37, Issue 4-5, Pages 394-403)

Last modified at 5/12/2008 10:50 AM by Shakib,Shaun C