SFM Basis API Implementation Guide

Bundle description

NOTE: A change of cardinality for sfm-Pllinfo is made. The cardinality for pllInfo is exteded from 0..1 to 0..3 as there was a need for separate representation of fields for e-multidose. The change is backwards compatible in the sense of using the new profile version will not break the parsing of 2.X versions of SFM. For versions 3.X an later in production there will be a breaking change in parsing and interpretion of the composition.

As FHIR currently does not have a concept corresponding to the Pasientens Legemiddelliste (PLL) the main communication element for prescriptions / medicationStatements is based on a Bundle of type document, with a structured Composition as the first entry. This composition has sections for the main elements in information from Reseptformidleren and Kjernejournal. The same structure is used for posting/updating Reseptformidleren with changes.

Operations for retrieval from and submission on prescriptions to national systems is based on a BundleType= document with contained resources. This implies that the first resource is a Composition: in this case a profile tailored for communication of the Norwegian PLL and prescription info:

Profile on Bundle to hold medication and prescription data in and out of API Basis: sfm-MedicationBundle

Profile on Composition to define the structure of data in and out of API Basis: sfm-MedicationComposition

These use of profiles on Bundle:document and Composition is inspired by the International Patient Summary (IPS) profiling.

This bundle will encompass all prescriptions and known dispenses, as well as the structured PLL info. The MedicationStatement entries will have ID's the links them to prescriptions and/or the PLL registrations.

sfm-MedicationStatement:ID is sliced with three types of ID:

• PLL-id
• prescriptionID
• treatmentID

The presence of a PLL-id identifies the Medication statement as part of the PLL. The presence of a prescriptionID identifies the Medication treatment as an electronic prescription, defining the ID of the M1 Resept message. If no prescriptionID is present, it typically represents an entry in PLL for an OTC medication- If no PLL-id is present, it typically is a prescription made by a system with no support for PLL or from a practitioner that is not a physician.

NOTE: Until PLL is widely introduced, there will generally not be a PLL, and no PLL-id's unless the patient is treated under the multidose scheme

For special use, the parameter "includeOriginal" has been provided to allow for inclusion of (part of) the original message on which a sfm-MedicationStatement is based. The MedicationStatement.derivedFrom will then be a reference to a Binary resource in the bundle containing original info. The "id" of the binary resource will be popultated after this rule:

• when picked from M25: EnkeltoppforingLib.Id (prefered)
• when picked from M1: MsgHead.MsgId
• when picked from M8.1: MsgHead.MsgId

When submitting the bundle for changes/renewals/withdrawals, the individual items will contain information making it possible for SFM to perform the necessary operations to Reseptformidleren, including sending signed M1 Resept, M5 Tilbakekalling and M25.1 PLL

Prescriptions that are obsolete (not Head of Chain - eg. being partOf another prescription) are not required in the bundle for $sendMedicaiton operation. All Head of chain prescriptions shall be returned for consistency check.

Examples

Example: A bundle returned from $getMedication without PLL info:

Example: A bundle submitted with $sendMedication with one recalled prescription

Attester (practitioner and organization) is listed an must correspond with information in access token

Example: A bundle submitted with $sendMedication with one renewed prescription

Renew is a function in "M5" recall, where the recall points to the new prescription

Example: A bundle submitted with $sendMedication with one recalled prescription and one new prescription

Both recalled and new sfm-Medication statement must be present in the list in this case.

Example: A bundle submitted with $sendMedication with PLL, one recalled prescription and one new prescription

Same as above, but with PLL as well. The PLL will not contain the recalled prescription. (For e-multidose there is special rules)

Example: A bundle submitted with $sendMedication with PLL=false, one recalled prescription and one new prescription

In this case the practitioner has decided to not send the PLL, but the list must be submitted consistently for check. The PLL concept specification will maintain rules for when to use this scenario.