improving healthcare data interoperability · • pcornet cdm leverages standard terminologies and...

The image part with relationship ID rId11 was not found in the file.

Improving Healthcare Data Interoperability

Welcome

Anqi LuThe Pew Charitable Trusts

Grant support provided by The Pew Charitable Trusts



Problem Statement & Meeting Objectives

James E. Tcheng, MDDuke Clinical Research Institute


@PaulLomax: The most unbelievable aspect of the Star Trek universe is that every ship they meet has compatible video conferencing facilities …

It Isn’t for a Lack of Trying …• 1899 – International Statistical Institute adopted

Bertillon Classification of Causes of Death (predecessor to ICD)

• 1965 – Systematized Nomenclature of Pathology published by CAP (predecessor to SNOMED)

• 1966 – AMA published 1st edition of CPT codes• 1987 – HL7 launched (Ed Hammond)• 1994 – LOINC initiated by Clem McDonald• 2011 – FHIR introduced by Grahame Grieve

Audience Response 1How many biomedical ontologies have been developed (e.g., CPT, RxNorm, SNOMED-CT, LOINC, …)?

1. ~1002. ~2503. ~5004. ~7505. >1000

Audience Response 2How many terms have been developed / modeled as CDEs in biomedical taxonomies (ontologies)?

1. ~1 million2. ~5 million3. ~10 million4. ~20 million5. ~40 million

http://bioportal.bioontology.org

http://bioportal.bioontology.org/

The Playbook - Content- General (core) CDEs- Domain-specific CDEs- UDI: GUDID, AUDI- Outcomes: AHRQ

- Data models- Patient ID, matching- Data aggregation- Distributed analysis

Professional Societies- Registries- Domain-specific CDEs- Structured data capture

DCRI / Academia- Need for CDEs- Academic publishing

NEST / NESTcc- Coordination of

medical devices

EHI Vendors- EHR, other HIT systems- Structured reporting

ONC- Common Clinical Dataset - USCDI- Interoperability Standards AdvisoryFDA

- MDEpiNet, CRNs, Women’s Health

- Regulatory use cases- Global coordination- Demonstration via

projectsHL7-CIC, CIIC, CIMI …- The Playbook: Process

for CDE modeling- Tooling, repository of

logical CDE models- Registry domain analysis

modeling

NQRN Registries on FHIR- Environmental scan- ID / spec of general (core) CDEs- Demonstration / implementation

NIH / NLM …- VSAC repository- CDE repository

Some problems are so complex that you have to be highly intelligent and well

informed just to be undecided about them.

Laurence J. Peter

Problem Statement

• Interoperability of what? • What will it take to make interoperability

a reality?• What can the registry community do to

accelerate interoperability?

au·dac·i·ty1. The willingness to take bold risks.

“her audacity came in handy during our most recent emergency”synonyms: boldness, daring, fearlessness, intrepidity, bravery,courage, heroism, pluck, grit

2. Rude or disrespectful behavior; impudence."she had the audacity to pick up the receiver and ask me to hang up“synonyms: impudence, impertinence, insolence, presumption, cheek, bad manners, effrontery, nerve, gall, defiance, temerity

Google Dictionary

Meeting Objectives• Develop a deep understanding of the project• Review work accomplished to date• Contribute to discussions about adoption

strategies• Understand your role in next steps (review /

critique of the core CDE set)• Position you to advocate for adoption of the

core CDEs in your registry



Design & Goals of the Project

Rebecca WilgusDuke Clinical Research Institute


Goals Describe current state of registries How well are data standards used across

common concepts? Describe ongoing interoperability initiatives &

content of national data models Environmental scan

Create an implementation guide All-in-one package of recommendations for db

developers


Aims• Aim 1: Case Report Form review

– >20 different disease and device registries of professional societies – Abstract minimum of 20 (max 100) ubiquitous clinical data elements (>50% prevalence

across Registry CRFs)

• Aim 2: National Data Standards, Data Models review – The “Big 5” terminologies (SNOMED, LOINC, RxNorm, ICD, CPT)– ONC Common Clinical Dataset / USCDI– OMOP / OHDSI, SENTINEL, PCORNet– HL7 / HL7 FHIR

• Aim 3: Best Practice recommendations – Analysis and cataloguing of previous work– Recommendations (NOT an nth data standard!)

Inputs to a roadmap that catalyzes the governance structural, operational, and technical transformations needed to implement a common clinical data element set across EHI and registry systems, and national data models.


Participating RegistriesAmerican Academy of OphthalmologyAmerican College of Cardiology NCDRAmerican College of GastroenterologyAmerican College of Obstetricians and GynecologistsAmerican College of RadiologyAmerican Optometric AssociationAmerican Orthopedic AssociationAmerican Physical Therapy Association American Podiatric Medical Association American Society for Clinical PathologyAmerican Society for Radiation OncologyAmerican Society of AnesthesiologistsAmerican Society of EchocardiographyAmerican Society of Nuclear CardiologyAmerican Urogynecologic SocietyAmerican Urological AssociationAmericas Hernia SocietyArthritis Research Center Foundation

Creaky Joints Patient Powered Research Network Cystic Fibrosis FoundationMichigan Surgical Quality Collaborative National Osteoporosis FoundationNeuropointNorth American Association of Central Cancer RegistriesOutpatient Endovascular and Interventional SocietyPlastic Surgery Registries Network (GRAFTS, TOPS)Renal Physicians AssociationSociety for Vascular SurgerySociety of Interventional RadiologySociety of Thoracic SurgeonsUniversity of Massachusetts Medical School: Function & Outcomes Research for Comparative Effectiveness in Total Joint Replacement United Network for Organ Sharing VANGUARDVermont Oxford NetworkWomen's Health Initiative


Deliverables1) Recommendations Specifications data base developers need to

support the consistent, interoperable collection of these data elements

2) Environmental scan Who’s doing related work Why are they doing it (use cases) Relationship to other initiatives


Concepts of Interest• Patient ID• Sex (birth sex)• Date of birth• Race• Ethnicity• Diagnosis• Smoking status – EtOH –

illicit substances • Risk Factors/Medical

History

• Laboratory results• Vital signs• Medications• Care team members –

attending physician/physician operator

• Procedures• Unique Device Identifiers• Mortality/Death


Key CDE Metadata

HCV status:

Question or promptMay have associated controlled

terminology

Value, result or answerMay have associated controlled

terminology

1. Clinical concept label (e.g., human prompt for CRF, data entry screen)2. Db field label (all caps, no spaces, underscores only, limited chars …)3. Clinical definition of the concept, synonyms thereof4. Data type / format (e.g., free text, constrained list, integer, …)5. Allowed values (aka permissible values = value set; VSAC?)6. Allowed values definitions7. Business rules (e.g., range / edit checks, consistency, validation)8. SDO binding(s)9. Published reference(s)


Coming soon…


Questions?

Email:[email protected]

Visit the project website: https://dcri.org/registry-data-standards/

mailto:[email protected]

https://urldefense.proofpoint.com/v2/url?u=https-3A__dcri.org_registry-2Ddata-2Dstandards_&d=DwMFAg&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=vfHzFRt5yHPflvG_NXrMI6QNXVmJ2RKZpUunntz-wuE&m=ysaEN7mJkKCYeT0t8Y0fW8nFrnH3Fh7ntNXeoVPkhCk&s=rj_Pm4baIFiuz_wPJQg3KUnaMgZW_lWeqXh58pXWHj8&e=


Common Clinical Concepts as DataEnvironmental Scan & Gap Analysis

Julia Skapik, MD, MPHCHIO

Cognitive Medical Systems


What is a Common Data Element?

Data Element (DE) - Information that describes a piece of data to be collected. The DE does not include the data themselves.

– According to ISO/IEC 11179 terminology, a Data Element is the fundamental unit of data that an organization disseminates.

– Attributes of DEs often include: name, definition, modifiers or restrictions, value set, and context

Common Data Element (CDE) – A clearly defined data element that is common to multiple data sets across different use cases.

– Can be required for some use cases including programs, standards, and reporting purposes.

22

“Common” Does Not Mean “Similar” Anyone can create “common” data elements– but what

makes CDEs common is that they are SHARED

Otherwise – semantic interoperability cannot be guaranteedThat means not just a name, but:• Format/standard• Terminology bindings• Optionality vs required elements• And USE! (i.e. someone other than you)

Right now the government has created several large scale efforts that created “common data elements” which are not common across use cases and were not designed to be applied to direct patient care. The use of overlapping “CDEs” is a major source of burden to systems and users.

23

CQM DATA

ELEMENT

EHR1 DATA

ELEMENT

CLINICAL RESEARCH

DATA ELEMENT

REGISTRYDATA

ELEMENT

EHR2 DATA

ELEMENT

AGENCY DATA

ELEMENT

CDS DATA ELEMENT

24

Current State: An Interoperability Nightmare

An Incomplete List of CDE Locations/Sets25

Some Current Definitions:• Meaningful Use Common Clinical Data Set

(CCDS)/US Core Data for Interoperability (USCDI)• Patient Centered Outcomes Research (PCORNet) • CaDSR/NCI Repository --> see NLM CDE Repo• FHIR (Core, US Core, Other)• CIMI Model Repository• PCOR Clinical Decision Support (CDS) under

AHRQ• CMS/NLM eCQM Data Element Catalog• CMS Data Element Library• NLM Common Data Element Repository

CCDS/USCDI• Started as the Meaningful Use Objectives Common

Clinical Dataset required for exchange at transitions of care– was updated at each version of ONC Certification rule, most recent 2015

• USCDI creates a framework for annual updates to expand the data classes, presumably these will also be available for certification in the future

• Data classes is ambiguous, and in reality the USCDI is a combination of data elements and data class requirements

• Much of the content is not granular enough to ensure interoperability of content (often no ranges, units, value sets, metadata definitions)

CCDS/USCDIPatient name Lab tests

Sex Lab values/results

Date of birth Vital signs (structured)

Race Procedures

Ethnicity Care team members

Preferred language Immunizations

Problems Unique device identifiers for implantable devices

Smoking Status Assessment and plan of treatment

Medications Goals

Medication allergies Health concerns

CCDS/USCDI

PCORNet• Built on the PCORNet Common Data Model, based

on the FDA Sentinel Initiative Common Data Model (www.sentinelsystem.org)

• PCORnet CDM leverages standard terminologies and coding systems for healthcare (including ICD, SNOMED, CPT, HCPSC, and LOINC)

• Output includes pdf and excel files• Research-focused use case• The PCORnet Distributed Research Network

utilizes the PopMedNet platform, a software application enabling simple creation, operation, and governance of distributed health data network

http://www.sentinelsystem.org/

http://www.popmednet.org/

PCORNet

FHIR Data Element Resourcehttps://www.hl7.org/fhir/dataelement.html

31

FHIR: Core, US Core, and Extensions

• FHIR is NOT a content standard– thus, there is no “FHIR CDE Repository” and most of the resources exist at the class level

• FHIR provides a physical representation for content– it does not have an underlying logical model

• FHIR Core includes standardized, required supported content although great optionality exists in the inclusion of metadata

• FHIR US Core aligns to the MU CCDS/USCDI (largely classes)

• Extensions in FHIR are not cross-tested for conformance– There is no governance process outside of the ballot

process

Graphic of a CIMI Detailed Clinical Model

data 138 mmHg

SystolicBPSystolicBPObs

quals

data Right Arm

BodyLocationBodyLocation

data Sitting

PatientPositionPatientPosition SNOMED CT

LOINC

33

• Definition: The Clinical Information Modeling Initiative (CIMI) is an international collaboration dedicated to providing a common format for detailed specifications for the representation of health information content.

• How is the CIMI model singularly appropriate for CDEs that are designed both for point of care applications and reuse?

1. Serves as a repository of detailed clinical models to which other models can be mapped and harmonized.

2. The DCM logical model can be transformed to isomorphic technical implementations including CDA, FHIR, Forms, HL7 V2, NCPDP, etc., including context.

3. Established industry support and process for inclusion.4. Can be a central point for introducing new/revised data elements in

context of the model.

Clinical Information Modeling Initiative (CIMI)

CMS Data Element Library• Contains Long Term and Post-Acute Care (LTPAC)

data elements from mandatory CMS program reporting assessments including:– MDS 3.0– RDF-PAI – OASIS– LCDS – HIS

• Includes codes in standard terminologies and structured metadata

• Not a standards-based form and manner• No API

CMS Data Element Library

CMS eCQM Data Element Catalog• Published annually with the CMS eCQMs• Contain Quality Data Model datatype, attributes, and

value sets associated with each published measure• Widely implemented in the field due to their long-

standing availability and requirement for ONC Certification to the measure data elements

• Do not contain additional metadata • Have formal QA process, and have been partially

harmonized through public feedback• Not a formal set of CDEs created through a

governance process, but instead largely defined by measure developers

CMS eCQM Data Element Catalog

NLM Common Data Element Repository

41

Research CDEs

eCQMs

EHR Based CDEs

True CDEs: Like Registries, Can Unify Multiples Use Cases

Registries/CDEs

Agency/ Org CDEs

• Start by defining the scope and any standards and workflow requirements

• Next collect and collate all the existing CDE formats and definitions

• Have SME QA team perform an evaluation of overlap/misalignment and identify high quality content as a starting point

• Have clinician and technical expert team define work and dataflow, review and build out additional content, and adjudicate misalignments

• Have QA team review content and provide feedback• Distribute for public review and feedback; revise as

appropriate• Repeat QA• Have technical team code final contentmove to test

implementation and formal release

42

Harmonizing Data Elements for Point of Care Use and Reuse

Closing the Interoperability Loop• The use of CDEs would over time cover all the necessary

clinical and patient-related concepts needed for clinical care• Removes the burden of creating and maintaining content

from the federal government• Allows organizations to perform a single mapping to the CDE

or “exchange” dataset• Allows developers to create applications and systems without

having to understand how to code their own clinical content because they can just reference CDEs

• Would allow systems to automatically display definition and use requirements to users at the point of data entry

43

Future Vision: Seamless, Semantic Interoperability

COMMON DATA

ELEMENTS

AGENCY

CDS

CQM

EHR2

EHR1

REGISTRY

CLINICAL RESEARCH

44

Questions?






BREAKGrant support provided by The Pew Charitable Trusts


Data Element Abstraction Process & Findings

Anne HeathDuke Clinical Research Institute


Registry Source Counts• The concordance tables presented today represent the data

collection methods in all 38 registry sources received and concentrate on the following concepts of interest:

– Race– Ethnicity– Date of Birth– Blood Pressure (Systolic and Diastolic considered separately)– Pulse– Height– Weight– UDI

RaceData Element Name

(CRF Label) Permissible Values Concordance

If Two or More Races, specify mixed race components

WhiteBlack of African AmericanAmerican Indian or Alaska NativeAsianNative Hawaiian or Other Pacific Islander 1

Patient Race

American Indian (Native American) or Alaska NativeAsianBlack or African AmericanNative Hawaiian or Other Pacific Islander WhitePatient declined to provideUnknownOther 2

Patient Race

American Indian/Alaska NativeAsianBlack/African AmericanNative Hawaiian/Pacific IslanderWhite 3

Race

American Indian or Alaska Native Asian Black or African AmericanNative Hawaiian or Other Pacific Islander WhiteMultiple RaceRefuse to answer 1

Race

American Indian or Alaska NativeAsianBlack or African AmericanNative Hawaiian or Other Pacific IslanderWhite 4

Race

WhiteBlack of African AmericanAmerican Indian or Alaska NativeAsianNative Hawaiian or Other Pacific IslanderSome other raceTwo or more races 1

RaceCont.

Data Element Name(CRF Label) Permissible Values Concordance

Race

Native Hawaiian or Other Pacific Islander American Indian or Alaska Native AsianBlack or African AmericanWhiteOther Race 1

Race

WhiteBlack/African AmericanAmerican Indian/Alaskan NativeAsian - IndianChineseFilipinoJapaneseKoreanVietnameseOther AsianNative HawaiianGuamanian or ChamorroSomoanOther Pacific Islander 1

Race

American Indian or Alaska NativeAsianBlack or African-AmericanWhiteNative Hawaiian or Other Pacific Islander OtherNot Disclosed 1

Race

White; Black/African American; American Indian/Alaskan Native; Asian - Indian; Chinese; Filipino; Japanese; Korean; Vietnamese; Other Asian; Native Hawaiian; Guamanian or Chamorro; Somoan; Other Pacific Islander 1

RaceWhite; Black/African American; Am Indian/Alaskan; Hawaiian/Pacific Islander; Asian; Other 1

Race/Ethnicity

American Indian or Alaska Native; Asian, Native Hawaiian or Other Pacific Islander; Black or African American; Hispanic; White, not of Hispanic origin 1

Race/Ethnicity (maternal)

White, Black or AA, American Indian or Native American, Asian Indian, Chinese, Filipino, Japanese, Korean, Vietnamese, Native Hawaiian, Guamanian or Chamorro, Samoan, Other pacific islander, Other (free text), Other Asian (specify) 1

Ethnicity Data Element Name(CRF Label) Permissible Values Concordance

EthnicityHispanic or LatinoNon Hispanic or Latino 6

Ethnicity

Hispanic of LatinoNot Hispanic or Latino Not Disclosed 1

Patient Ethnicity

Hispanic or LatinoNot Hispanic or Latino Patient declined to provideUnknown 1

Ethnicity Type

MexicanMexican-Americano ChicanoPuerto RicanCubanOther HispanicLatino or Spanish Origin 2

Hispanic

NoUnknownYes 1

Hispanic or Latino Ethnicity

NoYes 2

Hispanic Origin (maternal)

Mexican AmericanChicanoPuerto RicanCubanOtherSpanish/Hispanic/Latino Hispanic, NOS 1

Is Patient of Hispanic Origin?

YesNoUnknown 1

Hispanic, Latino or Spanish Ethnicity

Yes NoNot Documented 1

Date of BirthData Element Name

(CRF Label) Permissible Values ConcordanceBirth date MM/DD/YYYY 4Date of Birth DD-MMM-YYYY 5Patient Date of Birth mm/dd/yyyy 1

Patient's Date of Birthyyyy-mm-dd or mm/dd/yyyy 1

Patient Birthdate MM/DD/YYYY 1Date of Birth mm/dd/yyyy 2

Systolic BPData Element Name


Maternal Blood Pressure (systolic) [not specified] 1Resting BP Systolic Numeric (3) 1Systolic BP [not specified] 2

Diastolic BPData Element Name


Maternal Blood Pressure (diastolic) [not specified] 1Resting BP Diastolic Numeric (3) 1Diastolic BP [not specified] 2

Pulse


Pulse Rate number, integer 1

Heart Rate number, integer 2

HeightData Element Name

(CRF Label) Permissible Values ConcordanceHeight (cm) Alphanumeric 1Height (cm) Decimal (5,2) 3Height (cm) [not specified] 6Patient Height (inches) numeric, integer 1

Weight


Patient Weight (pounds) numeric, integer 1Weight (kg) Alphanumeric 1Weight (kg) Decimal (5,2) 3Weight (kg) [not specified] 6Weight at delivery (kg) number, decimal 1Weight at pregnancy onset (kg) number, decimal 1

UDIData Element

Name(CRF Label) Permissible Values Concordance

UDIUnique device identifier (not serial number) 1

Questions?






National Data Models & FHIR Review

Mary WilliamsDuke Clinical Research Institute


Improving the Interoperability of Healthcare Data• Aim 2: To characterize the data elements in

the context of healthcare data standards and other predicate work

Common Healthcare Data Interoperability Project

Supported by funding from The Pew Charitable Trusts

National Models• ONC Common Clinical Data Set (CCDS)• Common Clinical Registry Framework (CCRF)

v1.3• FHIR – US Core and QI Core• Observational Health Data Sciences &

Informatics (OHDSI) v5.3.1• PCORNet Common Data Model v4.1• Sentinel v6.0.2

Concepts of Interest• Patient ID• Sex (birth sex) – shown during July 12th

• Date of birth• Race• Ethnicity• Diagnosis• Smoking status – EtOH – illicit substances – Shown during July 12th

• Risk Factors/Medical History• Laboratory results – Shown during July 12th

• Vital signs (height, weight, heart rate, systolic bp, diastolic bp)• Medications• Care team members – attending physician/physician operator• Procedures• UDI• Mortality/Death

National Model Data Element Abstraction

EHR System Registry Data Entry

PEW Concept of Interest

Examples: Date of Birth

Date of BirthData Element Name Permissible Values Concordance

Date of Birth N/A 2(CCDS, CCRF)

Derived (year_ / month_ / day_of_birth) YEAR_OF_BIRTH, MONTH_OF_BIRTH, DAY_OF_BIRTH

N/A 1(OHDSI)

Patient.birthDate N/A 1(FHIR)

BIRTH_DATE N/A 2(PCORnet, Sentinel)

FHIR Recommendation: Date of Birth

Examples: Race

FHIR Recommendation: Race

Examples: EthnicityETHNICITY

Data Element Name Permissible Values ConcordanceETHNICITY Hispanic or Latino

Not Hispanic or Latino2(CCDS, CCRF)

StructureDefinition-us-core-ethnicity Hispanic or LatinoNot Hispanic or Latino

1(FHIR)

ethnicity_concept_id 38003563 - Hispanic or Latino38003564 - Not Hispanic or Latino

1(OHDSI)

HISPANIC Y=YesN=NoR=Refuse to answerNI=No informationUN=UnknownOT=Other

1(PCORnet)

HISPANIC N = NoU = UnknownY = Yes

1(Sentinel)

FHIR Recommendation: Ethnicity

Examples: HeightHEIGHT

Data Element Name Permissible Values Concordance

Body height N/A 3(CCDS, CCRF, FHIR)

HT N/A 2(PCORnet, Sentinel)

FHIR Recommendation: Height

Examples: Weight

WEIGHT


Body weight N/A 3(CCDS, CCRF, FHIR)

WT N/A 2(PCORnet, Sentinel)

FHIR Recommendation: Weight

Examples: Heart Rate

HEART RATE


Heart Rate N/A 3(CCDS, CCRF, FHIR)

FHIR Recommendation: Heart Rate

Examples: Systolic Blood PressureSYSTOLIC BP


Systolic blood pressure N/A 3(CCDS, CCRF, FHIR)

SYSTOLIC N/A2(PCORnet, Sentinel)

FHIR Recommendation: Systolic Blood Pressure

Examples: Diastolic Blood PressureDIASTOLIC BP


Diastolic blood pressure N/A 3(CCDS, CCRF, FHIR)

DIASTOLIC N/A 2(PCORnet, Sentinel)

FHIR Recommendation: Diastolic Blood Pressure

Examples: Unique Device Identifier (UDI) for Implantable Medical Devices

DEVICESData Element Name Permissible

ValuesConcordance

Unique device identifier(s) for a patient’s implantable device(s)

N/A 2(CCDS, CCRF)

Device.identifier N/A 1(FHIR)

unique_device_id N/A 1(OHDSI)

FHIR Recommendation: Unique Device Identifier (UDI)

How this Works

Registry CRFs

PEW Registry Recommendations

National Models

Questions?






Candidate Common (Core) CDEsJames Tcheng, MD

Duke Clinical Research Institute


We Have Robust Evidence & Guidelines--Why Registries?

Evidence

ClinicalPractice

Guidelines

“Science tells us what we can do; Guidelines what we should do; Registries what we are actually

doing.”

Swivel Chair Interoperability Wes Rishel

Clinical Systems Registry Data Entry

HIT / EHR (POCForm)

DiscreteData

(CDEs)

Structured Documentation

DQR Credible

Data

Analysis, Measures

BenchmarkRegistries

Active Quality Improvement

Cycle

Duke Heart Center - Dataflow End State

Heart Data Mart

Research

Build infrastructure Use the data

Near Real Time Clean Up

ARRA HITECHHIT Standards CommitteeClinical Operations Workgroup Report

Jamie Ferguson, ChairKaiser Permanente

John Halamka, Co-chairHarvard Medical School (& HITSP)

20 August 2009

HIT Committee: Standards for Interoperability

• Clinical Operations is recommending standards for interoperability between entities, not within an entity

• Recommended standards should not apply to internal data capture, storage or uses – only to external representation and data exchange between entities

• Content should be able to be represented in the specified vocabularies and exchanged in the specified standards at the boundary between entities, regardless of how it is managed internally– Many methods may potentially be used to achieve interoperability

standards, e.g., mapping, external services, or native data capture

Exchange, Use, and Reuse of Data Requires Shared Data Definitions (including semantics)

Data standards are like toothbrushes:

Everybody agrees we need them, but nobody wants to use anyone else’s.

Various attributions

US Core Data for Interoperability (USCDI) https://www.healthit.gov/sites/default/files/draft-uscdi.pdf

USCDI – 22 Concepts• Patient name• Date of birth• Race• Smoking status• Lab values / results• Problems• Medication allergies• Care team members• Immunizations• UDI• Provenance

• Sex• Preferred language• Ethnicity• Laboratory tests• Vital signs• Medications• Health concerns• Assessment / plan of rx• Procedures• Goals• Clinical notes

USCDI – Relevant to Registries?• Patient name• Date of birth• Race• Smoking status• Lab values / results• Problems• Medication allergies• Care team members• Immunizations• UDI• Provenance

• Sex• Preferred language• Ethnicity• Laboratory tests• Vital signs• Medications• Health concerns• Assessment / plan of rx• Procedures• Goals• Clinical notes

Query: Candidate Common CDEs8 As Is• Patient name• Date of birth• Sex• Race• Ethnicity• Smoking status• Procedures• UDI

7 Adjusted• Vital signs: height,

weight, BP, pulse• Lab results (via model)• Medications (via model)• Care team: MD only• *EtOH use• *Substance abuse• *Vital status (death)

*not in USCDI

Key CDE Metadata

HCV status:

Question or promptMay have associated controlled

terminology

Value, result or answerMay have associated controlled

terminology

1. Clinical concept label (human prompt – CRF, data entry screen)2. Clinical definition3. Clinical allowed values (human prompt – CRF, data entry screen)4. Database field label5. Database field data type / format (e.g., char, date, float, integer, list)6. Database field business rules (edit checks, range checks, etc.)7. Database allowed values (as stored in db)8. Allowed values definitions9. Reference ontology concept 10. Reference ontology allowed value bindings11. FHIR – profile and resource12. Sources / references / notes

Example: Sex1. Clinical concept label: Sex [Birth Sex, Sex (Birth Sex)]2. Clinical definition: A person's biological sex, assigned at birth, not to be

confused with the social construct of gender.3. Clinical allowed values: F, M, UNK [Female, Male, Unknown]4. Database field label: SEX5. Database field data type / format: Value Set – Char(3)6. Database field business rules: 7. Database allowed values: F | M | UNK8. Allowed values definitions: Female, Male, Unknown - a proper value is

applicable, but not known. Includes ambiguous, variations of unknown, and variations of null.

9. Reference ontology concept: LOINC: LL3324-2, Sex assigned at birth 10. Reference ontology allowed value bindings: LOINC: LA3-6, LOINC: LA2-8,

LOINC: LA4489-611. FHIR Profile: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-

patient.html; FHIR Resource: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-birthsex.html; Value Set: https://www.hl7.org/fhir/us/core/ValueSet-us-core-birthsex.html

12. Sources / references / notes: USCDI

https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html

https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-birthsex.html

Example: Height

1. Clinical concept label: Body Height [Height, Body Length]2. Clinical definition: Distance from the bottom of the feet to the top of the

head, standing erect.3. Clinical allowed values: …4. Database field label: HEIGHT5. Database field data type / format: FLOAT6. Database field business rules: …7. Database allowed values: …8. Allowed values definitions: …9. Reference ontology concept: LOINC 8302-2, 10. Reference ontology allowed value bindings: …11. FHIR Profile: https://www.hl7.org/fhir/us/core/us-core-vitalsigns.html;

FHIR Resource: http://hl7.org/fhir/bodyheight.html12. Sources / references / notes: USCDI; also CDE for unit of measure

https://www.hl7.org/fhir/us/core/us-core-vitalsigns.html

http://hl7.org/fhir/bodyheight.html

Example: Smoking Status

1. Clinical concept label: Smoking Status [Smoker, Tobacco Use, Tobacco Smoker]

2. Clinical definition: The current smoking status of an individual. 3. Clinical allowed values: Current heavy tobacco smoker, current light tobacco

smoker, current some day smoker, former smoker, never smoker, smoker current status unknown, current every day smoker, unknown if ever smoked

4. Database field label: SMOKING_STATUS5. Database field data type / format: Value Set – Char(50)6. Database field business rules: 7. Database allowed values: [same as clinical allowed values]8. Allowed values definitions: [CDC definitions]9. Reference ontology concept: LOINC 72166-210. Reference ontology allowed value bindings: CDC PHIN VADS

428071000124103, …11. FHIR Profile: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-

smokingstatus.html; Value set: https://www.hl7.org/fhir/us/core/ValueSet-us-core-observation-ccdasmokingstatus.html

12. Sources / references / notes: USCDI

https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-smokingstatus.html

https://www.hl7.org/fhir/us/core/ValueSet-us-core-observation-ccdasmokingstatus.html

Query: Key CDE Metadata

HCV status:1. Clinical concept label Data element short name

Data element label1. Clinical definition Data element definition2. Clinical allowed values Value set3. Database field label Technical short name4. Database field type Data type5. Database field business rules Value parts6. Database allowed values …7. Allowed values definitions Definitions of the VS elements8. Reference ontology concept Code system9. Reference ontology bindings …10. FHIR – profile and resource …11. Sources / references / notes Reference source | Comment

Classification (context)

DCRI - Pew FDA CRNs

Questions?






Proposed Medication ModelTom Windle

University of Nebraska Medical Center


Introduction• Reviewed 36 registry data dictionaries for all

medication data• 28 (78%) had questions directly related to

medications• Variety of specific questions• Four categories of general medication

questions

Four Types of Medication Questions• Provide a list of medications (n=12)

– List all medications patient is currently taking.• Specific, domain-pertinent medications (n=12)

– Does the patient have a TOBI Podhaler?• Medications in a class of drugs (n=18)

– Is the patient on Anticoagulation drugs?• Medications administered related to a

procedure (n=8)– Indicate if patient was prescribed for Ciprofloxacin

(Cipro) antibiotic after biopsy.

Health Information Technology Standards Panel’s Medication Standards (Plus 3)


Name Definition Existing Sources

Fill Status This identifies whether the medication has been fulfilled, such as completed and aborted. HL7 v3

Indication The medical condition or problem intended to be addressed by the ordered medication. ICD-9; ICD-10; or SNOMED CT

Product Form The physical form of the product as presented to the individual. NCI

Dose The dose of the product prescribed by the individual NCI; LOINC; or HL7 v3

Route The method for the medication received by the individual NCI; or HL7 v3

Type This is a classification based on how the medication is marketed SNOMED CT

Site This is the anatomic site where the medication is administered. (Body Site)

Brand Name The product brand name of drugs RxNorm

Clinical Drug Name The product clinical name of drugs RxNorm; or LOINC

Drug Class The pharmacological drug class RxClass; or NDF-RT

Packaged Product The labeler, product, and trade package size NDC

Ingredient Name Drug ingredients UNII; or RxNorm

Vehicle Non-active ingredient(s), or substances not of therapeutic interest, in which the active ingredients are dispersed. SNOMED CT

Prescriber* Clinician that prescribed or administered a drug. NPI

Effective Date* Date of the earliest fill date. HL7 v3

Duration* Amount of time patient take prescription HL7 v3

Health Information Technology Standards Panel’s Medication Standards (Plus 3)


Name Count Interoperable Count

Fill Status 2 1

Indication 3 2

Product Form 2 1

Dose 12 2

Route 6 3Type 0 0

Site 0 0

Brand Name 0 0Clinical Drug Name 21 9

Drug Class 18 0

Packaged Product 1 1

Ingredient Name 0 0

Vehicle 0 0

Prescriber* 1 1Effective Date* 10 10

Duration* 5 1

Conclusion• Medication data is necessary for registries to

become interoperable• There is a lack of adherence to established

standards– Or; a lack of communication of the utilization of

these standards

• Communicate the standards utilized in data dictionaries

Questions?






Networking LunchGrant support provided by The Pew Charitable Trusts

Workgroup Room Assignments

• Workgroup 1: Return on Investment– Third Floor, Hawaii

• Workgroup 2: Communications– Second Floor, European Union

• Workgroup 3: Technical Challenges– Second Floor, Americas (stay in this room)

• Workgroup 4: Adoption Strategies/Policy– Third Floor, Oklahoma

If the workgroup you would like to attend has no more available seats, please select a different group.


BREAKGrant support provided by The Pew Charitable Trusts


Workgroup Report Outs & Discussion



Wrap-up & Next StepsJames Tcheng, MD

Duke Clinical Research Institute


The Playbook - Content- General (core) CDEs- Domain-specific CDEs- UDI: GUDID, AUDI- Outcomes: AHRQ

- Data models- Patient ID, matching- Data aggregation- Distributed analysis

Professional Societies- Registries- Domain-specific CDEs- Structured data capture

DCRI / Academia- Need for CDEs- Academic publishing

NEST / NESTcc- Coordination of

medical devices

EHI Vendors- EHR, other HIT systems- Structured reporting

ONC- Common Clinical Dataset - USCDI- Interoperability Standards AdvisoryFDA

- MDEpiNet, CRNs, Women’s Health

- Regulatory use cases- Global coordination- Demonstration via

projectsHL7-CIC, CIIC, CIMI …- The Playbook: Process

for CDE modeling- Tooling, repository of

logical CDE models- Registry domain analysis

modeling

NQRN Registries on FHIR- Environmental scan- ID / spec of general (core) CDEs- Demonstration / implementation

NIH / NLM …- VSAC repository- CDE repository

Implications• Data standards work is being driven by use cases

– ONC CCDS, FDA CRNs, FDA MDEpiNet, SMART on FHIR, NQRN Registries on FHIR, CMSS Registry Interoperability

– Not by clinician SMEs, associations, registries, or even SDOs

• Registries – and clinicians, societies – must be part of the interoperability ecosystem – framework is needed

• Informatics processes and formalisms are key if CDEs are to be adopted across healthcare– FHIR, HL7 does not cover clinical registry use case– CDE metadata is a good start; still need modeling CIMI– Native, interoperable CDEs is the approach

A Little Behavioral Economics …

Human frailties - and the need for “choice architecture”:

• Unrealistic optimism- If interoperability were that easy …

• Loss aversion- Inertia favors stasis

• Status quo bias- “Easy Button” default option

• Framing effects• How to convince (“sell”)

If Interoperability Was Easy …

• Illusions of– Attention– Memory– Confidence– Knowledge– Cause– Potential

Questions?

Email:[email protected]@duke.edu





improving healthcare data interoperability · • pcornet cdm leverages standard terminologies and...

Documents