1 / 20

C-CDA Constraints

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.

quemby-huber
Download Presentation

C-CDA Constraints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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): • Rulesimposed on data that is being collected and/or exchanged • For example: • Data element SHALL (or must) be present • If data element cannot be provided nullFlavormust be provided • Data element values SHALL be drawn from one or more code systems • Sometimes the word Constraintis 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 Pros Cons • Improved consistencyof structured document contents • Improved semantic interoperability • For example, if data element contains the values from onecoding system/value set as opposed to multiple code systems. • Improved predictabilityand reliabilityof information available to the user • Consistent implementationof 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 GUIsto 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.

  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 <clinicalDocument> (CCD, Discharge Summary, Progress Note,..) Document Type <header> (document ID, author, patient ID…) Document Sections <section> [Procedures] Entries (free-text vs coded) <entry> (Colonoscopy) procedure Code: 73761001 procedure Date: Jul 1, 2010 procedure Name: Colonoscopy code 73761001 codeSystemSNOMED CT codeSystemOID2.16.840.1.113883.6.96 displayName Data Elements (DE) Data Element (DE): Value Sets/Code System Binding DE Attributes DE attribute: Value Sets/Code System Binding <section> [CurrentMedications] <entry> [ASA] <entry> [Warfarin]

  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 nullFlavorsor 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

More Related