c-cda constraints faca - strategy discussion june 23, 2014 mark roche, md
TRANSCRIPT
C-CDA Constraints
FACA - Strategy Discussion
June 23, 2014
Mark Roche, MD
Constraints - Agenda
• Definitions and Overview• Examples• Benefits and Drawbacks• Constraint Levels• Use of Companion Guide• Constraints Opportunities and Management• Discussion/ QA
Constraints - definition
• Constraints in terms of HL7 structured documents (in simple terms):– Rules imposed on data that is being collected and/or exchanged
• For example:– Data element SHALL (or must) be present– If data element cannot be provided nullFlavor must be provided– Data element values SHALL be drawn from one or more code systems
• Sometimes the word Constraint is used synonymously with Optionality– inversely related more constraints = less optionality
Constraints: conformance verbs, nullFlavors and negation Indicators
• SHALL: data must be provided; the data is Required• SHOULD: best practice; the data is Optional• MAY: a placeholder to provide data if user wants to; the data is
Optional• nullFlavors: a way to satisfy data element requirement when
data is unknown (e.g. not available, no information,…)– Any Data Element may use nullFlavor.– Attributes use negation Indicators.
Constraints: Example C-CDA IG
Constraints: Example Companion Guide
Constraints: pros and cons
• Improved consistency of structured document contents
• Improved semantic interoperability– For example, if data element
contains the values from one coding system/value set as opposed to multiple code systems.
• Improved predictability and reliability of information available to the user
• Consistent implementation of standards across vendors.
• Data element requirements differ based on clinical or administrative intent
• Requirement to capture data that may not be relevant to clinical or administrative intent (case)
• Systems may be required to extend their databases and GUIs to capture more fields than they do now.
• Semantic and structural overload of CCDA templates.– E,g. Smoking Status (MU2)
required a new CCDA template (Smoking Status Observation) to satisfy MU2 reqs.
Pros Cons
Constraints Levels
• Document (CCD, Progress Note, Discharge Summary)• Sections• Entries (free-texted narrative vs coded)• Data Elements (DE) (name, value, code, effectiveTime)
– Optionality (SHALL, SHOULD, MAY)– Value (Vocabulary)
• Binding (SHALL, SHOULD, MAY)• Type (e.g. just LOINC, vs LOINC OR SNOMED CT)
– nullFlavor values
• Data Element (DE) Attributes (@code, @codeSystem, @displayName)– Optionality (SHALL, SHOULD, MAY)– Value (Vocabulary)
• Binding (SHALL, SHOULD, MAY)• Type (e.g. just LOINC, vs LOINC OR SNOMED CT)
• nulFlavors
Constraints Levels - graphic<clinicalDocument>(CCD, Discharge Summary, Progress Note,..)
<header> (document ID, author, patient ID…)
<section> [Procedures]
<entry> (Colonoscopy)procedure Code: 73761001procedure Date: Jul 1, 2010procedure Name: Colonoscopy
code73761001
codeSystem SNOMED CTcodeSystemOID 2.16.840.1.113883.6.96displayName
<section> [Current Medications]
<entry> [ASA]<entry> [Warfarin]
Data Elements (DE)
Data Element (DE):Value Sets/Code System Binding
Document Type
Document Sections
DE Attributes
Entries (free-text vs coded)
DE attribute:Value Sets/Code System Binding
“Companion Guide” (CG)
• Provides supplemental guidance an offers practical guidance on how to implement CCDA in light of 2014 Ed. CEHRT requirements
• CG is informative and does not impose new constraints beyond those that already exist in C-CDA and in 2014 Ed. CEHRT requirements.– In terms of constraints, CG:
• Summarizes existing constraints from CCDA• Ties (maps) CCDA constraints to MU2 requirements.• Provides practical examples for implementers to improve
consistency• Recommends adding sections to CCD
Example 1
Example 2
Example 3
Opportunities
• Require more data elements (DE) to be collected– (MAY/SHOULD SHALL)
• Provide more guidance on where to use nullFlavors or negation indicators if information is not available.
• Reduce the number of code system options for DEs• Narrow code system breadth• Require consistent information for attributes
Example 1: Tightening Data Elements and nullFlavors
Example 2: Tightening Data Vocabulary Binding
Example 3: Tighten vocabulary options
• Vocabulary options– ICD-9
• Vocabulary breadth (within a code system)– SNOMED CT
C-CDA R1.1
C-CDA R2.0
Example 4: Tightening attributes (by declaring and tightening)
Constraints Management - Options
• Constraining underlying (CDA) or derivative (C-CDA) standard– Balloting process through HL7 required
• 3 times/ year• Time consuming process (July 2012 -> Sep 2014)• Updating base standard often involves other structural improvements to standard in
addition to constraints (e.g. new datatypes, new templates, new sections, new entries…etc)
– Ballot passing is subjected to approval of all changes to standard (not just tighter constraints)
• Constraining “Companion Guide to C-CDA for MU”– Balloting process through HL7 required– Tied to specific version of standard (e.g. CCDA 1.1, CCDA 2.0)
• May require updates if underlying standard version changes
– Can be more targeted to constraining data elements.• Constraining directly in CFR (specify directly in CFR all DE constraints)
– Lengthy and complex.– Not tied to specific version of standard
• May require Implementation guide that ties CFR reqs. To standard
Discussion, Q/A