Consumer Real-Time Pharmacy Benefit Check FHIR IG
2.0.0-ballot - STU 2 Ballot

Consumer Real-Time Pharmacy Benefit Check FHIR IG, published by HL7 International / Pharmacy. 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/carin-rtpbc/ and changes regularly. See the Directory of published versions

## Conformance

Page standards status: Informative | Highlight text changes?

### Systems

This implementation guide defines the responsibilities of two types of systems involved in a Consumer Real-Time Pharmacy Benefit Check interaction:

An RTPBC Requester is a consumer-facing client applications that enables the user to retrieve and view information related to their medications from their insurer, drug discount sources and/or other related data sources.

An RTPBC Responder is an insurer or data source that returns information in response to RTPBC requests.

### Conformance Terms

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 ought to be adhered to to avoid suboptimal interoperability 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 there is no recommendation for or against adoption.

### Must Support

Profiles in this implementation guide make use of the mustSupport element. Base expectations for interpretation of these terms are set in the FHIR core specification. Also see the mustSupport rules in the US Core implementation guide, which apply to content in this IG which is based on US Core profiles.

In addition, profile element-specific interpretations are included in the associated profile page in this IG.

### Conformance Statements in this Guide

Id | Expectation | Rule
--- | --- | ---
| SHALL SHOULD MAY |
§BR-1 | SHALL | When a party that has implemented the responder role of this implementation guide and can also respond to the provider-focused NCPDP Real-time Prescription Benefit (RTPB) transaction, it SHALL ensure that it returns consistent values for information that is common between the two standards.
§CS-REQ-1 | SHALL | An RTPBC Requester SHALL support at least one use case defined in this Guide and listed in the Use Cases section.
§CS-REQ-2 | SHALL | An RTPBC Requester SHALL implement the RESTful behavior according to the HL7 FHIR specification.
§CS-REQ-3 | SHALL | An RTPBC Requester SHALL support the JSON source format.
§CS-REQ-4 | SHOULD | An RTPBC Requester SHOULD support the XML source format.
§CS-REQ-5 | SHOULD | An RTPBC Requester SHOULD identify the RTPBC profiles supported as part of the FHIR `meta.profile` attribute for each instance.
§CS-RES-1 | SHALL | An RTPBC Responder SHALL support the $process-message operation
§CS-RES-2 | SHALL | An RTPBC Responder SHALL support at least one use case defined in this Guide and listed in the Use Cases section.
§CS-RES-3 | SHALL | An RTPBC Responder SHALL implement the RESTful behavior according to the HL7 FHIR specification.
§CS-RES-4 | SHALL | An RTPBC Responder SHALL support the JSON source format.
§CS-RES-5 | SHALL | An RTPBC Responder SHALL provide on the server a CapabilityStatement identifying the profiles supported.
§CS-RES-6 | SHOULD | An RTPBC Responder SHOULD support the XML source format.
§CS-RES-7 | SHOULD | An RTPBC Responder SHOULD identify the RTPBC profiles supported as part of the FHIR `meta.profile` attribute for each instance.
§MS-CLM-1 | MAY | The preferredPharmacyPostalCode extension MAY be repeated to specify multiple postal codes.
§MS-CLM-2 | SHALL | An RTPBC Responder SHALL consider all preferredPharmacyPostalCode values submitted in a request.
§MS-COV-1 | SHALL | The Coverage elements identified as Must Support are the typical set used in US pharmacy benefit processing; client systems SHALL enable these to be submitted in requests, and responders SHALL be able to accept them to be used as appropriate during processing.
§MS-CR-1 | SHOULD | RTPBC Responders SHOULD return pricing and coverage information for relevant drug/pharmacy alternatives, in the ClaimResponse.addItem composite.
§MS-CR-2 | SHALL | Every RTPBC response ClaimResponse SHALL contain either an item composite or an error composite, but not both.
§MS-CR-3 | SHALL | The RTPBC response ClaimResponse.iItem composite SHALL be populated when sufficient information is received to be able to answer the request.
§MS-CR-4 | SHALL | The RTPBC response ClaimResponse.error composite SHALL be populated when the responder cannot complete processing due to insufficient or invalid information in the request.
§MS-CR-5 | SHALL | The benefitRestrictions extension is a conditional element that SHALL be populated in an RTPBC response ClaimResponse when the responder is an insurer (or other processor representing the patient's pharmacy benefit). It is not expected to be populated when the responder is a medication pricing source.
§MS-CR-6 | MAY | The RTPBC response ClaimResponse.processNote element is a conditional element that MAY be populated when the responder has additional information about costs or coverage related to an .item or .addItem.
§MS-CR-7 | SHALL | The RTPBC Responder SHALL ensure that content in Must Support ClaimResponse elements is accurate and complete.
§MS-CR-8 | SHALL | RTPBC Requesters SHALL be able to interpret and convey to users all cost and coverage information returned in an RTPBC response, as appropriate to the application.
§MS-MR-1 | SHALL | All MedicationRequest elements with a minimum cardinality of 1 SHALL be populated in order to enable reliable results from the processor.
§MS-MR-2 | SHOULD | MedicationRequest.dosageInstruction SHOULD be used when determining days supply.
§MS-MR-3 | MAY | Days supply (MedicationRequest.expectedSupplyDuration) can impact cost and coverage for a medication; however, patients may not be able to reliably provide it. Implementing partners MAY determine how or whether the element is to be used.
§MS-MR-4 | SHALL | RTPBC Responders SHALL make use of all pertinent required MedicationRequest elements when determining pricing and coverage.
§MS-MR-5 | MAY | RTPBC Responders MAY use MedicationRequest.dosageInstruction when determining pricing and coverage.
§MS-PH-1 | SHALL | The pharmacy Organization.identifier and Organization.name SHALL be populated with correct information in order for the processor to determine reliable cost and coverage information.
§MS-PH-2 | SHOULD | Pharmacy phone (Organization.telecom.work) and address SHOULD be populated to assist in identifying a particular pharmacy location, especially when identifying the pharmacy using an NPI.
§MS-PH-3 | SHALL | RTPBC Responders SHALL consider pharmacy type and location when determining pricing, coverage, and alternative pharmacy options
§MS-RB-1 | SHALL | All RTPBC Request Bundle elements designated as Must Support SHALL be populated with correct and complete information in order to elicit reliable information in the RTPBC response.
§MS-RB-2 | SHALL | When submitting to an insurer, the Coverage resource SHALL also be populated.
§MS-RB-3 | SHALL | RTPBC Responders that are insurers SHALL consider all information submitted in Must Support elements when determining cost and coverage.
§MS-RB-4 | SHOULD | RTPBC Responders that are not insurers SHOULD use all applicable submitted information when determining responses.
§OP-1 | SHALL | In the event that the RTPBC source system (payer/PBM, discount pricing source) is unable to fully process a request because of data or business rule issue, that system SHALL respond by populating the .error composite in the ClaimResponse resource.
§OP-2 | SHOULD | Values SHOULD be taken from the set of RTPBC error codes as defined in the RTPBC Error Code Value Set.
§OP-3 | SHALL | In the event of a system or communication error, RTPBC source systems (payer/PBM, discount pricing source) SHALL respond by providing an OperationOutcome resource.
§OP-4 | SHALL | OperationOutcomes SHALL contain a definition of severity in the OperationOutcome.issue.severity field providing a value from the valueset-issue-severity value set.
§OP-5 | SHALL | OperationOutcomes SHALL contain a definition of the type of error in the OperationOutcome.issue.code element, providing a value from the issue-type value set.
§OP-6 | SHALL | OperationOutcomes SHALL contain details of the error in the .issue.details.coding.code and .issue.details.coding.display fields.
§OP-7 | SHOULD | OperationOutcomes SHOULD provide additional diagnostic details of the error in OperationOutcome.diagnostics property.
§PHI-CLM-1 | SHALL | To conform with the Non-PHI Coverage profile, the Data Absent Reason extension SHALL be used in the Claim.patient and Claim.insurance.coverage elements, populated with the code, "masked".
§PHI-CLM-2 | SHALL | The patient.identifier element in this profile is available to be populated but SHALL contain only non-personally-identifiable codes, such as an account or user ID assigned during an anonymous interaction with the server.
§PHI-COV-1 | SHALL | To conform with the Non-PHI Coverage profile, the Data Absent Reason extension SHALL be used in the Coverage.beneficiary element, populated with the code, "masked".
§SEC-1 | SHOULD | The following SMART on FHIR Capability Sets SHOULD be supported when retrieving from RTPBC data sources that return patient-specific information–such as an insurer system that returns responses containing a member's benefit balances and coverage information.
§SEC-2 | SHOULD | Interactions with RTPBC data sources that supply non-patient-specific information such as discount pricing SHOULD support SMART Backend Services.
§SEC-3 | SHALL | RTPBC data sources SHALL support token introspection defined by the SMART App Launch Guide. For more details and additional consideration, see SMART App Launch's Token Introspection.