201609 Payer Extract

Payer Extract

Justification

To facilitate calculation of payer quality measures, payers routinely receive patient information relevant to the quality measures. This process involves time consuming export/import processes, as well as auditing and validation processes to ensure data transfer is secure and accurate. The CQF-on-FHIR resources, in particular the Measure and MeasureReport, used in conjunction with standard FHIR data interchange functionality, has the potential to streamline this process, significantly reducing effort and cost for EHR vendors, payers, and quality reporting vendors. This track focuses on this approach and exercising the resources and components involved in regularly communicating patient data based on quality measure definitions.

The previous connectathon demonstrated that the approach is feasible from a technology perspective. This track aims to build on that approach to continue to work out the details necessary for production usage. The experience from this connectathon will inform the design and structure of the quality reporting aspects of the CQF-on-FHIR resources and IG, as well as the Payer Extract IG.

Proposed Track Lead

• Bryn Rhodes
  • Email: bryn at databaseconsultinggroup dot com
  • Skype: bryn.rhodes

Roles

EHR

The EHR role in this track represents a FHIR-enabled hospital or clinic system that can be accessed using FHIR standard queries. The specific quality measures involved will determine the necessary profiles and content, but in general, DAF or QI-Core profiles can be used to describe the information. See the scenario descriptions below for specific details on the required content this role is expected to be able to provide.

Measure Processor

The Measure Processor role in this track represents a service that can perform the $evaluate-measure operation to produce individual level measure reports for specific measures. This component will make use of the EHR role to retrieve the necessary patient information.

Payer

The Payer role in this track represents a payer's system that needs to access covered patient's information. The payer will make use of the Measure Processor to determine the information required, and retrieve the necessary information as a Bundle.

Scenarios

Single Measure Individual Open Access

Action: A Payer issues an $evaluate-measure operation to a Measure Processor to determine required patient information. The inputs to this operation are:

• Measure to be evaluated (this is part of the url of the request)
• Patient Id
• Last Retrieved On (the date the data was last retrieved, only data that is new/updated since this date should be returned)

Precondition: The EHR must be prepopulated with information for the given patient that satisfies the requirements of the measure being evaluated.

Success Criteria: The Payer receives a MeasureReport with the url to a Bundle containing the required patient information.

Bonus point: Use the Last Retrieved On parameter in successive executions to demonstrate incremental data exchange

Three cohort definition measures are supported for this scenario:

• Controlling Blood Pressure (Observation resources conforming to the DAF-Vital Sign profile, blood pressure measurements)
• Adult BMI Assessment (Observation resources conforming to the DAF-Vital Sign profile, height and weight measurements)
• Colorectal Cancer Screening (Condition, Procedure, and Observation resources)

Multiple Measures

Action: A Payer issues an $evaluate-measure operation to a Measure Processor to determine required patient information for multiple measures in a single request. The results are combined in a single bundle to minimize bandwidth usage.

Precondition: The EHR must be prepopulated with information for the given patient that satisfies the requirements of the measures being evaluated.

Success Criteria: The Payer receives a MeasureReport with the url to a Bundle containing the required patient information.

Bonus point: Demonstrate that a patient resource that was involved in multiple measures is communicated only once in the results.

Multiple Patients

Action: A Payer issues an $evaluate-measure operation to a Measure Processor to determine required patient information for multiple patients for a single measure.

Precondition: The EHR must be prepopulated with information for multiple patients that satisfy the requirements of the measure being evaluated.

Success Criteria: The Payer receives MeasureReports for each patient with appropriate links to Bundles containing the required patient information.

Bonus point: Demonstrate that processing multiple patients is being done in parallel.

Security

Action: A Payer issues an $evaluate-measure operation to a Measure Processor using industry standard security protocols to guarantee correct authentication and authorization.

Precondition: In addition to the preconditions for the Single Measure Request, the EHR and Measure Processor Component must be able to work together securely to ensure authentication and authorization is correctly enforced.

Success Criteria: The Payer receives the correct MeasureReport and Bundle through secure channels.

Bonus point: Demonstrate that the Measure Processor component cannot access data for an unauthorized patient for the Payer.

Data Validity

Action: A Payer can correctly calculate the Controlling Blood Pressure measure because the information retrieved contained enough detail to ensure the measurements were valid for use (i.e. the measurement was taken at rest, in a sitting position, in an out-patient setting, etc.)

Precondition: The EHR must be prepopulated with valid blood pressure measurements for the given patient.

Success Criteria: The Payer can correctly distinguish between valid and invalid blood pressure measurements.

Bonus point: Demonstrate that only valid blood pressure is returned, reducing the amount of data communicated.