Implementation Workgroup Constraining the CCDA Liz Johnson, co-chair Cris Ross, co-chair July 9, 2014

Review of charge CCDA presentation Workplan review Next steps Agenda Review of charge CCDA presentation Workplan review Next steps Public comment 7/9/2014

Charge Determine whether there are usability issues with the CCDA v1.1 specification and associated implementation guidance (currently adopted in ONC’s certification program) that hinder interoperability If there are issues that hinder interoperability, how can ONC most effectively address these issues, including through future versions of the certification program? 7/9/2014

Stakeholder Feedback on the Consolidated CDA (via the NPRM) Proposal ONC proposed to create a new “cross-vendor” exchange requirement. Specifically, ONC proposed to require EHR technology certified to ToC to demonstrate that it can successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time (performance standard). Relevant Implementation Workgroup Comments Difficult to understand how the performance standard could be tested for certification. It would seem minimally that a library of derivative Consolidated CDAs would have to be available or a testing tool capable of generating the same would need to be available for vendors to prepare with. Patient Matching - Requiring month, day and year is an unnecessary constraint. Instead, use just the year. Summary of Comments by Other Stakeholder Over twenty comments on this proposal. Commenters questioned the likelihood that the proper set of testing documents could be collected, which would prevent efficient testing and development. Commenters believed that the 95% threshold would be impractical, time consuming, and expensive to implement, given the wide variation in Consolidated CDA implementation. Commenters sought additional information about what it means to “electronically process.” Commenters supported constraining the Consolidated CDA as a better way to achieve ONC’s stated goals. 7/9/2014

C-CDA Constraints Mark Roche, MD

Agenda Current CCDA context Executive Summary Feedback sources Users feedback – optionality examples: Across all CCDA sections CCDA section-specific Next Steps

Current CCDA Context Documentation Description Status CCDA standard v1.1 Content standard containing 8 document templates that address document headers, sections, and in some cases data elements (combo of shall, should, and may requirements) Adopted as part of 2014 edition certification program (required for MU stage 2) CCDA companion guide Constrains CCDA v1.1 based on MU stage 2 requirements Voluntary for implementers to use CCDA standard v2.0 New structures added (3 document templates, 6 sections, many new entries). Tighter data element constraints. New or tightened vocabulary constraints. Sep 2013

Executive Summary C-CDA R1.1  C-CDA R2.0 Data elements and vocabulary tightened. More guidance provided on how to use templates, nullFlavors and negation Indicators. Companion Guide “mapped” MU2 requirements to C-CDA R1.1, resulting in additional constraints. There is room for improvement in terms of further constraints: Vocabulary: Number of vocabularies available for DE – not necessarily 1-to-1 map code spectrum (all codes or some codes from code system) Data element (DE): values and units DE Attributes @displayName, @codeSystemName, @codeSystem nullFlavors and missing information Distinguish between: Receive and display Receive and consume/integrate Display of inbound CCDA document is possible using a browser and style sheet provided by HL7. User consumption is possible since narrative text must be provided. Issues arise when local EHR needs to consume coded (non-narrative) inbound data since variability in data representation “confuses” local EHR.

Sources Following sources were leveraged: HL7 C-CDA R2 ballot comments ONC-Authorized Certification Body (ONC-ACB) Companion Guide to HL7 Consolidated CDA For Meaningful Use Stage 2 Healthcare providers (large hospital centers) SITENV (sitenv.org) Analysis was focused on users feedback for CCDA R1.1 and verifying whether feedback was addressed in C-CDA R2.0.

Feedback across all CCDA sections

Use of attributes Inconsistent use of attributes. E.g. for elements that require code/value to be chosen from a code system/value set: @code, @displayName, @codeSystem, @codeSystemName. Impact: @displayName, @codeSystemName often not specified. This may result in mismatches being sent between E.g. SNOMED CT @code and LOINC @codeSystem that are discovered too late. Issue specifically when multiple vocabularies are allowed for DE. Users may easily mis-associate code and codeSystem resulting in significant data quality and integrity issues. Procedure code example (“Procedure Activity Procedure” Template): This code in a procedure activity procedure activity SHOULD be selected from LOINC (codeSystem 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (CodeSystem: 2.16.840.1.113883.6.12) or ICD10 PCS (CodeSystem: 2.16.840.1.113883.6.4) Correct <code @code=“386831001” @displayName= “Endoscopy of stomach” @codeSystem=“2.16.840.1.113883.6.96” @codeSystemName=“SNOMED CT” \> Incorrect <code @code=“386831001” @displayName= “Endoscopy of stomach” @codeSystem=“2.16.840.1.113883.6.1” @codeSystemName=“SNOMED CT” \> Often missing

Vocabulary options Too many vocabulary options within a data element: Impact: Transcoding (mapping ICD-10-PCS to SNOMED CT) is not 1-to-1. Data receivers who use SNOMED CT and receive ICD-10-PCS code may be able to display but not integrate such code into their EHR (Impaired interoperability and integration) Procedure code example (“Procedure Activity Procedure” Template): This code in a procedure activity procedure activity SHOULD be selected from LOINC (codeSystem 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (CodeSystem: 2.16.840.1.113883.6.12) or ICD10 PCS (CodeSystem: 2.16.840.1.113883.6.4) User 1 <code @code=“38102005” @displayName= “Cholecystectomy” @codeSystem=“2.16.840.1.113883.6.96” @codeSystemName=“SNOMED-CT” \> User 2 <code @code=“0FT44ZZ” @displayName= “Resection of Gallbladder, Percutaneous Endoscopic Approach” @codeSystem=“2.16.840.1.113883.6.4” @codeSystemName=“ICD10PCS” \>

Vocabulary too broad Vocabulary binding too broad: E.g. entire SNOMED CT, entire LOINC Impact: SNOMED CT problem code used in a procedure template in inbound data. Impacts interoperability (semantically incorrect code used for a given template) Remedy: Constrain SNOMED CT to those codes that are descendants of a SNOMED CT code “Procedure” (71388002) Procedure code example (“Procedure Activity Procedure” Template): This code in a procedure activity procedure activity SHOULD be selected from LOINC (codeSystem 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (CodeSystem: 2.16.840.1.113883.6.12) or ICD10 PCS (CodeSystem: 2.16.840.1.113883.6.4) Correct <code @code=“38102005” @displayName= “Cholecystectomy” (procedure) @codeSystem=“2.16.840.1.113883.6.96” @codeSystemName=“SNOMED-CT” \> Semantically Incorrect <code @code=“309205005” @displayName= “Cholecystectomy sample” (specimen) @codeSystem=“2.16.840.1.113883.6.4” @codeSystemName=“ICD10PCS” \>

Attribute use for Code/Value Set system Unable to distinguish between Code System and Value Set globally unique ISO identifier (OID) in HL7 message. Example: Code System (SNOMED CT): 2.16.840.1.113883.6.96 Value Set (Problem Type Value Set): 2.16.840.1.113883.3.88.12.3221.7.2 Same attribute is used to capture both OIDs: <code codeSystem=“2.16.840.1.113883.6.96”,…\> <code codeSystem=“2.16.840.1.113883.3.88.12.3221.7.2”,…\> Impact: semantic “overload” of codeSystem attribute Value Set project at HL7 addresses this issue by extending CCDA schema with valueSetOID. These extensions are not applied to CCDA R2 at this point. Code System Value Set

Value Set Binding Some Code systems/ Value Sets have inconsistently specified or unspecified binding stability: STATIC: codes tied to a specific version of Code System/ Value Set vs. DYNAMIC: codes tied to the current version of Code System/ Value Set Examples where binding is still missing: Body Site Vaccine Clinical Drug INDRoleClass SupportedFileFormats Personal and Legal Relationship Type Healthcare Provider Taxonomy (HIPAA) ActStatus Impact: In STATIC binding, user may need to load Value Set codes once into local EHR. In addition, STATIC VS may cause retro-grade interoperability issues. E.g.v2 VS has 15 codes, v1 VS has 10 codes. V1 user may not understand and integrate V2 codes for the 5 codes that are missing from v1 (assuming codes in v2 have been only added, and none has been deleted). In DYNAMIC binding, user may need to periodically check for latest codes and update local EHR db continuously. Binding declaration helps sender and user determine the right set of codes for information exchange. C-CDA R2 significantly improved binding specification but aforementioned Value Set may still need to be clarified.

nullFlavors and no information Missing information and inconsistent use of nullFlavor: Omission – nothing sent in the C-CDA document instance. No Information – no data recorded in the system during visit but field is “declared” in C-CDA No Known Information – Relevant clinical scenario not appropriate for nullFlavor Impact: Difficult to integrate incoming data (from variety of sources) into local EHR

nullFlavors & no information Omission System doesn’t have a value. System has a value, but doesn’t supporting sending the field. System has a value, but failed while preparing to send this field. We want to avoid omissions – if missing, the receiver can infer nothing. Through regulation and standards we can eliminate omissions by requiring the right fields as currently validated. No Information No data recorded during the visit. Systems are using several different nullFlavors (NI – No information, UNK – Unknown, NA – Not Applicable) to cover this scenario. We want to guide vendors on what to send when they have no information. For example, no information on vaccination history. Provide a single recommendation to communicate No Information. No Known Information Not appropriate to use nullFlavor to communicate ‘No Known Information’. C-CDA doesn’t provide explicit guidance on how to communicate No Known Allergies HL7 Taskforce working with the community on examples for this and other similar concepts Vendors are free, while following current conformance statements, to invent their own approach to ‘No Known Information’. We want vendors to follow a single approach to communicate no known information for each MU relevant data element.

Missing Information Issues If incoming CCD does not contain Procedures Section is it because Procedure data is not available. Procedure data is available but source is not required to send it If incoming CCD does not contain Immunization Section is it because Patient was vaccinated but Immunization data is not available. Patient was never vaccinated. Immunization data is not available but source is not required to send it If lab sends a lab result and no reference range field is provided is it because: Source lab does not maintain that field Source lab maintains the field but forgot to parse data values? Source lab maintains the field but is not required to provide information?

nullFlavors (cont.) If information is not known how and where should nullFlavor be specified? Impact: Inconsistent use (or inconsistent policies on use) of nullFlavors at various levels makes it difficult to integrate data. Example: Example solution: European Patient Summary IG stipulates that if address is not known then nullFlavor “NI” SHALL be provided for addr element and no further child element SHALL be declared.

CCDA section-specific feedback

Section-specific: Header Omission of maritalStatusCode Omission of all associated data elements except languageCode in languageCommunication Omission of @codeSystem, @codeSystemName, @displayName for Gender, Race, Ethnicity Impact described previously Inconsistent use of name qualifiers, especially for Last Name Birthplace: US: state required, country not required. postalCode (MAY), city (not specified); omission of @displayName If city is element is not specified in IG, and sender provides postalCode but without @displayName, the user would need to search corresponding city name on receiving end. Address: AD.US.Fielded template: both postalCode and city specified. If country is US, should city element match @displayName associated with @code (for USPS postal code)? Inconsistent use of usablePeriod for address Impact: significant variability in how information is sent makes it difficult for the receiver to integrate information into local system and use that information in a meaningful way.

Section-specific: Results (lab and other) Result <code> LOINC, SNOMED CT and local codes allowed Impact: Receiving system using LOINC may not be able to integrate incoming SNOMED CT code (it may be able to display though using standard CDA stylesheet provided by HL7) Any code from LOINC and SNOMED CT code system is permitted Some LOINC and SNOMED CT codes are not “result” codes. E.g. Pharyngitis (405737000) is a Problem code. Result section may contain non-result related information. Approach: Constrain vocabularies, constrain codes within vocabularies. Many LOINC codes available for one result. E.g. Erythrocyte count has 3 possible codes depending on method used (none specified, manual, auto) Impact: Receiving systems may not be able to easily integrate AND graph incoming labs Overall Impact: labs constitute up to ~60% of Dx procedures. Lack of consistency in representation of lab data makes integration of inbound data more difficult, and may lead to unnecessary duplication of lab test.

Section-specific: Results (lab and other) No guidance on value + unit pair for lab results. Example: Lymphocytes (rel.) can be reported as 45% and 0.45 (decimals) Lymphocytes (abs.) can be reported as: 2.8 x10E3/ul, 2,800 /uL, 2.8 x10E12/L Impact: Transformation required to normalize and integrate incoming labs (normalize for graphing) InterepretationCode (currently: SHOULD) Blank/empty for some entries, populated for other. Included only when result is “low”, “high” or “abnormal” Impact: Diagnostic devices can be calibrated differently, which impacts reference range and interpretation. Incoming data designated for integration into local EHR needs to contain sufficient information from data source. Omission of @displayName, @codeSystem, @codeSystemName Impact described previously referenceRange (currently: SHOULD) Omission for quantitative results Impact: Diagnostic devices can be calibrated differently, which impacts reference range and interpretation. Incoming data to be integrated needs to contain sufficient information from data source. Unstructured for intervals Impact: Difficult to parse and integrate inbound data. Local system may have differently structured data. methodCode (currently: MAY) No vocabulary binding specified Impact: Free-texted field, lack of vocabulary makes it difficult to normalize and integrate incoming data.

Section-specific: Allergy Omission of templates that further describe Allergic reaction: Reaction (currently SHOULD) Severity (currently MAY) Impact: Data completeness and quality Users may not find data “reliable” (due to lack of consistent appearance) – e.g. data is sometimes provided, and sometimes not. Also, Severity can be expressed at the Allergy level OR Reaction level. There has been confusion on which level should be chosen.

Section-specific: Medications Omission @displayName and @codeSystemName not specified for medication code or translation codes. Impact: described previously routeCode not specified (currently SHOULD) Interval timing (effectiveTime) not provided for common daily meds (e.g. Lipitor) (currently SHOULD) Impact: Reconciliation (integration) inbound medication information impacted. doseQuantity for compound medications. E.g. Compound med 40mg / 20mg / 5ml CCD can show doseQuantity as 80mg. Impact: Without knowing which ingredient, it is difficult to know if its 2x or 4x the original strength. In addition, some providers send the doseQuantity in ml. Lack of clarity, misinterpretations during inbound medication information reconciliation step.

Section-specific: Medications Medication section is structurally one of the most complex sections due to variability in which medication information can be captured. For example: Medication name, dose, units and administration form can be captured using: one field/element (e.g. “Aspiring 500 mg oral tablet”) or distinct (separate) fields, one for each information component; Name=”Aspirin”, Dose=”500”, Units=”mg”, Form=”oral tablet”. Impact: The variability in the use of brand name, generic name and ingredient names and associated formulations makes is very difficult for EHR to integrate medication information from a variety of sources).

Section-specific: Problems Omission of @codeSystemName, @displayName Impact described previously Inconsistent use of nullFlavors

Section-specific: Social Hx -> Smoking Hx Omission of @codeSystemName, @displayName Impact described previously Three template options for documenting smoking history within Social History Section. E.g. “Current Smoking Status” template: used only for current smoking status (snapshot in a time) “Tobacco Use” template: for previous smoking history “Social History Observation” template: can be used as well (although not recommended) Impact: Variability impacts integration of inbound data into local EHR. Overlapping codes (used both in “Current Smoking Status” and “Tobacco Use” Value sets): 266927001 (Unknown if ever smoked) and 428061000124105 (Light tobacco smoker) Impact: Users may chose one or the other template to document “Unknown if ever smoked”  integration of inbound data difficult. Options: (1) Require the use of both templates, remove the two, aforementioned, duplicate Value Set codes from “Tobacco Use” Template. Disallow use of “Social History Observation” template for smoking-related data. (2) require the use of one template only and disallow the use of two other templates (or completely remove them from IG) (European IG approach)

Section-specific: Vital Signs Variability in the use of units for Vital Sign data. Eg: PulseOx value [units]: 0.95 or 95 [%] Height: 192 [cm] or 1.92 [m] (both cm and m are valid UCUM units) Issues (for user receiving data): Graphing difficulty. User documenting in % and receiving decimal values needs to convert units to integrate inbound data. Challenges (for user providing data): The choice of units for data strongly depends on sending system CCDA R2 recommends (but does not require) following units: @codeSystemName, @displayName not provided Impact described previously Name Unit PulseOx % Height/Head Circumf cm Weight kg Temp Cel BP mm[Hg] Pulse/Resp Rate /min BMI Kg/m2 BSA m2

Other points Document Level Multiple document types, depending on setting For some sections, entries are required in one document type but not in another. E.g. Vital Signs Entries required: Discharge Summary,… Entries optional: Continuity of Care Document (CCD),… Impact: Receiver can process narratives easily, but structured (coded) entry will not always be present Easy for human to read Difficult for computers to utilize and process Sender has to support multiple configurations to determine when to send entries and when not.

Next steps What is the optimal mechanism to constrain C-CDA (reduce optionality)? Group-wise (who should do the work) S&I Framework HL7 structured documents wg Document/Form-wise (how should outcomes be required) Companion Guide: Updates to (subsequent versions of) C-CDA IG: Updates to (subsequent versions of) Any other?

Next steps (cont.) Strategy: Create universal set of constraints and apply to each document type (consistently)? Create document-specific constraints (e.g. CCD-specific, Discharge Summary-specific….etc)? Priorities (of work): Environmental scan: Determine which documents are most frequently produced for MU2 Address constraints for high-frequency documents first By data elements, attributes and associated vocabulary binding Start with MU2 set, then other DEs Challenge questions: is data interoperable, are there too many ways to send data By Section: Allergies, Problems and Medications first Timeframe: What is timeframe for constraining C-CDA R2?

Thank you.

Workplan Meeting Date Tasks June 23rd Introduction of charge Presentation from ONC July 9th Workgroup discussion July 28th Presentations – field experience (challenges with CDA) HIEs? August 11th August 20th Recommendations to HITSC 7/9/2014