Page tree
Skip to end of metadata
Go to start of metadata

Clinical Quality Information

Justification and Objectives

  • This track will test the $care-gaps operation 
  • Understand existing capability of the operation
  • Discuss additional functionality of the operation to support both the Gaps in Care use case and the Member Attribution IG

Related tracks

HIMSS20 Clinical Scenario

Da Vinci Risk Based Contract Member Identification

Proposed Track Lead

Eric Thomas (Independence Blue Cross)

Expected participants

Potential producers (health plans) and consumers (3rd party application developers) of the Plan-net data.

Please add your name/organization here:



Jason BrophyCambia
Juliet RubiniMathematica

System Roles

Local Requester (Client)

An application that can query a FHIR server implementing the $care-gaps operation

Plan-Net  (Server)

A server that contains quality measure data and implements the $care-gaps operation

Connectathon Resources:

Hosted Reference Implementation


Track tasks:

  • Review this Care Gap Walk through: -
  • Evaluate the $care-gaps operation with EXISTING data to understand the parameters and response
  • Evaluate the ability to use the Group resource from Member Attribution
  • Review DEQM  steps in HIMSS20 Scenario to see if $care-gaps can support pneumococcal vaccination, controlling blood pressure, medication reconciliation post-discharge
  • Summarize next steps to support/change the HIMSS20 scenario based on scenario needs and $care-gaps capability
    • Plans to update the server to R4
    • Data needs to support the HIMSS20 Scenarios
    • What details in the Group resource are needed to support a population based $care-gaps API?

    • Update the $care-gaps api and implementation to support the Group as a parameter, as opposed to Patient Bryn Rhodes

    • Will need to create additional patients and measure data to support the $care-gaps api

      Measures - Controlling Blood Pressure, Colon Cancer Screening, Breast Cancer Screening

      Need to be able to support the subject list to include patient level measure details

      API input - a list of patients (Group resource) and the measure category

      API response - a measurereport (by measure), the list of patients, and supporting measure data

Scenario 1: 





Security and Privacy Considerations

No security or privacy considerations.   Data is not patient-related.

Action Items:

Cambia and Independence to supply definition of data submitted to providers currently.

Evaluation Outcome:

In this current world, payers would not have enough required FHIR data in a FHIR database to be able to supply care gaps.  However, using internal systems, payers already would have data on what care gaps exist and could be supplied to providers in a FHIR format.  In time, data could become available in a fully integrated FHIR world.

  • No labels