Patient Cost Transparency Implementation Guide, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pct/ and changes regularly. See the Directory of published versions

Formal Specification

Page standards status: Trial-use

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.

Workflow Specific Specifications

Additional Specifications for the two workflows in this guide can be found on the following pages:

• GFE Coordination Specification - Requirements to support the ability for a provider to request and collect one or more GFEs from other providers that may participate in a set of procedures related to patient’s period of care for which a GFE is required, either to provide to the patient and/or to submit to a payer.

• GFE Submission and AEOB Specification - Requirements to supports the ability for a provider to submit a collection of one or more GFEs to a payer for them to process and produce an AEOB bundle to the patient and optionally to the provider.