MyHealth@Eu NCPeH API - Local Development build (v10.0.0-ci) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Prescribed item Retrieval

This page describes the implementation options of the Prescribed item Retrieval task.

Business View

The overall business scenarios associated to this task are described in the Business view page.

Application View

The implementation-independent sequence diagrams associated to this task are described in the Application view page.

The context: HL7 CDA to FHIR-based service migration

Cross-border ePrescription/eDispensation exchange is currently managed through a CDA-based approach, using a query-and-retrieve pattern for ePrescription and a notification mechanism for eDispensation.

Moving the service to HL7 FHIR, a proper workflow control can be realized by using the MedicationRequest resource.

However, the solution is expected to continue supporting the same functional approach. allowing for prescription (items) search, and retrieval of the complete set of information for the selected prescribed items.

The solution should also not prevent future evolution towards more explicit subscription-based mechanisms. For example, in a future scenario, when a prescription is issued in Country B, this event could be notified back to Country A using a real subscription or event notification mechanism.

Pre-conditions

The MyHealth@EU general architecture requires that no assumptions are made on the way the service is implemented at the national level.

This implies that any solution adopted for the NCPeH to NCPeH communications has to work properly independently from the fact that a HL7 FHIR server, a national ePrescription repository, or any other national solution is locally adopted.

Country A's prescription system should acts as an implicit subscription provider for a MedicationRequest-based prescription availability topic.

When a prescribed item is issued or updated, the system prepares a Bundle containing the MedicationRequest and the supporting resources needed to represent and process that request.

This Bundle of type collection is used to group the MedicationRequest and the supporting resources needed for prescription processing. It realizes the concept of a subscription-notification Bundle, even if it is not exchanged as part of an explicit event notification workflow. It doesn't require therefore the additional subscription-related parameters that are not useful in this implicit scenario. A more unified subscription-based approach can be considered later, either when the solution moves to a FHIR version where the subscription framework is more mature for this use case, such as FHIR R6, or if the architecture evolves towards the use of real explicit FHIR Subscriptions.

To enable the receiving system to retrieve the complete Bundle after discovering or receiving the MedicationRequest.identifier, the Bundle.identifier shall be equal to the business identifier of the MedicationRequest.

The subscription aspect is implicit because Country B does not create or manage an explicit FHIR Subscription resource. Instead, Country A prepares and exposes the collection Bundle according to predefined business rules and architectural agreements.

Implementation

The prescription search and retrieval mechanism permits realizing the Prescribed item Retrieval process described in the Application view.

In the following diagram the requesting NCP searches available prescribed items and retrieves the overall information for the selected ones.

In summary:

• The Requesting NCP searches for available prescribed items for an identified patient.
• The Responding NCP returns the associated minimal data.
• The Requestor selects an item.
• The Requesting NCP retrieves the collection Bundle associated with the selected item.

Scenario

Query and retrieval

Country B queries Country A for available MedicationRequest resources.

The returned list of prescribed items is presented to the user.

For each prescribed item selected, Country B uses the MedicationRequest.identifier to retrieve the corresponding collection Bundle.

Step-by-Step Breakdown: MedicationRequest Search

eHDSI MedicationRequest Search Request

The Requesting NCP initiates a search query for available prescriptions using the FHIR API call:

GET $server/MedicationRequest?<searchParameters><modifiers>

The query includes search parameters and modifiers to refine the search criteria.

Search Parameters

Common

eHDSI MedicationRequest Search Response

The Responding NCP returns a FHIR Bundle containing the search results.

The bundle contains entries of type MedicationRequest representing available prescriptions or prescribed items.

Bundle.where(type='searchset').entry.resource.ofType(MedicationRequest)

Each returned entry provides the minimal data needed to allow the Requestor to select the prescribed item to retrieve. The MedicationRequest.identifier identifies the collection Bundle that contains the complete set of information needed to represent and process the selected prescribed item.

Search HTTP Error Response Codes

Examples

All active prescriptions of the Czech patient 456789123.

GET $server/MedicationRequest?patient.identifier=https://ncez.mzcr.cz/standards/fhir/sid/rid|456789123&status=active

All prescriptions of the Czech patient 456789123 authored from 2024, January 1st.

GET $server/MedicationRequest?patient.identifier=https://ncez.mzcr.cz/standards/fhir/sid/rid|456789123&authoredon=ge2024-01-01

Step-by-Step Breakdown: Prescribed item Retrieval

MedicationRequest Selected

The Requestor selects one prescribed item from the prescription minimal data returned by the search response.

Read MedicationRequest.identifier

The Requesting NCP retrieves the selected prescribed item information using a valid FHIR API URL in the form:

$server/Bundle/id

The retrieved Bundle is a Bundle of type collection that groups the MedicationRequest and the supporting resources needed to represent and process the prescribed item.

The Bundle can be identified through the business identifier discovered in the search phase.

The following rule applies:

1. Bundle.identifier shall be equal to the business identifier of the corresponding MedicationRequest.

eHDSI Get Bundle by Identifier Request

If the selected prescription is represented by a collection Bundle, the system retrieves it using a FHIR Bundle search by identifier request:

GET $server/Bundle?identifier=[system]|[value]

The Requesting NCP sends a request to the Responding NCP for the Bundle.

eHDSI Get Bundle by Identifier Response

Since the request is a search, the Responding NCP returns a searchset Bundle containing the matching collection Bundle(s):

Bundle.where(type='searchset').entry.resource.ofType(Bundle)

Per precondition (3) above, only one current logical collection Bundle SHALL exist for a given MedicationRequest business identifier, so the following cases apply:

• One match: the searchset contains a single entry, the selected collection Bundle. This is the expected outcome.
• No match: the searchset contains zero entries. This may occur if the collection Bundle is no longer available (see error response codes below).
• More than one match: the searchset contains more than one entry. This indicates a violation of precondition (3) and SHOULD be treated as an error condition by the Requesting NCP.

Prescription Retrieval HTTP Error Response Codes

Examples

Retrieval of the collection Bundle associated with a selected MedicationRequest business identifier.

GET $server/Bundle?identifier=https://ncez.mzcr.cz/standards/fhir/sid/prescription|RX-12345

Implementation alternatives

The Prescribed item Retrieval task is realized by searching the prescriptions available for an identified patient and retrieving the selected prescribed item information.

In this first version, this will be realized by searching HL7 FHIR resources representing prescribed items and retrieving a prepared collection Bundle for each selected prescribed item.

For HL7 FHIR R4, prescriptions are represented by MedicationRequest resources. MedicationRequest search is suitable for the query part, while retrieval of the complete prescribed item details in a cross-border scenario requires further analysis.

It does not seem appropriate for the receiving system to retrieve each referenced resource individually.

It also does not seem sufficiently robust to rely on _include=* or _revinclude=*, possibly with the :iterate modifier, because the behavior of responding systems may not be uniform.

A more reliable approach is therefore to prepare a collection Bundle that groups the MedicationRequest and the supporting resources needed to represent and process the prescribed item.

This Bundle can then be retrieved once the prescribed item has been discovered or selected.

Open points to be further assessed

The FHIR R5 Subscription Backport Implementation Guide does not appear to be actively maintained as a stable reference for this use case. The current published release is still from 2023, while later material appears to be available only as ballot or continuous-build content. It is therefore not yet clear how reliable it is as a reference source for the implicit prescription retrieval pattern described here.

The R4 backport approach appears to require the first Bundle entry to contain parameters that simulate the role of the newer SubscriptionStatus resource. This should be assessed carefully, because SubscriptionStatus includes a mandatory reference to a Subscription resource. Such a reference may not be appropriate or necessary in an implicit subscription scenario, where no explicit FHIR Subscription resource is created or managed by Country B. Similar considerations may apply to other parameters listed in the backport specification.

The available FHIR subscription specifications are useful as conceptual references, but they do not directly define the implicit subscription pattern described here. In particular, the standard FHIR subscription-notification model assumes an explicit Subscription and uses SubscriptionStatus to convey metadata about that Subscription. This does not fully match the proposed implicit cross-border pattern, where the event relationship is established by policy and architecture rather than by a FHIR Subscription resource created by the receiving country.

It is still to be assessed whether retrieval of a multi-item prescription as a Bundle should be enabled.