1. C-CDA Constraints FACA - Strategy Discussion June 23, 2014 Mark Roche, MD

2. Constraints - Agenda Definitions and Overview Examples Benefits and Drawbacks Constraint Levels Use of Companion Guide Constraints Opportunities and Management Discussion/ QA

3. 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

4. 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.

5. Constraints: Example C-CDA IG

6. Constraints: Example Companion Guide

7. 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. ProsCons

8. 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

9. Constraints Levels - graphic (CCD, Discharge Summary, Progress Note,..) (CCD, Discharge Summary, Progress Note,..) (document ID, author, patient ID…) (document ID, author, patient ID…) [Procedures] (Colonoscopy) procedure Code: 73761001 procedure Date:Jul 1, 2010 procedure Name:Colonoscopy code73761001 codeSystemSNOMED CT codeSystemOID2.16.840.1.113883.6.96 displayName (Colonoscopy) procedure Code: 73761001 procedure Date:Jul 1, 2010 procedure Name:Colonoscopy code73761001 codeSystemSNOMED CT codeSystemOID2.16.840.1.113883.6.96 displayName [Current Medications] [ASA] [Warfarin] [ASA] [Warfarin] Data Elements (DE) Data Element (DE): Value Sets/Code System Binding Data Element (DE): Value Sets/Code System Binding DE Attributes DE attribute: Value Sets/Code System Binding DE attribute: Value Sets/Code System Binding

10. “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

11. Example 1

12. Example 2

13. Example 3

14. 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

15. Example 1: Tightening Data Elements and nullFlavors

16. Example 2: Tightening Data Vocabulary Binding

17. 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

18. Example 4: Tightening attributes (by declaring and tightening)

19. 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

20. Discussion, Q/A