C-CDA ConstraintsFACA - 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

code 73761001codeSystem 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