rapid core data element development in loinc · server (solor) domain analysis create logical...

RAPID Core Data Element Development in LOINC

Susan Matney, PhD, RNC-OB, FAAN

Stan Huff, MD, FHL7, FACMI

Why standard models and codes?

• So that there is a standard, computable, and publicly known meaning for the data elements

• We can use the same models and definitions for sharing data with:• MDEpiNet RAPID (and other MDEpiNet projects)

• Direct patient care

• Quality and disease specific registries

• Research

• Patient data to CMS

• Public health reporting, including to CDC

• FDA for device and product approval

Graphic of a Detailed Clinical Model

data 138 mmHg

SystolicBPSystolicBPObs

quals

data Right Arm

BodyLocationBodyLocation

data Sitting

PatientPositionPatientPositionSNOMED CT

LOINC or SNOMED Observable

3

The structure of the data plus the codes make the representation complete.

The Interoperability Development Process

Project Needs

• MDEpiNet RAPID• OPA Data Collection• Skin and Wound Assessment• Neonatal Bilirubin• PCORI• ACC registries

TerminologyServer

(SOLOR)

Domain Analysis

Create Logical Models (CIMI)

Approve Models

Model Repository

Create Physical

Artifacts (FHIR

Profiles)

Artifact

Repository(FHIR Profiles)

Create Software

(Apps, Services, CDS)

Conformance Testing

Information Requirements

Inception to Model

Domain Analysis Model

Model Request Spreadsheet

Design Patterns

SNOMED CT Concept Model

ISO 13606

openEHR

Clinical Quality Information

CIMI Requirements Specification Design

Information model

Constraint templates

Terminology

Current Status (from Susan Matney)

• Working as time and resources permit

• 67 data elements in a model request spreadsheet

• 4/67 (6%) match of RAPID data elements to LOINC

• Some of the modeling issues:• Modified Rutherford, Wound Grade (Wlfl) and Infection Grade (Wlfl) scales

not in LOINC (submitted)

• Devices listed as data elements (Cryo-Balloon, Scoring Balloon, Drug-Coated Balloon) which are values

• Yes/No questions for Assertions and Procedures (Graft, Lower Extremity Bypass, Hematoma, Hemorrhage)

Data Entry Styles

Device Use

Cryo-Balloon

Scoring Balloon

Drug-Coated Ballon

Yes No Unk

Device Used

Cryo-Balloon

Scoring Balloon

Cryo-Balloon (repeating field)

(handles pertinent

negatives)

Clinical Information Interoperability Council

1St Meeting July 13, 2017NIH Clinical Center, Masur Auditorium,

Bethesda Maryland

Goals for the meeting

• Develop a common understanding of problems to be addressed

• Make a plan for defining common data elements that can be shared and used across all of healthcare

• Obtain commitments across stakeholders to collaborate to share resources to reduce duplication of efforts and adopt common data elements

• Agree on a process for prioritizing the work

• Determine how we delegate responsibility for subject domains to specific organizations or groups

• Agree on a process for governing the work and making decisions

• Develop a plan for moving forward

Discussion

Process• Domain Experts Submit Use Case

• Use Case Reviewed by CIMI – CIMI agrees

• Domain Analysis Model

• DAM used to populate CIMI model template spreadsheet

• Review the Questions and Answers in the Spreadsheet

• Align Questions with CIMI Patterns• Wound = assertion• Wound measurements = EvaluationResults

• Use high level BMM patterns to model Detailed Clinical Models (DCMs)

• Encode with Standard Terminologies (LOINC, SNOMED CT, RxNorm, …)

• Create the DCMs

• Transform to other structures (e.g. FHIR profiles)

Wound DAM (Skin Risk Assessment)class Wound

Exudate

Dressing

«enumeration»

PeriwoundCondition

Tunnel

- direction: int- length: PQ

Undermining

- depth: PQ- direction: int- length: PQ

Wound

- bedAppearance: WoundBedAppearance- closureType: WoundClosureType- depth: PQ- edgeAppearance: WoundEdgeAppearance- length: PQ- periwoundCondition: PeriwoundCondition- type: WoundKind- width: PQ- Wound Number: PQ

«enumeration»WoundBedAppearance

«enumeration»WoundClosureType«enumeration»

WoundEdgeAppearance«enumerati...

WoundKind

Pressure Ulcer

«enumerati...ExudateQuantity

«enumeration»ExudateAppearance«enumerati...

ExudateColor

«enumerati...DressingPosition«enumerati...

DressingKindhasUndermining

hasDressinghasTunneling

exudes

Assertion

• Key = a code meaning “assertion”

• Code (was name) = a code representing what’s being asserted (“rash”, “auto accident”, “hypertrophy”, etc.)• Concepts from SNOMED CT

“Clinical Finding” hierarchy

• Finding site for the assertion (“nose”, “elbow”)• Concepts from SNOMED CT

“Body Location” hierarchy

Assertion Example

Finding Site Assertion String Syntax

The patient has a diabetic ulcer on the

right foot

WoundAssertion

key: WoundAssertion

Code: Diabetic foot ulcer (disorder)

bodylocation: Foot structure (body structure)

body side: Right (qualifier value)

Context: Confirmed present (qualifier value)

Evaluation Result

Key = a code meaning “Evaluation Result”

Code = the item being observed Concepts from SNOMED CT

“Observable Entity” hierarchy OR LOINC

Result = the result of the observation

EvaluationResult Examples

Physical Evaluation String Syntax

The patient’s skin turgor is

friable

SkinTurgorEval

key: EvaluationResult

Code: Skin turgor (observable entity)

result: Fragile skin (finding)

evaluationProcedure: Inspection (procedure)

Context: Confirmed present (qualifier value)

Wound Assertion Development Process

• High level pattern identified (if created)• Wound Assertion is a specialization

of Finding Site Assertion• Data Type and cardinality identified for

each data element• Terminology bindings created for data

elements and values in enumerated value sets

• Archetype Definition Language (ADL) created for each detailed clinical model

CIMI Model Data Elements

Element Display NameData

TypeCardinality Optionality

Assertion Wound Present Coded 0..1 Mandatory

PhysicalEval Wound Type Coded 0..1 Mandatory

Property Body Location Coded 0..* Conditional







Panel Grouping Wound Size 0..1Conditional

PhysicalEval Wound Width Eval PQ 0..1

PhysicalEval Wound Length Eval PQ 0..1

PhysicalEval Wound Depth Eval PQ 0..1







Panel Grouping Wound Size 0..1Conditional

PhysicalEval Wound Width Eval PQ 0..1

PhysicalEval Wound Length Eval PQ 0..1

PhysicalEval Wound Depth Eval PQ 0..1

PhysicalEval Periwound Condition Eval Coded 0..* Conditional

Encoding The DCM

22

Type Text Terminology Code FSN

Finding Wound Present SNOMED CT 416462003 Wound (disorder)

Observation Wound Type LOINC 72300-7 Skin Alteration:Type:PT:Skin:Nom:::

Value Diabetic Foot Ulcer SNOMED CT 371087003 Diabetic foot ulcer (disorder)

Encoding The Patient Story

23





Observation Body Location LOINC 39112-8Body location

qualifier:Find:PT:^Patient:Nom::

Value Foot SNOMED CT 56459004 Foot structure (body structure)

Encoding The Patient Story

24





Observation Body Location LOINC 39112-8Body location

qualifier:Find:PT:^Patient:Nom::

Value Foot SNOMED CT 56459004 Foot structure (body structure)

Panel/Grouping Wound Size LOINC 72287-6 Wound Size Panel::PT:Wound::

Question 1 Wound Width LOINC 39125-0 Width:Len:PT:Wound:Qn::

Value 3 centimeters SNOMED CT 258672001 centimeter (qualifier value))

Question 2 Wound Length LOINC 39126-8 Length:Len:PT:Wound:Qn::

Question 3 Wound Depth LOINC 39127-6 Depth:Len:PT:Wound:Qn::

LOINC Wound Assessment Panel

Conclusion

• Identify Requirements and Use Case

• Develop the DAM

• Complete the DCM Template

• Determine Model Patterns

• Bind to the Appropriate Standard Terminologies

• Create the Detailed Clinical Models (DCMs)

• Transform to FHIR

rapid core data element development in loinc · server (solor) domain analysis create logical...

Documents