Short Description

Continue the testing and use of the Data Exchange for Quality Measures (DEQM IG) for gaps in care reporting use cases using FHIR-based eCQMs, Testing the use of the member attribution for gaps in care.

Testing the use of Pdex Export using atr-export and atr-patient-list.

Long Description

The Connectathon will exercise the Member Attribution  FHIR IG and validate:

  • Specific APIs proposed
  • Specific Operations proposed
  • Specific Data Structures proposed for representing the Member Attribution List. (Data Structures include Resources, profiles, valuesets, extensions)
  • Continue testing the gaps in care profiles and $care-gaps operation specified in the September 2020 Ballot DEQM IG (with gaps in care content) 
  • Continue testing gaps in care use cases focusing on an interactive and end-to-end scenario and closely coordinate with the Clinical Reasoning Track
    • Run $care-gaps using the colorectal cancer screening FHIR-based measure written with CQL (CMS130v7: Colorectal Cancer Screening)
    • Use $submit-data or $collect-data to close some gaps identified in the gaps in care report
    • Re-run $care-gaps for an updated gaps in care report to see that gaps were closed
    • Report Summary measure report
  • Test the use of populationReference extension to support associating a specific evaluatedResource to a population
  • Test the use of DaVinci Risk Based Contracts Member Attribution (ATR) List IG to attribute members when create a gap in care report
  • Test the use of bulk data to test the atr-export operation for pdex specific use case.

Type

Test an Implementation Guide

Track Lead(s)

Nagesh Bashyam

Track Lead Email(s)

Specification Information

Call for participants

Participants list for the current track is still developing and we will update as the list is finalized. The previous participant list is enclosed. 

  • Drajer LLC

Zulip stream

https://chat.fhir.org/#narrow/stream/214784-Da-Vinci.20ATR

Track Kick off Call

September 7th at 3:00 pm ET

Join Zoom Meeting: https://hl7-org.zoom.us/j/94940304335?pwd=WktVM3NnbWdtRVZiNXVYcE1kamVSdz09

Clinical Input Required?No
Related Tracks?Clinical Reasoning/Risk Adjustment/DEQM/GapsInCare/Pdex

Pre-Requisites

The following are the pre-requistes for the Member Attribution track

  • Producers (Servers) will require to implement the Bulk Data capabilities and the Member Attribution $atr-export operation. Producers can use the reference implementation of ATR to create and verify the server capabilities.
  • Consumers will require to consume the data and combine the attribution data to verify the attribution data. Consumers can use the POSTMAN for verification.
  • Familiarity with Touchstone Testing Tool is a Plus as touchstone scripts will be used for the connectathon.

Testing Scenario:

Producer Role (Server)

  • System that will be responsible for creating the Member Attribution List
  • Server has to support the following resources 
    • Patient
    • Practitioner
    • PractitionerRole
    • Coverage
    • Organization
    • Group (atr-group)
    • Group (atr-patient-list)
    • RelatedPerson (Optional)
  • APIs that would be required
    • Group/$export with the above resource types being extracted. (Phase 1, already balloted, tested and published)
    • Search/Read on Group resource (Phase 1 of the IG , already balloted, tested and published)
    • POST on GROUP (Creation of a Group for Phase 2 - getting ready for ballot)
    • POST on PATIENT (Creation of a Group for Phase 2 - getting ready for ballot)
    • POST on ORGANIZATION (Creation of a Group for Phase 2 - getting ready for ballot)
    • POST on PRACTITIONER(Creation of a Group for Phase 2 - getting ready for ballot)
    • Group/[id]/$add-member operation (Modifying Group for Phase 2)
    • Group/[id]/$remove-member operation (Modifying Group for Phase 2)
    • Group/$atr-export operation (Operation that can handle different types of export).
  • Effort Required: Few months if starting from scratch.

Consumer Role (Client)

  • System that will be responsible for consuming the Member Attribution List.
  • APIs that would be required
    • Ability to Search/Read on the Group resource (Phase 1, already balloted, tested and published)
    • Invoke Bulk API for Group/$export (Phase 1, already balloted, tested and published)
    • Consume the data that is received and at least analyze the data. (Phase 1, already balloted, tested and published)
    • POST resources to create GROUPS, PATIENTS, PRACTITIONER, ORGANIZATION
    • Support invocation of Group/[id]/$member-add operation  (Modifying Group for Phase 2)
    • Support invocation of Group/[id]/$member-remove operation  (Modifying Group for Phase 2)
    • Support invocation of Group/[id]/$atr-export operation (Generalized export for phase 2 using Member Attribution export or Pdex export)
  • Effort Required: Few weeks if starting from scratch

Scenarios

Scenario 1: Consumer (Provider Organization) discovers the applicable Group Resource in Producers (Payer Organization) system

  • (Part of Phase 1 Implementations) 

Ability for a Provider organization to discover the Group Resource representing the Member Attribution List that is applicable to their specific organization.

For example, Multicare would like to know which Group Resource in Cambi'a System is applicable for their organization using the Contract Identifier or Settlement Entity Name

Pre-condition:

  • One of the following queries will be executed
    • Provider Organization knows the Settlement Entity Name or Contract Identifier

API: 

GET <Server Base URL>/Group?identifier=http://example.org/groups|12345

Success Criteria:

  • Receive Group Resource from the API call.


Scenario 2: Consumer (Provider Organization) Requests the Member Attribution List from the Producer (Payer Organization)

  • (Part of Phase 1 Implementations) 

Ability for a Provider organization to request the full Member Attribution List that is applicable to their specific organization. Note: The request has to be accepted by the Payer and eventually a Member Attribution List would be made available. This is an asynchronous request following Bulk Data IG specifications.

For example, Multicare would like to request the Member Attribution List from Cambia for a specific contract. 

Pre-condition: 

  • Provider Organization knows the specific Group Resource for the specific contract that represents the Member Attribution List.
  • The Group Id of the specific Group Resource that is applicable and was retrieved as part of Scenario 1

API

GET or POST <Server Base URL>/Group/[Group id]/$export? _type=Patient,Practitioner,PractitionerRole,Organization,Location,Coverage,RelatedPerson

or Phase 2: Group/[Group id]/$atr-export with required parameters (sub-set of patients, subset of types, since parameter)

Success Criteria:

  • Request is accepted by the Payer and a Content Location is received as part of the Response. 


Scenario 3: Consumer polls the Content Location for Request Completion and Member Attribution List data location. 

  • (Part of Phase 1 Implementations) 

Ability for a Provider organization to poll the Content Location received as part of Scenario 2 to determine completion status of the Member Attribution List Request issued in Scenario 2 and once completed identify the location of the files that represent the Member Attribution List.

For example, Multicare would poll the content location received as part of the response in Scenario 2. 

Pre-condition: 

  • Provider Organization has requested the Member Attribution List which was accepted by the Payer.
  • Provider Organization has the URL for the Content Location where the request status can be polled.

API

GET <Content Location from Scenario 2 response>

Success Criteria:

  • Completion Status indicated by 200 HTTP code and the Response Body containing the URLs for the files representing the Member Attribution List.
  • There needs to be at least one URL for each of the resource types specified using the _type parameter in the Scenario 2. (

Patient, Practitioner, PractitionerRole, Organization, Location, Coverage, RelatedPerson)


Scenario 4: Consumer retrieves the files representing the Member Attribution List

  • (Part of Phase 1 Implementations) 

Ability for a Provider organization to retrieve each of the files that represent the Member Attribution List.

For example, Multicare retrieves each of the NDJSON files representing the Member Attribution List.

Pre-condition:

  • Provider Organization has the URLs to retrieve the files representing the Member Attribution List from the response indicating that the export request was completed.

API

GET <File URL for each Resource identified in Scenario 3 completion response>

Success Criteria:

  • Retrieve the NDJSON files for each of the following resources:
    • Patient, Practitioner, PractitionerRole, Organization, Location, Coverage, RelatedPerson


Scenario 5: Consumer creates PATIENT, PRACTITIONER and ORGANIZATION resources

  • (Part of Phase 2 Implementations) 

Ability for a Provider organization to create Patient, Practitioner and Organization resources to be used in the Group.

For example, a Provider organization planning to use CMS DPC system would create these resources before creating the Group.

Pre-condition:

  • Provider Organization has the URLs
  • Provider Organization has a treatment relationship with the Patient.

API

POST <BaseURL>/[Patient|Practitioner|Organization]

Success Criteria:

  • Verify that the resources have been created.


Scenario 6: Consumer creates Group resource

  • (Part of Phase 2 Implementations) 

Ability for a Provider organization to create Group resource.

For example, a Provider organization planning to use CMS DPC system would create a Group resource.

Pre-condition:

  • Provider Organization has the URLs
  • Provider Organization has a treatment relationship with the Patient.

API

POST <BaseURL>/[Group]

Success Criteria:

  • Verify that the resources have been created.


Scenario 7: Consumer modifies Group resource

  • (Part of Phase 2 Implementations) 

Ability for a Provider organization to add members to the  Group resource.

For example, a Provider organization planning to use CMS DPC system would create a Group resource and add members to the Group with whom they have a treatment relationship.

Pre-condition:

  • Provider Organization has the URLs
  • Provider Organization has a treatment relationship with the Patient.

API

POST <BaseURL>/Group/[id]/$member-add

Success Criteria:

  • Verify that the members have been added to the Group by retrieving the Group.


Scenario 8: Consumer modifies Group resource

  • (Part of Phase 2 Implementations) 

Ability for a Provider organization to remove members from the  Group resource.

For example, a Provider organization planning to use CMS DPC system would create a Group resource and add members to the Group with whom they have a treatment relationship, when the treatment relationship no longer exists the Provider Organization may remove the members from the Group.

Pre-condition:

  • Provider Organization has the URLs
  • Provider Organization has a treatment relationship with the Patient.

API

POST <BaseURL>/Group/[id]/$member-remove

Success Criteria:

  • Verify that the members have been removed from the Group by retrieving the Group.


TestScript(s)

  • Indicate any test scripts that will be used to help verify system behavior


TestScript(s)

  • Touchstone - DaVinci Member Attribution 4.0.1


Security and Privacy Considerations

  • SMART on FHIR Backend Services Authorization is specified by the IG. However it is not required for Connectathon purposes this time around since this is the first time this IG is being tested.