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

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

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

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

5. C-CDA Constraints
Mark Roche, MD

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

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

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

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

10. Feedback across all CCDA sections

11. Use of attributes
Inconsistent use of attributes. E.g. for elements that require code/value to be chosen from a code
Impact:
often not specified. This may result in mismatches being sent between E.g. SNOMED and 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 ) or SNOMED CT (CodeSystem: ), and MAY be selected from CPT-4 (CodeSystem: ) or ICD10 PCS (CodeSystem: )
Correct
<code
@code=“ ”
@displayName= “Endoscopy CT” \>
Incorrect
<code
@code=“ ”
@displayName= “Endoscopy CT” \>
Often missing

12. 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 ) or SNOMED CT (CodeSystem: ), and MAY be selected from CPT-4 (CodeSystem: ) or ICD10 PCS (CodeSystem: )
User 1
<code
@code=“ ”
\>
User 2
<code
@code=“0FT44ZZ”
@displayName= “Resection of Gallbladder, Percutaneous \>

13. 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” ( )
Procedure code example (“Procedure Activity Procedure” Template):
This code in a procedure activity procedure activity SHOULD be selected from LOINC (codeSystem ) or SNOMED CT (CodeSystem: ), and MAY be selected from CPT-4 (CodeSystem: ) or ICD10 PCS (CodeSystem: )
Correct
<code
@code=“ ”
@displayName= \>
Semantically Incorrect
<code
@code=“ ”
@displayName= “Cholecystectomy sample” (specimen)
\>

14. 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):
Value Set (Problem Type Value Set):
Same attribute is used to capture both OIDs:
<code codeSystem=“ ”,…\>
<code codeSystem=“ ”,…\>
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

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

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

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

18. 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?

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

20. CCDA section-specific feedback

21. Section-specific: Header
Omission of maritalStatusCode
Omission of all associated data elements except languageCode in languageCommunication
@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
If city is element is not specified in IG, and sender provides postalCode but 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 associated (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.

22. 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 ( ) 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.

23. 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.
@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.

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

25. Section-specific: Medications
Omission
@displayName 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.

26. 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).

27. Section-specific: Problems
Impact described previously
Inconsistent use of nullFlavors

28. Section-specific: Social Hx -> Smoking Hx
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):
(Unknown if ever smoked) and (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)

29. 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:
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

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

31. 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?

32. 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?

33. Thank you.

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