Skip to end of metadata
Go to start of metadata

Date: 09/23/2020


Quarter: 3


Chair: Laura R

Scribe: Erin H

Minutes Approved as Presented 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."

Goals

Set goals, objectives or some context for this meeting.

Discussion items

TimeItemWhoNotes
75 mineCR updateJohn Loonsk

eCR 9-20 PHWG V1.pdf

  • eCR Now kicked off in April, kicked off to speed up implementation with COVID-19
  • All 50 jurisdictions and 8 jurisdictions have implemented
  • 85 million reportable COVID events reported
  • 4,900 reporting
  • eCR Now Elements
    • Rapid cohort – based covid-19 implementation (CDA based for eICR and RR)
    • eCR Now FHIR App, FHIR on the EHR side and CDA on the PH side of the app- not live yet but progressing, stepping-stone for full FHR implementation
    • Nationwide eCR trust framework
      • Doesn’t require point to point connectivity
    • See schematic for eCR Infrastructure
      • Some jurisdictions would like to implement FHIR but expect this up take to be slow and recognize the need to continue to support PH at their current capacity
      • xslt transforms so it can go back and fort
      • Expecting to be able to handle native FHIR at the platform
    • Who is we: joint project of CDC, CSTE, and APHL
      • Includes team who works on project exclusively including consultants as well
      • The platform is supported by AIMS,
      • RCKMS supporting by CSTE and CDC
      • Folks who have worked on standards in the past including Laura C and Sarah G.
    • Standards in Play:
      • eICR 1.1- in operations exclusively now
      • eICR 2.0- balloted and published but not implemented due to COVID
      • Reportability response (RR) 1.1- in implementation at the platform
      • FHIR eCR 1.0 including:
        • eICR
        • RR
        • electronic reporting and surveillance distribution (instructions for triggering for EHRs) (updates to the codes almost every week during COVID to allow for rapid inclusion of trigger codes into EHRs)
      • XSLT transforms that can convert back and forth between CDA and FHIR for the eICR and the RR.
      • Want to have the CDA eICR and the FHIR eICR to be in lock step so we don’t end up in situations where we have data with no place to put it. Will be managed in parallel to ensure consistency
    • Moving Forward
      • Take the eICR CDA 2.0 standard and do an update and never implement the 2.0 by itself
      • A minor update for the RR CDA
      • Keep the FHIR eICR in alignment with the CDA, so the FHIR version will need to be updated to reflect the eICR 2.1 updates. It currently is consistent with the 2.0 version
      • Same for RR
      • Would also want to update the eRSD as well
      • What is driving these proposed updates?
        • Done massive implementations during COVID-19 and have learned from that- driven by implementation
      • What is the requirement for ONC & CURES Act certification for EHR vendors?
        • Currently implied that that EHR vendors would need to implement the 2.0 but then immediately through it away.
        • C-CDA is listed as 2.1 in the regulation
        • The eICR 1.1, 2.0, and future 2.x would comport with the requirements for the CDA. Both eICRs IGs are using C-CDA 2.1.
        • The eICR 1.1, 2.0, and 2.x update would all be using acceptable certified version of the CDA.
        • There wouldn’t be anything in eICR 2.0 that would be thrown away if you implemented and then moved to a subsequently published IG.
      • Changes Proposed/expected:
        • eICR: CDA and FHIR
          • Alignment between eICR and broader FHIR ECR
          • Improve FHIR narratives to align with the CDA descriptions
          • Tweak pregnancy constraints to improve
          • Utilize Vital Records common profile for pregnancy
          • Add “blank” questions, dynamically entered questions and answers to accommodate data needs determined/identified during outbreaks
            • May not always need to include in the 80%, but accommodate when needed
            • Introduce conceptually
          • Add blank space for reportable condition from RR
            • Reportable condition code is different than trigger code. The RC code is less granular than the clinically associated trigger code (one or more trigger codes contribute to a reportable condition concept)
            • This could greatly simplify how PH processes the eICR
            • The point of this would be to create a place in the eICR to contain the reportable condition value.
            • It would be PH’s responsibility to pull the reportable condition value from the RR and place into the eICR, likely in the EDI engine. The eICR and the RR would come zipped together from the platform. They will be synchronized on the output from the platform
            • Amit- trying to separate out where this is happening in software vs who has the jurisdiction?
              • Each jurisdiction is able to update their jurisdictional specific rules for triggering in the RCKMS platform
              • Reportable conditions are assigned generally at the platform but those concepts are less granular then the trigger codes
              • It is up to the jurisdiction to define the requirements, the RCKMS is the software supporting this work
            • As a standards body, is there a hope that we can standardized the rules? The Rules represent the expectations of state laws. The Use of the platform and RCKMS protect the EHR vendors from seeing that complexity
          • Technical solution for EHR data entered in error
            • Retracted or not coded correctly initially
            • This shouldn’t require an update to the FHIR eSRD bc this addressing when data was entered incorrectly
          • Align FHIR IG to reference the latest release of the US Core
          • Cardinality tweaks
          • Support procedure-based triggering
          • Data & HIPAA
            • Possibly adding data, for example:
              • Disability elements
              • Congregate home settings
              • Ventilator use
              • Narrative notes
              • More specifically call out:
                • Date of symptom onset from problem list
                • Date of diagnosis
                • Location (e.g. historically ICU record)
              • Others? (known contact to a confirmed case? Case of what? When? i.e. exposure?)
            • STU comments
            • Why the reference to HIPAA? – PH exclusion (permission if you will) with enabling law (State reporting law for example)
              • The eICR was initially designed to support all reportable conditions from any jurisdiction
              • The supporting laws are HIPAA and State Reporting Rules and Regs
              • Because of this, may have to work with CSTE if we have to add data to what the CSTE task force deemed necessary
            • Expecting to be a reballot, as opposed to a dot release. Expecting to ballot in January
          • eRSD Update:
            • Triggering action restricting
            • PlanDefinition profile changes
              • Workflow definition rather than the ECA rule
              • Specifically, CQL library
              • Executable value set packaging
            • Incorporate document rule filtering arch
            • Specific jurisdiction code system
          • Reportability Response
            • Section headings issues resulting in what appears to be duplicates inappropriately in the consuming EHR
            • Sending EHRs back errors and warnings value sets on eICRs they submitted
            • Would like to do a dot release for the RR CDA version
            • Danny- Gut reaction on the RR, seems minor and could do a dot release, but want to take a closer look at eCR given we have almost 5000 implementers. So eICR may be more inclined to reballot.
              • eICR CDA, FHIR eCR would be reballot, and the CDA RR could be considered for dot release.
              • Is there a high-level adoption of the RR? RR like an ack that the reporting took place and is used. As for consuming, EHRs its currently being attached to the patient chart, but not to actively notify the patient’s provider
              • Have to be careful about altering the provider’s workflow
              • Shouldn’t be a huge lift to see consumption of the RR in the EHR
              • The RR was initially intended to provide a response back to clinical care
              • PH does find the RR helpful due to its inclusion of the reportable condition and code
              • Putting it through ballot would get this in front of more eyes and possibly more buy in.
25 mineICR STU CommentsSarah Gaunt
  • Co-Chair will need to update in the STU comments page- completed  
  • Block vote eCR 1.1:

    https://docs.google.com/spreadsheets/d/1nzqiZAAwVmahecA-g5dkXouqwHTcEGY4IFpFFRrnV5s/edit#gid=1127364330&fvid=159949121


    • 1932- persuasive with mod
      • re documentationOf and the fact that it is optional
      • If it isn't there, then it means that the eCIR was automatically generated, you can only specify a code for a manually initiated code
      • In the 2.0 version a similar comment is made, also p with mod
    • 1931- Not related
      • Question regarding usage of ODH template and the number of usual occupations permitted and whether you can document the usual occupation for a related person, can’t fix in our IG. Commenters should make a comment against the ODH IG instead. Commenter has been notified.
    • 1933- Persuasive with mod
      • Formatting issues, will be addressed in trifolia is possible

Motion: Sarah G moves to accept these three (1931, 1932, 1933) with the dispositions as stated

Second: Craig N Seconds

vote: 21,0,0

    • eCR 2.0 https://docs.google.com/spreadsheets/d/1nzqiZAAwVmahecA-g5dkXouqwHTcEGY4IFpFFRrnV5s/edit#gid=2105732947&fvid=844634506
      • Sarah moves to accept these 6 (1993, 2005, 1992, 1991, 1990, 1989) with the documented dispositions
      • Craig seconds
      • 20,0,0
        • 1993- persuasive
          • Will add guidance on templates included but not specifically apart of the respective use case to reduce confusion; will include guidance on intent of linked templates
          • Observation templates for example that include the links suggest a conformance statement
          • Should put in the details of the expectations regarding the use of linked templates
        • 2005- Not related
          • ODH example is not complete
          • Issue with the ODH template, commenter was informed to make a comment against the ODH IG
        • 1992- similar to 1993 persuasive with mod
        • 1991- Not related
          • Issue with the ODH template and commenter should make a comment against ODH IG
        • 1990- Persuasive with mod
        • 1989- Persuasive

Motion: Sarah G moves to accept these 6 (1993, 2005, 1992, 1991, 1990, 1989) with the documented dispositions

Second: Craig N seconds

vote: 20,0,0

Action items