Jira and Confluence will be undergoing maintenance on Monday Nov 28th from 3-5pm We apologize for the inconvenience.

Page tree


Work In Progress: Gathering/Using Care Data Across CDOs

What are Collaborative Participants and Other Currently Doing to Close this Gap?

University of Minnesota: 

See LHS Case Study for details

Making EHR Data More Available for Research and Public Health (MedMorph)

  • Aiming to reduce "reporting burden" on providers and provider organizations
  • Developed a reference architecture and representative content implementation guides to streamline how data is collected from healthcare organizations to any endpoint (e.g., public health agency, research organization, etc.)

The descriptions for each step in the above diagram are described below:

  • Step 1: A Public Health Agency (PHA) or a Research Organization (RO) creates a Knowledge Artifact (KA) and makes it available via the Knowledge Artifact Repository (KAR).
    • Step 1a: KARs, which implement notifications, can optionally notify the subscribers (EHRs, Backend System App, Administrators) of changes in the KAs.
  • Step 2: Backend Service App (BSA) queries the KAR to retrieve a KA.
    • Step 2a: BSA receives the KA as a response to the query in Step 2.
  • Step 3: BSA processes the KA and creates subscriptions in the EHR’s FHIR Server so that it can be notified when specific events occur in clinical workflows.
  • Step 4: Providers, as part of their clinical workflows, update the data in the EHR patient chart.
  • Step 5: EHR notifies the BSA based on subscriptions that have been created in Step 3.
  • Step 6: BSA queries the EHR for patient’s data.
    • Step 6a: BSA receives the response from the EHR with the patient’s data.
  • Step 7: After the creation of the report with identifiable data that needs to be submitted, the BSA invokes Data/Trust Services (DTS) to de-identify, anonymize, pseudonymize the report as needed (NOTE: DTS are not invoked if the data must remain identifiable, as with most public health use cases).
    • Step 7a: BSA receives the de-identified, anonymized or pseudonymized report (only if DTS have been invoked).
  • Step 8: The BSA submits the created report in Step 7 to the PHA/RO directly without any Trusted Third Parties (TTPs) acting as intermediaries.
    • Step 8a: PHAs/ROs can require TTPs to act as intermediaries to receive reports from clinical organizations. For these scenarios, the BSA submits the created report to the TTP.
    • Step 8b: The TTP receives a submitted report from the BSA and forwards the report to the PHA/RO.
  • Step 9: The PHA/RO submits a response back to the healthcare organization based on the submitted report. The response transaction can be synchronous (immediately w.r.t. Step 8) or asynchronous (after a period of time).
    • Step 9a: The PHA/RO can require TTP to act as intermediaries to submit reports to clinical organizations. For these scenarios, the PHA/RO submits a response to the TTP.
    • Step 9b: The TTP receives the submitted response from the PHA/RO and forwards the response to the BSA which is part of the healthcare organization.
  • Step 10: The BSA writes back the response from the PHA/Research Organization to the EHR as appropriate. (NOTE: The response may have to be re-identified in some scenarios using Data/Trust Services before it is written back to the EHR.)


  • Provides tools for data aggregation and validation.


  • CMS is coordinating across federal agencies (HHS, VA, DOD) to identify a single list of common data elements that are needed for various purposes (quality measurement, case reporting, guideline development, etc.) across federal agencies. The goal is to help ONC in the next update to the USCDI (list of data elements that are part of US EHR certification criteria). Having all EHR vendors have a common list of data elements will ensure availability and exchange of care process and results data needed for this part of the LHS cycle.


  • Measurement-based activities
    • Has a goal to digitize measures; this is a stepping stone for having data available for other key uses. Intend to leverage FHIR where applicable.
  • QI activities
    • CMS Data and Analytics Supporting Healthcare (DASH): overarching contract from CMS to provide a commercial, streamlined process to support CMS Quality Related Initiatives with the need for agile delivery services, including IT management and governance, business process analysis, Human-Centered Design (HCD), agile solution architecture and design, agile application development and configuration, analytics and reporting, integration, and DevOps.