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
The image part with relationship ID rId11 was not found in the file.
Improving Healthcare Data Interoperability
Problem Statement & Meeting Objectives
James E. Tcheng, MDDuke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
@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
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
The image part with relationship ID rId11 was not found in the file.
Improving Healthcare Data Interoperability
Design & Goals of the Project
Rebecca WilgusDuke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
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
Improving Healthcare Data Interoperability
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.
Improving Healthcare Data Interoperability
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
Improving Healthcare Data Interoperability
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
Improving Healthcare Data Interoperability
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
Improving Healthcare Data Interoperability
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)
Improving Healthcare Data Interoperability
Coming soon…
Improving Healthcare Data Interoperability
Questions?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
Common Clinical Concepts as DataEnvironmental Scan & Gap Analysis
Julia Skapik, MD, MPHCHIO
Cognitive Medical Systems
Grant support provided by The Pew Charitable Trusts
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
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
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?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
BREAKGrant support provided by The Pew Charitable Trusts
Improving Healthcare Data Interoperability
Data Element Abstraction Process & Findings
Anne HeathDuke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
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
(CRF Label) Permissible Values Concordance
Maternal Blood Pressure (systolic) [not specified] 1Resting BP Systolic Numeric (3) 1Systolic BP [not specified] 2
Diastolic BPData Element Name
(CRF Label) Permissible Values Concordance
Maternal Blood Pressure (diastolic) [not specified] 1Resting BP Diastolic Numeric (3) 1Diastolic BP [not specified] 2
Pulse
Data Element Name(CRF Label) Permissible Values Concordance
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
Data Element Name(CRF Label) Permissible Values Concordance
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?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
National Data Models & FHIR Review
Mary WilliamsDuke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
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
Data Element Name Permissible Values Concordance
Body weight N/A 3(CCDS, CCRF, FHIR)
WT N/A 2(PCORnet, Sentinel)
FHIR Recommendation: Weight
Examples: Heart Rate
HEART RATE
Data Element Name Permissible Values Concordance
Heart Rate N/A 3(CCDS, CCRF, FHIR)
FHIR Recommendation: Heart Rate
Examples: Systolic Blood PressureSYSTOLIC BP
Data Element Name Permissible Values Concordance
Systolic blood pressure N/A 3(CCDS, CCRF, FHIR)
SYSTOLIC N/A2(PCORnet, Sentinel)
FHIR Recommendation: Systolic Blood Pressure
Examples: Diastolic Blood PressureDIASTOLIC BP
Data Element Name Permissible Values Concordance
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?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
Candidate Common (Core) CDEsJames Tcheng, MD
Duke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
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
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
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
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?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
Proposed Medication ModelTom Windle
University of Nebraska Medical Center
Grant support provided by The Pew Charitable Trusts
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)
EHR System Registry Data Entry
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)
EHR System Registry Data Entry
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?
Email:[email protected]
Visit the project website: https://dcri.org/registry-data-standards/
Improving Healthcare Data Interoperability
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.
Improving Healthcare Data Interoperability
BREAKGrant support provided by The Pew Charitable Trusts
Improving Healthcare Data Interoperability
Workgroup Report Outs & Discussion
Grant support provided by The Pew Charitable Trusts
Improving Healthcare Data Interoperability
Wrap-up & Next StepsJames Tcheng, MD
Duke Clinical Research Institute
Grant support provided by The Pew Charitable Trusts
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
Visit the project website: https://dcri.org/registry-data-standards/