4. Rationale
• As with other domains, local systems have
idiosyncratic names for clinical documents
• Need a common, controlled vocabulary
• Needed for HL7 CDA standard
– HL7 v2 too
• Timeline
– 06/2000 Document Ontology Task Force
– 09/2003 First axis values and LOINC codes
– ~2005 Expanded SMD domain
– 10/2007 Revised axis value approval
5. Document Type Codes
• Created to provide consistent
semantics for names of documents
exchanged b/w independent systems
• Supported Uses
– Retrieval
– Organization
– Preparation of templates
– Display
Frazier P, Rossi-Mori A, Dolin RH, Alschuler L, Huff SM. The creation of an ontology of clinical document names. Stud Health Technol Inform. 2001;84(Pt 1):94-8.
6. What is a Document?
• Document = Collection of information
– Sentences, sections
– Distinguished from “panels”, which have
enumerated discreet contents
• Formal Document Ontology model/rules
apply to “clinical notes”
– Clinical document (per HL7 CDA), produced by
clinicians spontaneously or in response to a
request for consultation
– Does not apply to “reports”, produced in
response to an order for a procedure
7. Approach
• Started with empiric analysis of over
2000 document names
– Mayo, 3M/Intermountain, VA in SLC, VA in
Nashville
• Find the level of granularity that best
meets the exchange use case
8. Finding the Commonality
• Ultra-specific local names:
– Dr. Evil’s Friday Afternoon Pain Clinic Note
• Generalizable elements:
– Outpatient Pain Clinic Note
• Local codes may still be needed
– Can send both local and universal codes in HL7
– Mapping to the universal code enables
interoperability and aggregation
10. Names Based on Document Content
• Names based on the expected
information content
• NOT based on the document format
– Text, scanned images, structured entry
form, XML, etc would all have the same
LOINC code if the information content
was the same
Assume that these other important attributes would be
sent in different fields of the message
11. What’s NOT in a Document Name
• Specific author
• Specific location of service or dictation
• Date of service
• Status (e.g. signed, unsigned)
• Security/privacy flags (protected)
• Updates/amendments to a document
Assume that these other important attributes would be
sent in different fields of the message
12. Model of Document Names
• Subject Matter Domain
– E.g. Cardiology, Pediatric Cardiology, Physical Therapy
• Role
– Author training/professional classification (not @ subspecialty)
– E.g. Physician, Nursing, Case Manager, Therapist, Patient
• Setting
– Modest extension of CMS’s definition (not equivalent to location)
– E.g. Inpatient Hospital, Outpatient, Emergency Department
• Type of Service
– Service or activity provided to/for the patient (or other subject)
– E.g. Consultation, History and Physical, Discharge Summary
• Kind of Document
– General structure of the document
– E.g. Note, Letter, Consent
13. Rules for Constructing Names
• LOINC has enumerated value lists for axes
• Names need a Kind of Document value and
at least one of the other four axes
Component Prop Time System Scale Method
<Type of Service> <Kind of Document> Find Pt <Setng> Doc <SMD>.<Role>
• Combinations from within an axis
– Allowed where they make sense (SMD, Service)
– Represented with a plus (+)
• Makes use of the curly brace notation
• LOINC Class = DOC.CLINRPT
14. Example LOINC Codes
Component Prop Time System Scale Method
Group counseling note Find Pt Inpatent Hospital Doc {Provider}
Evaluaton and management note Find Pt Outpatent Doc {Provider}
Evaluaton and management note Find Pt {Setng} Doc {Provider}
History and physical note Find Pt {Setng} Doc {Provider}
Inital evaluaton note Find Pt {Setng} Doc Physician
Subsequent evaluaton note Find Pt {Setng} Doc Nurse Practtoner
{curly braces} notation: send that content as a
separate item in the message (field or segment)
15. Hierarchy in LOINC
• Constructed a first-pass Component hierarchy
based on the Type of Service axis
– Ignored Kind of Document
• Multi-axial hierarchy is generated based on the
component hierarchy
– (available as separate download)
• Could imagine construction of other hierarchies,
like context-specific use cases
18. Ontology Evolution and Refinement
• Ongoing evaluation and evolution
• Exceptional contributions from
Columbia University and the VA
• In particular, expanded original SMD
value list with ABMS specialty names
and iterative discussion
Shapiro JS, Bakken S, Hyun S, Melton GB, Schlegel C, Johnson SB. Document ontology: supporting narrative documents in electronic health records. AMIA Annu
Symp Proc. 2005:684-8.
19. Iterative Evaluation Case Study:
NYPH-CUMC
SMD Role Setng Type of Service Kind of Document Overall Distnct
Original CDO 26.7% 99.9% 99.9% 43.5% 100% 23.4% 7.9%
(n=894)
Expanded CDO 98.6% 100% 100% 99.9% 99.9% 98.5% 39.1%
(n=935)
• Hyun S, Shapiro JS, Melton G, Schlegel C, Stetson PD, Johnson SB,
Bakken S. Iterative evaluation of the Health Level 7--Logical
Observation Identifiers Names and Codes Clinical Document Ontology
for representing clinical document names: a case report. J Am Med
Inform Assoc. 2009 May-Jun;16(3):395-9.
• Summary
• More documents could be fully specified in with the expanded CDO
• Many documents map to one LOINC code – factor of local names
and suitable LOINC values
• Inter-rater reliability was very good
20. Nursing
SMD Role Setng Type of Service Kind of Document Overall Distnct
SMD-enhanced 74% 100% 100% 100% 100% 74.5% 33%
CDO (2005) (n=94)
Hyun S, Shapiro JS, Melton G, Schlegel C, Stetson PD, Johnson SB, Bakken S. Iterative evaluation of the Health Level 7--Logical Observation Identifiers Names and Codes
Clinical Document Ontology for representing clinical document names: a case report. J Am Med Inform Assoc. 2009 May-Jun;16(3):395-9.
• In a separate analysis, 38% of the section headings
(n=308) from nursing documents could be
mapped to existing LOINC codes
• Hyun S, Bakken S. Toward the creation of an ontology for nursing
document sections: mapping section names to the LOINC semantic
model. AMIA Annu Symp Proc. 2006:364-8.
21. German University Hospital
• Used LOINC v2.24 (original DocOnt terms)
• Of 86 the document types for 1.2 million
documents:
– 44% mapped to LOINC
– 44% had available mapping deemed not specific
enough
– 12% had no LOINC match
• A LOINC code existed for 93.1% of
documents in their set (by volume)
Dugas M, Thun S, Frankewitsch T, Heitmann KU. LOINC codes for hospital information systems documents: a case study. J Am Med Inform Assoc. 2009
May-Jun;16(3):400-3.
23. Ongoing Development
• A work-in-progress
• LOINC Users’ Guide is the definitive
source for current policy
– Always available at http://loinc.org
• Collaboration/discussion
– Clinical LOINC meetings, HL7 SDTC
– LOINC website
– LOINC Users’ Forum: http:/forum.loinc.org
26. Future Directions
• Continued harmonization of v1 and v2
axis values
• Axis definitions
• Extension/refinement to other Kind of
Documents
• Empiric analysis of document contents
Editor's Notes
CDA Criteria: wholeness, stewardship, authentication, persistence, and human readability.