- Created by Nagesh Bashyam, last modified by Holli Murphy on Jan 10, 2023
NOTE: For information on this track, please visit the Value Based Performance Reporting track desk and contact Dave Degandi for information on Member Attribution track.
Track Kick off Slides: https://confluence.hl7.org/download/attachments/144981756/ATR%20Slides%20Connectathon%20Jan%202023.pptx?api=v2
Server Info and Postman Collection for RI: https://confluence.hl7.org/download/attachments/144981756/Memeber%20Attribution.postman_collection.json?api=v2
Demo of using Touchstone and Postman collection to verify Member Attribution: Member Attribution List Demo
Short Description | Testing the use of Member Attribution STU2 candidate IG focusing on the following operations davinci-data-export and davinci-patient-list |
Long Description | The Connectathon will exercise the STU2 candidate Member Attribution FHIR IG and validate:
|
Type | Test an Implementation Guide |
Related Tracks? | |
Call for participants | EHR vendors Payers ACOs |
Track Prerequisites | Bring either a client or a server (Consumer or a Producer). Clients can also be POSTMAN. |
Track Lead(s) | David Degandi Nagesh Bashyam |
Track Lead Email(s) | |
Specification Information |
|
Zulip stream | |
Track Kick off Call | 12/14/2022 |
Testing Scenario: | Producer Role (Server)
Consumer Role (Client)
Scenarios Scenario 1: Consumer (Provider Organization) discovers the applicable Group Resource in Producers (Payer Organization) system
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:
API: GET <Server Base URL>/Group?identifier=http://example.org/groups|12345 Success Criteria:
Scenario 2: Consumer (Provider Organization) Requests the Patient List from the Producer (Payer Organization) Ability for a Provider organization to request the full Patient 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:
API Group/[Group id]/$davinci-data-export with required parameters (sub-set of patients, subset of types, since parameter) Success Criteria:
Scenario 3: Consumer polls the Content Location for Request Completion and Member Attribution List data location.
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:
API GET <Content Location from Scenario 2 response> Success Criteria:
Patient, Practitioner, PractitionerRole, Organization, Location, Coverage, RelatedPerson) Scenario 4: Consumer retrieves the files representing the Member Attribution List
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:
API GET <File URL for each Resource identified in Scenario 3 completion response> Success Criteria:
Scenario 5: Consumer creates PATIENT, PRACTITIONER and ORGANIZATION resources
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:
API POST <BaseURL>/[Patient|Practitioner|Organization] Success Criteria:
Scenario 6: Consumer creates Group resource
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:
API POST <BaseURL>/[Group] Success Criteria:
Scenario 7: Consumer modifies Group resource
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:
API POST <BaseURL>/Group/[id]/$member-add Success Criteria:
Scenario 8: Consumer modifies Group resource
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:
API POST <BaseURL>/Group/[id]/$member-remove Success Criteria:
TestScript(s)
TestScript(s)
Security and Privacy Considerations
|