1. Clinical LOINC Tutorial
LOINC®
Panels, Forms, and Patient Assessment Instruments
08.13.2009
Daniel J. Vreeman, PT, DPT, MSc
Assistant Research Professor | Indiana University School of Medicine
Research Scientist | Regenstrief Institute, Inc
Copyright © 2009

2. Overview
• Background
• Standard Panels in LOINC
• Enhanced Panel Model for Patient
Assessment Instruments
• Current Projects
• Challenges Along the Way

3. Brief Timeline
• 2000 – First panels in LOINC
• 2000 – Original Model Extension for Standardized Assessment
Measures (Braden, etc)
– Bakken, S, Cimino, JJ, Haskell, R, Kukafka, R, Matsumoto, C, Chan, GK, and Huff, SM (2000).
Evaluation of the clinical LOINC (Logical Observation Identifiers, Names, and Codes) semantic structure as a terminology model for standard
J Am Med Inform Assoc 7(6):529-38.
• 2000 – Initial surveys stored in LOINC (HIV, HHC, etc)
• 2002 – Proposed extension for Assessment Instruments
– White, TM and Hauan, MJ (2002). Extending the LOINC conceptual schema to support standardized assessment instruments. J Am Med
Inform Assoc 9(6):586-99.
• 2005 – Dissection of OASIS in LOINC
– Choi, J, Jenkins, ML, Cimino, JJ, White, TM, and Bakken, S (2005).
Toward semantic interoperability in home health care: formally representing OASIS items for integration into a concept-oriented terminolo
J Am Med Inform Assoc 12(4):410-7.
• 2006 – Initial work with MDS/OASIS (LOINC v2.17)
• 2006 – More discussions about data model, APSE/CHI interest
• 2006 – CHI/NCVHS Endorsement of LOINC as standard for
federally-required assessment instruments (quest/ans)

4. Standard Panels in
LOINC

5. Panels (Batteries) in LOINC
• Panel term linked to enumerated child elements
– Child elements can be panels themselves (nesting)
• Panel term names (under discussion)
– Component often have “panel”, include authoritative source
– Property typically “-” because child elements will vary
– Scale typically “-” because child elements will vary
– Class PANEL.*
• Child elements linked and identified as:
– Required (R) Element always reported with panel
– Optional (O) Element may not be reported depending on
institutional policies or capabilities
– Conditional (C) Element is a key finding and thus should be
assumed to be negative, absent, or not present if
panel result does not include data for this element.

6. Example Panel

7. Example Panel with Nesting

8. Clinical Panels

9. Patient Assessment
Instruments
Iterative Enhancement of the Panel Model

10. Introduction
• Initial modeling (circa 2000) required modest
extensions to the LOINC axes
– E.g. for System to include aggregate units like “family”, and Method
to distinguish among reported and observed findings
• Survey instruments have psychometric properties
• Question meaning tightly coupled with answers
• With experience in modeling instruments from
various domains, we uncovered additional
relevant attributes to store
General Aim: LOINC could serve as the
“master question file” in this domain

11. What’s in the Master Question File?
• Question (item) name/text
– Exact question text, form-specific display name
• Data type
• Description and/or help text
• For numeric values: units of measure, range checks
• For categorical results: answers in an answer list
• Required item (Y/N)
• Cardinality (more than one answer allowed)
• Copyright and terms-of-use notices
• Skip logic
• Consistency/data integrity logic
• … and more

16. Advantages of the Master Catalog
• Single database (LOINC) contains the details about
individual observations and sets
– In the database, all forms (sets) look the same
– Automatic standardization
• Separates the form structure, question details, the
rendered version (paper or screen), and the
program that manages it
• Can easily reuse observations (and attributes) in
different forms/sets

18. Panels/Forms Available as
Separate Download
http://loinc.org/downloads

19. Rules for Display of Items
1. SURVEY_QUEST_TEXT (if populated). Used when item is asked as a
question. Sometimes the item has a label and a question, so we
store both as [label].[question text]
Pain Presence. Ask resident: “Have you had pain or hurting at
any time in the last 7 days?”
2. DISPLAY_NAME_FOR_FORM (if populated). Provides an override
display linked to the instance of the LOINC in a particular form.
Allows for presentation variation that doesn’t affect meaning and
for where the LOINC naming conventions require some difference
b/w the item and the LOINC Component.
Item label = “Body Mass Index (BMI)”
LOINC Component = “Body mass index”
3. COMPONENT. This is the default display

20. Rules for Display of Items
• LOINC is developing/evolving other display
names
– Short Name
– Long Common Name
– Consumer Name
• May be useful in some contexts, but our
current practice is to capture the exact form
display with previous rules
• Some of the original surveys in LOINC may
not yet follow the model

21. Structured Answer Lists
• Many items in surveys have highly specialized, fixed
answer lists
– Often the answer lists define the meaning of the question
– Few are represented by existing codes in reference terminologies
• LOINC has created answer codes where needed
– Have “LA” prefix and a mod-10 check digit
– Are unique by lexical string (ignoring capitalization)
– Intentionally do NOT distinguish based on context-specific meaning
• In some cases, the answer list is identified with a
Regenstrief-assigned OID (for HL7 CDA use)
• Answer list shows sequence, but not bound by it
• Store local codes for items and have place to store
universal code (e.g. SNOMED) – not yet populated

22. Current Projects and
Directions

23. ASPE as Key Supporter
• ASPE (Jennie Harvell) has championed use
of HIT standards for assessment
instruments in many venues
• Initial Reports
– Making the "Minimum Data Set" Compliant with Health Information Tech
– Standardizing the MDS with LOINC® and Vocabulary Matches

24. Consolidated Health Informatics Initiative
• CHI Goal:
– Adopts a portfolio of existing health information
interoperability standards (health vocabulary and
messaging) enabling all agencies in the federal
health enterprise to “speak the same language”
• In 2006, adopted LOINC as standard:
– Laboratory test order names
– Medications: Structured Product Labeling Sections

25. Consolidated Health Informatics Initiative
• In 2007, CHI adopted LOINC as standard
for federally-required assessments:
– questions and answers
– assessment forms that include functioning
and disability content
• Jennie Harvell (ASPE) Co-chaired

26. Currently in LOINC
• US Government Forms
– CARE, MDSv2, MDSv3, OASIS, RFC
– US Surgeon General’s Family Health Portrait
• Geriatric Depression Scale
• HIV Signs and Symptoms Checklist
• Home Health Care Classification
• howRU
• OMAHA
• PHQ (9 and 2)

27. Find them in RELMA

28. Current RI/LOINC Efforts
• ASPE-funded effort to create LOINC®
representation of new instrument versions
– MDSv3 (done)
– OASIS-C (this fall)
• CMS-funded effort to create LOINC®
representation of new CARE instrument
– Make recommendations on legacy instruments
– Interoperability recommendations

29. HL7 CDA Implementation Guide

30. Many Other Potential Opportunities
• Mental health instruments
• Lots of other commonly-used
instruments (SF-36, etc)
• AHRQ Common Framework forms
• CDC case report forms
• PhenX protocols for clinical research
trials

31. Challenges
Corralling the Creativity

32. Intellectual Property Issues
• Must negotiate separate agreements with each
copyright/IP holder
• Many instruments are fiercely protected
– Protection against change and attribution are
understandable
– Some want royalties
– Commercial use in LOINC’s context is tricky
• Even more complicated when several
instruments included in larger CMS ones (MDS,
CARE, etc)

33. Modeling
• Despite many instruments now in LOINC,
reuse of items has been minimal
– E.g. extremely few of same items b/w MDSv2
and MDSv3
– MDSv3 has greater similarity to CARE, but the
lookback period is different (7D vs 2D)
• Lament the seemingly trivial differences
between the CMS-required instruments

34. Original PHQ-9
CARE
MDSv3

35. MDSv2
MDSv3
OASIS
CARE

36. Incongruity with HL7 Information Model
• Items for things that could go in PID, etc
• Flat data model vs stacked
– Every ‘Check all that apply’ stored as separate yes/no item
• “Unknown” or “unable to determine” as answer
choices vs flavors of null
• In general, CMS has not been thinking in terms of
interoperable data exchange
– Resistant to getting involved in SDO processes like
balloting

37. Many Yes/No Diseases

38. Always New Challenges
• How to label/store definitional text vs text
giving examples
– Rashes – e.g. intertrigo, eczema, drug rash, heat rash…
• Answer list sequences
– Same answers across instruments but different order
• Skip logic shown at level of answer
– Current strategy is to aggregate up to question level