Consumer Real-Time Pharmacy Benefit Check FHIR IG
2.0.0-ballot - STU 2 Ballot United States of America flag

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

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

IdExpectationRule
 SHALL
 SHOULD
 MAY
§BR-1SHALLWhen 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-1SHALLAn RTPBC Requester SHALL support at least one use case defined in this Guide and listed in the Use Cases section.
§CS-REQ-2SHALLAn RTPBC Requester SHALL implement the RESTful behavior according to the HL7 FHIR specification.
§CS-REQ-3SHALLAn RTPBC Requester SHALL support the JSON source format.
§CS-REQ-4SHOULDAn RTPBC Requester SHOULD support the XML source format.
§CS-REQ-5SHOULDAn RTPBC Requester SHOULD identify the RTPBC profiles supported as part of the FHIR meta.profile attribute for each instance.
§CS-RES-1SHALLAn RTPBC Responder SHALL support the $process-message operation
§CS-RES-2SHALLAn RTPBC Responder SHALL support at least one use case defined in this Guide and listed in the Use Cases section.
§CS-RES-3SHALLAn RTPBC Responder SHALL implement the RESTful behavior according to the HL7 FHIR specification.
§CS-RES-4SHALLAn RTPBC Responder SHALL support the JSON source format.
§CS-RES-5SHALLAn RTPBC Responder SHALL provide on the server a CapabilityStatement identifying the profiles supported.
§CS-RES-6SHOULDAn RTPBC Responder SHOULD support the XML source format.
§CS-RES-7SHOULDAn RTPBC Responder SHOULD identify the RTPBC profiles supported as part of the FHIR meta.profile attribute for each instance.
§MS-CLM-1MAYThe preferredPharmacyPostalCode extension MAY be repeated to specify multiple postal codes.
§MS-CLM-2SHALLAn RTPBC Responder SHALL consider all preferredPharmacyPostalCode values submitted in a request.
§MS-COV-1SHALLThe 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-1SHOULDRTPBC Responders SHOULD return pricing and coverage information for relevant drug/pharmacy alternatives, in the ClaimResponse.addItem composite.
§MS-CR-2SHALLEvery RTPBC response ClaimResponse SHALL contain either an item composite or an error composite, but not both.
§MS-CR-3SHALLThe RTPBC response ClaimResponse.iItem composite SHALL be populated when sufficient information is received to be able to answer the request.
§MS-CR-4SHALLThe 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-5SHALLThe 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-6MAYThe 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-7SHALLThe RTPBC Responder SHALL ensure that content in Must Support ClaimResponse elements is accurate and complete.
§MS-CR-8SHALLRTPBC 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-1SHALLAll MedicationRequest elements with a minimum cardinality of 1 SHALL be populated in order to enable reliable results from the processor.
§MS-MR-2SHOULDMedicationRequest.dosageInstruction SHOULD be used when determining days supply.
§MS-MR-3MAYDays 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-4SHALLRTPBC Responders SHALL make use of all pertinent required MedicationRequest elements when determining pricing and coverage.
§MS-MR-5MAYRTPBC Responders MAY use MedicationRequest.dosageInstruction when determining pricing and coverage.
§MS-PH-1SHALLThe 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-2SHOULDPharmacy 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-3SHALLRTPBC Responders SHALL consider pharmacy type and location when determining pricing, coverage, and alternative pharmacy options
§MS-RB-1SHALLAll 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-2SHALLWhen submitting to an insurer, the Coverage resource SHALL also be populated.
§MS-RB-3SHALLRTPBC Responders that are insurers SHALL consider all information submitted in Must Support elements when determining cost and coverage.
§MS-RB-4SHOULDRTPBC Responders that are not insurers SHOULD use all applicable submitted information when determining responses.
§OP-1SHALLIn 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-2SHOULDValues SHOULD be taken from the set of RTPBC error codes as defined in the RTPBC Error Code Value Set.
§OP-3SHALLIn the event of a system or communication error, RTPBC source systems (payer/PBM, discount pricing source) SHALL respond by providing an OperationOutcome resource.
§OP-4SHALLOperationOutcomes SHALL contain a definition of severity in the OperationOutcome.issue.severity field providing a value from the valueset-issue-severity value set.
§OP-5SHALLOperationOutcomes 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-6SHALLOperationOutcomes SHALL contain details of the error in the .issue.details.coding.code and .issue.details.coding.display fields.
§OP-7SHOULDOperationOutcomes SHOULD provide additional diagnostic details of the error in OperationOutcome.diagnostics property.
§PHI-CLM-1SHALLTo 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-2SHALLThe 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-1SHALLTo 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-1SHOULDThe 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-2SHOULDInteractions with RTPBC data sources that supply non-patient-specific information such as discount pricing SHOULD support SMART Backend Services.
§SEC-3SHALLRTPBC 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.