Da Vinci - Risk Based Contracts Member Attribution (ATR) List
0.1.0 - STU1 Ballot
Da Vinci - Risk Based Contracts Member Attribution (ATR) List
0.1.0 - STU1 Ballot
This page is part of the Risk Based Contracts Member Attribution List FHIR IG (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions 
This section of the implementation guide defines the specific conformance requirements for systems wishing to conform to this Risk Based Contracts Member Attribution List Exchange implementation guide. The bulk of it focuses on the implementation of the Bulk Data IG to meet attribution list use-cases. It also describes the use of SMART on FHIR Backend Services Authorization and provides guidance on privacy, security and other implementation requirements.
Before reading this formal specification, implementers should first familiarize themselves with two other key portions of the specification:
The Use Cases & Overview page provides context for what this formal specification is trying to accomplish and will give a sense of both the business context and general process flow enabled by the formal specification below.
The Technical Background page provides information about the underlying specifications and indicates what portions of them should be read and understood to have necessary foundation to understand the constraints and usage guidance described here.
This implementation guide uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:
SHALL indicates requirements that must be met to be conformant with the specification.
SHOULD indicates behaviors that are strongly recommended (and which may result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
MAY describes optional behaviors that are free to consider but where the is no recommendation for or against adoption.
This implementation guide sets expectations for two types of systems:
Producer systems are typically Payer systems but could theoretically be any system responsible for producing a Member Attribution List. These systems typically act as servers.
Consumer systems are typically Provider systems that act on behalf of provider organizations who retrieve the attribution list from Producer. These systems typically act as clients.
The requirements and expectations described here are not intended to be exhaustive. Producers and Consumers could potentially support additional resources and extensions, etc. The purpose of this implementation guide is to establish a baseline of expected behavior and data elements that communication partners can rely on and then build from. Future versions of this specification will evolve based on implementer feedback.
This specification makes significant use of FHIR profiles, search parameter definitions and terminology artifacts to describe the content to be shared as part of Memeber Attribution List interactions. The implementation guide supports two versions of FHIR: STU3 and R4 and profiles for both are listed for each interaction. This version of the specification does not (yet) provide guidance for DSTU2 resources.
The full set of profiles defined in this implementation guide can be found by following the links on the FHIR Artifacts page.
This implementation guide also leverages the US Core set of profiles defined by HL7 for sharing non-veterinary EMR individual health data in the U.S. Where US Core profiles exist, this Guide either leverages them directly or uses them as a base for any additional constraints needed to support the member attribution list use cases. If no constraints are needed, this IG doesn’t define any profiles.
Where US Core profiles do not yet exist (e.g. for Coverage, Group), profiles have been created that try to align with existing US Core profiles in terms of elements exposed and terminologies used.
This section outlines how the Bulk Data IG will be leveraged by this implementation guide.
Producer systems SHALL support the [base]/Group/[id]/$export operation for member attribution list implementation.
Producer systems SHALL support the reading and searching of Group resources per the capability statement expectations outlined below.
Producer systems SHALL support Patient, Related Person, Practitioner, PractitionerRole, Location, Organization, Coverage, Group resource types for the [base]/Group/[id]/$export?_type parameter.
Producer systems SHALL support the Bulk Data Request Flow as defined in the Bulk Data IG specification.
Producer systems MAY support the Bulk Data Delete Request as defined in the Bulk Data IG specification.
Producer systems SHALL support the Bulk Data Status Request as defined in the Bulk Data IG specification.
Producer systems SHALL set the requireAccessToken to true within the Bulk Data Status Request response body as defined in the Bulk Data IG specification.
Producer systems SHALL require Consumer systems to provide valid access token to access the member attribution list files.
When the Consumer systems do not have appropriate authorization to the data requested, the Producer systems SHALL return OperationOutcome with appropriate error message.
When the Consumer systems do not have appropriate access token to access the data requested, the Producer systems SHALL return OperationOutcome with appropriate error message.
This section outlines how the SMART on FHIR Backend Services Authorization guide will be used by this implementation guide.
Producer systems SHALL advertise conformance to SMART Backend Services by hosting a Well-Known Uniform Resource Identifiers (URIs) as defined in the Bulk Data IG specification.
Producer systems SHALL include token_endpoint, scopes_supported, token_endpoint_auth_methods_supported and token_endpoint_auth_signing_alg_values_supported as defined in the Bulk Data IG specification.
Consumer systems SHALL share their JWKS with the Producer systems using URLs as defined in the Bulk Data IG specification.
Consumer systems SHALL obtain the access token as defined in the Bulk Data IG specification.
Producer systems SHALL support system/Patient.read, system/Practitioner.read, system/PractitionerRole.read, system/Coverage.read, system/Organization.read, system/RelatedPerson.read, system/Location.read, system/Group.read scopes.
During Consumer registration, the Producer system SHALL collect the NPI and Tax Identification Numbers applicable for a specific contract along with the specific contract information. This information is necessary for the Producer to create the necessary Member Attribution List and provide an API that will allow the Consumer to retrieve the Member Attribution List.
When the Consumer is trying to discover the specific Group resource that represents the Member Attribution List for a specific contract, the Producer SHALL verify that the Consumer credentials provided allow the Consumer to access the requested specific Group Resource. NOTE: This verification is for a specific Group instance and not just the type which is controlled by the scopes.
This section lists the capability statements for Producer and Consumer systems.
The specific requirements for the Producer systems are outlined in the Producer Capability Statement.
The specific requirements for the Producer systems are outlined in the Consumer Capability Statement.
This interaction outlines the APIs for a Consumer (for example, Provider organization) to discover the Group Resource in a Producer’s system ( for example, Payer organization).This Group resource represents the Member Attribution List that has been created by the Producer based on a contract between the Producer and the Consumer. FFor example, Multicare a Provider Organization would like to identify the Member Attribution List that a Payer organization (e.g Cambia Health Systems) has created based on a contract between Cambia and Multicare.
Precondition:
In order to discover the appropriate Group Resource (Member Attribution List) the Consumer is expected to know its own NPI and Tax Identification Number.
API:
GET <Server Base URL>/Group?identifier:oftype=http://terminology.hl7.org/CodeSystem/v2-0203|NPI|<ExampleNPI>&identifier:oftype=http://terminology.hl7.org/CodeSystem/v2-0203|TAX|<ExampleTIN>
In the above API, notice the use of “oftype” modifier on the search to allow searching based on type which includes a CodeSystem and a Value. In addition the “ExampleNPI and ExampleTIN” will be substituted with the values that represent the Consumer organization.
The Producer verifies the client credentials according to the SMART Backend Services Authorization protocols and in addition verifies that the Consumer is allowed to access the specific Member Attribution List and returns one or more Group Resources representing the Member Attribution Lists for each contract between the Producer and the Consumer.
Expected Result:
Consumer receives one or more Group Resources from the API call. Each Group Resource represents a specific Member Attribution List between the Producer and the Consumer. To narrow down the specific Member Attribution List for a specific contract the Consumer has to examine the Group.characterstic.valueReference element and compare the contract information.
AThis interaction outlines the APIs for a Consumer (Provider) organization to request the full Member Attribution List that is applicable to their specific organization for a specific contract. 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 details from Cambia Health Systems for a specific contract.
Precondition:
Provider Organization knows the specific Group Resource for the specific contract that represents the Member Attribution List from executing the discovery of group resource API outlined previously.
API:
GET or POST <Server Base URL>/Group/[Group id]/$export?_type=Patient,Practitioner,PractitionerRole,Organization,Location,Coverage,RelatedPerson
Expected Results: Request is accepted by the Producer and a Content Location is received as part of the Response.
This interaction outlines the APIs for a Consumer (Provider) organization to poll the Content Location received as part of Member Attribution List Export Request outlined previously. This polling is required to determine completion status of the export request. This would be repeated until the request is complete or cancelled following the Bulk Data IG specifications.
For example, Multicare would poll the content location received from Cambia as part of the Member Attribution List Export Request.
Preconditions:
API
GET <Content Location from Member Attribution List Export Request>
Expected Results:
AThis interaction outlines the APIs for a Consumer (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.
Precondition:
Consumer has the URLs to retrieve the files representing the Member Attribution List from a successfully completed Member Attribution List Export Request. These URLs are obtained by executing the Member Attribution List Export Request Polling interaction until the request is completed.
API:
GET <File URL for each Resource identified in Member Attribution List Export Request completion response>
Expected Results:
IG © 2019+ HL7 International - Financial Management Work Group. Package hl7.fhir.us.davinci-atr#0.1.0 based on FHIR 4.0.1. Generated 2019-12-24
Links: Table of Contents |
QA Report | Search
| Version History |
|
Propose a change