This page is part of the Da Vinci Patient Cost Transparency Implementation Guide (v1.1.0: STU 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Formal Specification

Page standards status: Informative

This section of the implementation guide (IG) defines the specific conformance requirements for systems wishing to conform to this Patient Cost Transparency (PCT) IG. The bulk of it focuses on Good Faith Estimate (GFE) submission $gfe-submit and an Advanced Explanation of Benefits (AEOB) query, though it also provides guidance on privacy, security, and other implementation requirements.

Context

Pre-reading

Before reading this formal specification, implementers should first familiarize themselves with two other key portions of the specification:

• The Use Case page provides context for the intent and general process flow of this formal specification.

• The Technical Background and Underlying Technologies page provides information about the underlying specifications and indicates what portions should be read and understood to have the necessary foundation for the constraints and usage guidance described here.

Conventions

This implementation guide (IG) 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 are not a recommendation for or against adoption.

Must Support

The following rules regarding Must Support elements apply to all Profiles in this guide. The Must Support definitions are not inherited from other IGs, even for profiles in this guide derived from another guide.

Sender:

• The sender SHALL send the data element if the sender maintains the data element and is authorized to share it.

  • Data elements that the sender maintains includes data elements available in the systems under the sender’s control.

  • If the sender does not capture/store the data, the data are not available, or sharing of the data is not authorized, the system SHOULD NOT send the element if the element is not marked as mandatory (lower cardinality of 0).

Receiver:

• The receiver SHALL be capable of processing resource instances containing must-support data elements without generating an error or causing the application to fail.
• The receiver SHOULD be capable of displaying must support data elements for human use.
• The receiver SHALL be able to process resource instances containing must-support data elements asserting missing information (data absent reason extension).

This guide uses technical actors to define Must Support conformance requirements.

Profiles

This specification makes significant use of FHIR profiles and terminology artifacts to describe the content to be shared as part of AEOB requests and responses.

The full set of profiles defined in this IG can be found by following the links on the Artifacts page.

Detailed Requirements

Summary

FHIR uses a pair of resources called Claim and EOB for multiple purposes - they are used for actual claim submission, but they are also used for managing prior authorizations and pre-determinations. These uses are distinguished by the Claim.use and ExplanationOfBenefit.use code. This guide requires predetermination for both Claim.use and ExplanationOfBenefits.use. All references to Claim and EOB in this IG are referring to the AEOB.

Submitting a GFE and Polling for an AEOB

The primary interaction supported by this IG is submitting a GFE and receiving an AEOB in response. To perform this, a GFE Bundle resource is constructed by the client (e.g., Billing Management Software) system. The response is an AEOB Bundle.

The GFE Bundle will be sent as the sole payload of a $gfe-submit operation, which is based on the Asynchronous Interaction Request Pattern (please refer to that page for more details). Note: that page is part of the FHIR R5 current build, but uses no R5 resources; this guide is pre-adopting that HTTP request pattern. The response will be a URL in the Content-Location header for subsequent polling.

AEOBs will often not be complete and the calling client (or other interested systems - e.g., patient or convening provider system) will need to periodically poll the payer server to determine the status of the gfe-submit operation. Polling can generate the following responses:

• If the response is in-progress, this request will return an HTTP status code of 202 Accepted, indicating that the provider should poll again later. The payer system should return a Retry-After header with each in-progress polling response, and the client should use this information to inform the timing of the next polling request.
• If the response is an error, this request will return an HTTP status code of 4XX or 5XX, and the body of the response will be an OperationOutcome detailing the error.
• If the response is successful, this request will return an HTTP status code of 200 OK, and the body of the request will be a Bundle resource of type batch-response. This batch-response bundle SHOULD contain the completed AEOB Bundle and MAY contain one or more OperationOutcome resources with additional information regarding GFE/AOEB processing. If the batch-response Bundle does not contain an AEOB Bundle, then it SHALL contain at least one OperationOutcome resource detailing the reason why the AEOB Bundle is not present (e.g., the AEOB was sent directly to the patient and will not be returned to the provider).

Patient Access to AEOBs

Note: Although technically possible, conveying the AEOB to the patient via FHIR API is optional and the workflow is contingent upon the payer opting to expose the API to the patient. The payer must return the completed AEOB to the patient, but this may be done in many ways such as via mail, the payer benefits portal, or via an API. The only method in scope for this guide is the FHIR-based API approach inspired by the Patient Access API defined in the CARIN Consumer Directed Payer Data Exchange guide. Note that use of an API is optional for the payer, and if the payer does implement both this API and the Patient Access API defined in the CARIN IG, it is up to the payer to determine if those APIs use the same or different endpoints.

If the payer system supports access via an API, then a third-party app used by the patient authorizes/authenticates and receives an access token. The app requests the AEOB by using the access token using a GET request for ExplanationOfBenefit resources in the patient’s compartment. For example, GET [base]/ExplanationOfBenefit?patient=[patient-id]. Payer systems SHALL implement appropriate access controls to ensure that AEOBs are only accessible by the authenticated patient.

• If successful, the system will return 200 OK, and the body will contain a Bundle resource of type searchset, containing zero or more ExplanationOfBenefit resources. Once the desired AEOB is found, the third-party app may use the same API to query for other resources referenced by the AEOB, such as Patient, Practitioner, Organization, and Coverage resources if those referenced resources are not contained in the AEOB itself. Third-party apps should keep track of prior AEOBs and alert the patient if new ones are found. New AEOBs would have a different identifier and a created date later than previous AEOBs.

GFE and AEOB Bundle Graphics

Figure 1 shows the components of the GFE and AEOB bundles. For full details, see the PCT FHIR Artifacts. Note: For brevity, not all bundle data elements are shown below.

Figure 1: GFE Bundles

Note: All resources (supporting info, etc.) needed to process the GFE and produce the AEOB SHALL be included in the GFE Bundle. Relevant resources referenced by such resources SHALL also be included.

Figure 2: AEOB Bundle

Note: The AEOB bundle SHALL contain one or more AEOBs. Each AEOB SHALL contain a reference to the original GFE bundle (i.e., and exact copy of the originally submitted GFE).

AEOB Request

The $gfe-submit operation is executed by POSTing a GFE FHIR Bundle to the $gfe-submit endpoint. The server SHALL support JSON encoding and MAY support XML. The GFE FHIR Bundle will include one or more GFE resources for one patient. The GFE profiles used for the claim resources can be found here. Additional Bundle entries SHALL be populated with any resources referenced by the GFE resource (and any resources referenced by those resources, fully traversing all references, and complying with all identified profiles). Note that even if a given resource instance is referenced multiple times, it SHALL only appear in the Bundle once, e.g., if the same Practitioner information is referenced in multiple places, only one Practitioner instance is created - referenced from multiple places as appropriate.

Bundle.entry.fullUrl values SHALL be one of the following: • the URL at which the resource is available from the Billing Management System if exposed via the client’s REST interface • in the form “urn:uuid:[some guid]”

All GUIDs used SHALL be unique, including across independent GFE submissions - with the exception that the same resource instance being referenced in distinct AEOB request Bundles can have the same GUID.

In addition to these core elements, any “supporting information” resources needed to process the AEOB request must also be included in the Bundle. Relevant resources referenced by those “supporting information” resources SHALL also be included. Any such resource that has a US Core profile SHALL comply with the relevant US Core profiles. All “supporting information” resources included in the Bundle SHALL be pointed to by the GFE resource using the GFE.supportingInfo.valueReference element.

Whenever possible, the AEOB should default to elements in the GFE (i.e., not include/repeat) unless there is a business reason to do so to reduce complexity for app developers or for patient clarifications. This is why many elements in the GFE profiles are not repeated in the AEOB profiles, since the original GFE SHALL be referenced from the AEOB.

To attach PDFs, CDAs, JPGs, a DocumentReference instance should be used. The GFE.supportingInfo.sequence for each entry SHALL be unique within the GFE.

All resources SHALL comply with their respective profiles. FHIR elements not required (minimum cardinality of 1) or marked as “must support” MAY be included in resources within the Bundle, but client systems should have no expectation of such elements being processed by the payer unless prior arrangements have been made. Systems that do not process such elements SHALL ignore unsupported elements unless they are “modifier” elements, in which case the system MAY treat the presence of the element as an error.

This IG treats everything that happens beyond the defined operations endpoint receiving the FHIR bundle as a black box. This black box includes any business associates, clearinghouses, payers, contracted review entities, and other intermediaries that may be involved in the AEOB request and response. The black box ensures that any other requirements are met and to perform all processing within the allowed timeframe.

AEOB Response

Just like the AEOB request, additional Bundle entries must be present for all resources referenced by the AEOB response or descendent references. When converting additional Bundle entries, the conversion process SHALL ensure that only one resource is created for a given combination of content, e.g., if the same Practitioner information is referenced in multiple places, only one Practitioner instance should be created - referenced from multiple places as appropriate. When echoing back resources that are in the AEOB request, the system SHALL ensure that the same fullUrl and resource identifiers are used in the response as appeared in the request.

It is possible that the incoming Bundle cannot be processed due to validation errors or other non-business-errors. In these instances, the receiving system SHALL return OperationOutcome instances that detail why the Bundle could not be processed and no AEOB response will be returned.

AEOB Request / Response example

Example bundles can be found here