2Review of charge CCDA presentation Workplan review Next steps AgendaReview of chargeCCDA presentationWorkplan reviewNext stepsPublic comment7/9/2014
3ChargeDetermine whether there are usability issues with the CCDA v1.1 specification and associated implementation guidance (currently adopted in ONC’s certification program) that hinder interoperabilityIf 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
4Stakeholder Feedback on the Consolidated CDA (via the NPRM) ProposalONC 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 CommentsDifficult 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 StakeholderOver 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
6Agenda Current CCDA context Executive Summary Feedback sources Users feedback – optionality examples:Across all CCDA sectionsCCDA section-specificNext Steps
7Current CCDA Context Documentation Description Status CCDA standard v1.1Content 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 guideConstrains CCDA v1.1 based on MU stage 2 requirementsVoluntary for implementers to useCCDA standard v2.0New structures added (3 document templates, 6 sections, many new entries). Tighter data element constraints. New or tightened vocabulary constraints.Sep 2013
8Executive 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 mapcode spectrum (all codes or some codes from code system)Data element (DE):values andunitsDE Attributes@codeSystemnullFlavors and missing informationDistinguish between:Receive and displayReceive and consume/integrateDisplay 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.
9Sources 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 2Healthcare 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.
11Use of attributesInconsistent use of attributes. E.g. for elements that require code/value to be chosen from a codeImpact: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
12Vocabulary 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 \>
13Vocabulary too broadVocabulary binding too broad: E.g. entire SNOMED CT, entire LOINCImpact: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)\>
14Attribute 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 attributeValue 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 SystemValue Set
15Value Set BindingSome 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 SetExamples where binding is still missing:Body SiteVaccine Clinical DrugINDRoleClassSupportedFileFormatsPersonal and Legal Relationship TypeHealthcare Provider Taxonomy (HIPAA)ActStatusImpact: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.
16nullFlavors 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-CDANo Known Information – Relevant clinical scenario not appropriate for nullFlavorImpact:Difficult to integrate incoming data (from variety of sources) into local EHR
17nullFlavors & no information OmissionSystem 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 InformationNo 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 InformationNot appropriate to use nullFlavor to communicate ‘No Known Information’.C-CDA doesn’t provide explicit guidance on how to communicate No Known AllergiesHL7 Taskforce working with the community on examples for this and other similar conceptsVendors 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.
18Missing Information Issues If incoming CCD does not contain Procedures Section is it becauseProcedure data is not available.Procedure data is available but source is not required to send itIf incoming CCD does not contain Immunization Section is it becausePatient was vaccinated but Immunization data is not available.Patient was never vaccinated.Immunization data is not available but source is not required to send itIf lab sends a lab result and no reference range field is provided is it because:Source lab does not maintain that fieldSource lab maintains the field but forgot to parse data values?Source lab maintains the field but is not required to provide information?
19nullFlavors (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.
21Section-specific: Header Omission of maritalStatusCodeOmission of all associated data elements except languageCode in languageCommunication@displayName for Gender, Race, EthnicityImpact described previouslyInconsistent use of name qualifiers, especially for Last NameBirthplace:US: state required, country not required.postalCode (MAY), city (not specified); omissionIf 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 addressImpact: 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.
22Section-specific: Results (lab and other) Result <code>LOINC, SNOMED CT and local codes allowedImpact: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 permittedSome 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 labsOverall 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.
23Section-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/LImpact: 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.@codeSystemNameImpact described previouslyreferenceRange (currently: SHOULD)Omission for quantitative resultsImpact: 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 intervalsImpact: Difficult to parse and integrate inbound data. Local system may have differently structured data.methodCode (currently: MAY)No vocabulary binding specifiedImpact: Free-texted field, lack of vocabulary makes it difficult to normalize and integrate incoming data.
24Section-specific: Allergy Omission of templates that further describe Allergic reaction:Reaction (currently SHOULD)Severity (currently MAY)Impact:Data completeness and qualityUsers 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.
25Section-specific: Medications Omission@displayName not specified for medication code or translation codes.Impact: described previouslyrouteCode 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.
26Section-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”) ordistinct (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).
27Section-specific: Problems Impact described previouslyInconsistent use of nullFlavors
28Section-specific: Social Hx -> Smoking Hx Impact described previouslyThree 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)
29Section-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 systemCCDA R2 recommends(but does not require) following units:not providedImpact described previouslyNameUnitPulseOx%Height/Head CircumfcmWeightkgTempCelBPmm[Hg]Pulse/Resp Rate/minBMIKg/m2BSAm2
30Other points Document Level Multiple document types, depending on settingFor some sections, entries are required in one document type but not in another. E.g. Vital SignsEntries required: Discharge Summary,…Entries optional: Continuity of Care Document (CCD),…Impact:Receiver can process narratives easily, but structured (coded) entry will not always be presentEasy for human to readDifficult for computers to utilize and processSender has to support multiple configurations to determine when to send entries and when not.
31Next stepsWhat is the optimal mechanism to constrain C-CDA (reduce optionality)?Group-wise (who should do the work)S&I FrameworkHL7 structured documents wgDocument/Form-wise (how should outcomes be required)Companion Guide: Updates to (subsequent versions of)C-CDA IG: Updates to (subsequent versions of)Any other?
32Next 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 MU2Address constraints for high-frequency documents firstBy data elements, attributes and associated vocabulary bindingStart with MU2 set, then other DEsChallenge questions: is data interoperable, are there too many ways to send dataBy Section:Allergies, Problems and Medications firstTimeframe:What is timeframe for constraining C-CDA R2?
34Workplan Meeting Date Tasks June 23rd Introduction of charge Presentation from ONCJuly 9thWorkgroup discussionJuly 28thPresentations – field experience (challenges with CDA)HIEs?August 11thAugust 20thRecommendations to HITSC7/9/2014