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