Medication Dispense (Clinician)

FHIR Requirements for medication dispense information displayed to a clinician.

Constraints on the MedicationDispense resource to reflect source data mappings for the ACCESS Health project. Focus of this profile is on display of medication dispense information to clinician viewers.

This profile was generated from HL7 MedicationDispense StructureDefinition

Sources-To-Date

• Nova Scotia DIS Specification

• New Brunswick DIS Specification

• Newfoundland & Labrador DIS Specification

• Prince Edward Island DIS Specification

Constraints

As part of the scope of the discovery phase of this project, mappings, profiles, and implementation guides were expected to be agnostic with regard to implementation decisions or architectural paradigm.

• It could not be assumed that future implementations will exchange information via a RESTful API.
• Design for how resources could be identified and verified/matched across organizations and jurisdictions fell outside of scope for this phase. Mappings had to be made under the most basic assumption that resources could be referenced on a local server.

This profile is informed by the Drug Information System vendor specifications from all four Atlantic Provinces. While vendor specifications provide helpful insight into system configurations, test messages and documentation on known variances from the CeRX standard are foundational in accessing each jurisdiction's future conformance to the FHIR profile.

Supported CeRX interaction types limitations:

New Brunswick DIS does not currently support query interactions, because of this an alternative CeRX message type (Record Dispense Processing Request) was used for both MedicationRequest and MedicationDispense.

Test message limitations:

Test messages were only available from one DIS (Prince Edward Island).

• Further examination of test and pre-production messages will be critical for validating each jurisdiction’s conformance to the standard, as even slight variation can create errors in extraction and risks in conformance to the profile.

Documented variance limitations:

Only two jurisdictions (Newfoundland Labrador and New Brunswick) called out specific differences from the CeRx standard in their implementations. None of the differences identified by these sources impacted the interactions that were examined for conversion.

• While this might imply that conversion from CeRx to FHIR in Atlantic provinces could be accomplished in a broadly standardized manner across jurisdictions, it is important to note that the absence of noted variances in the other two jurisdictions is not the same as confirmation that variances do not exist.

Note Additional evaluation and iteration of these profiles, as additional jurisdictional specifications are made available, is paramount to ensure the final profile reflects the current state of Atlantic systems.

ACCESS MedicationDispense (Clinician) Profile

ACCESS MedicationDispense (Clinician) Profile

MedicationDispense

MedicationDispense.identifier

MedicationDispense.status

active

MedicationDispense.medication[x]

MedicationDispense.subject

MedicationDispense.performer

MedicationDispense.performer.function

MedicationDispense.performer.actor

MedicationDispense.location

MedicationDispense.authorizingPrescription

MedicationDispense.type

MedicationDispense.quantity

MedicationDispense.daysSupply

MedicationDispense.whenPrepared

MedicationDispense.dosageInstruction

MedicationDispense.dosageInstruction.sequence

MedicationDispense.dosageInstruction.text

MedicationDispense.dosageInstruction.timing

MedicationDispense.dosageInstruction.site

MedicationDispense.dosageInstruction.route

MedicationDispense.dosageInstruction.doseAndRate

MedicationDispense.dosageInstruction.doseAndRate.doseRange

MedicationDispense.dosageInstruction.doseAndRate.rateRatio

MedicationDispense.dosageInstruction.maxDosePerPeriod

MedicationDispense.substitution

MedicationDispense.substitution.wasSubstituted

MedicationDispense.substitution.type

MedicationDispense.substitution.reason

MedicationDispense.substitution.responsibleParty

MedicationDispense.detectedIssue

Example Message:

Command 'pagelink' could not render: Page not found.

Key differences from MedicationDispense Base Resource:

• Removed the following elements from the profile due to lack of available semantically equivalent CeRX fields across examined sites:

  • partOf, statusReason, category, context, supportingInformation, whenHandedOver, destination, receiver, note, and eventHistory

• Flagged the following elements as "Must Support":

  • status, medication, subject, location, quantity, daysSupply, and dosageInstruction

• Changed the cardinality of the following elements:

  • dosageInstruction.text

Key differences from ACCESS MedicationDispense Patient Profile:

Must Support Differences N/A - no cardinality differences between the patient and clinician profile. There was desire to make authorizingPrescription a Must-Support element in the clinician profile- however its data type requirement to reference a FHIR MedicationRequest resource was too restrictive given that there will be prescriptions still received by the DIS in paper form

Optional Field Differences While the must support elements remain the same for both the patient and clinician MedicationDispense profiles, the optional elements and sub-elements supported by each profile are drastically different

The MedicationDispense Clinician profile includes the following optional elements that are not included in the Patient profile:

• performer, performer.function, performer.actor
  • Reviews with SME indicated that the dispensing pharmacy is more likely to be important to patients and dispensing pharmacy is already covered in the location resource.
  • Some jurisdictions outside of the Atlantic provinces (e.g. Saskatchewan) may not capture the name of the pharmacist in the DIS.
• dosageInstruction sub-elements (timing, site, route, doseAndRate.doseRange, doseAndRate.rateRatio, maxDosePerPeriod)
  • These details were included in the clinician profile because of the belief that clinician applications may support better clinical decision support interactions if the dosage instruction information could also be provided as structured data elements.
• substitution.responsibleParty
  • The practitioner responsible for making a substitution is likely not meaningful for citizens but could be used by clinicians for coordination/verification.

The MedicationDispense Patient profile includes an optional element under dosageInstruction (patientInstruction) that the clinician profile does not include.

• Given the focus of these profiles for citizen access, this element was not removed from the patient profile. However, there is no clear mapping distinction between patient instructions and dosage instructions in the CeRX specifications so jurisdictional DIS would need to be evaluated before conversion could begin.

Cardinality Constraint Differences N/A - no cardinality differences between the patient and clinician profile

Data Type Constraint Differences N/A - no data type differences between the patient and clinician profile

Binding Differences N/A - no binding differences between the patient and clinician profile

Key differences from [US Core MedicationDispense R4 Profile]

US Core does not support a profile for MedicationDispense

Key differences from ONC MedicationDispense STU3 Profile

Because there was no US Core equivalent profile for MedicationDispense, the ONC profile for MedicationDispense was used as an international source of comparison.

Must Support Differences

• The ONC profile flags performer and performer.actor as must support elements, these are included as optional in the ACCESS MedicationDispense Clinician profile (not included in the patient profile).
• The ONC profile flags whenHandedOver as a must support element, this are not included in the ACCESS MedicationDispense Patient profiles.
  • SME Note: Jurisdictional DIS support of the CeRX equivalent for whenPrepared & whenHanded over is likely varied. When a DIS does support the CeRX equivalent, it is more likely only record whenPrepared due to existing workflow issues.
• The ACCESS Clinician profile includes location as a Must Support element
  • location was not present in the ONC profile because location is a new element FHIR R4 and the ONC profile is based in STU 3.
• The ACCESS Clinician profile includes quantity and daysSupply as Must Support elements (recommendation of SME), the ONC profile does not.

Cardinality Constraint Differences

The ACCESS profiles intentionally did not introduce cardinality constraints into the medication profiles (see Profiling Principle 4 above).

• The ONC profile created a lower constraint on the cardinality of subject (making it 1..1). Because subject is not readily present in the CeRX Drug Dispense Drug message (PORX_MT060090CA) and instead needs to be inferred from the linked prescription (when it's available). There is no guarantee that the patient information will always be available in the CeRX data source, and therefore the profile could not mirror the cardinality constraint present in the ONC Profile.

Data Type Constraint Differences

• The ONC MedicationDispense profile references the US Core Medication Profile, whereas the ACCESS profile references the CA Core Medication Profile.

Binding Differences

• The ONC profile offers an extensible binding to Rx Norm Medication Codes, while the ACCESS profile suggests a preferred binding to the value set currently proposed in the CA Core Medication profiles (https://fhir.infoway-inforoute.ca/ValueSet/prescriptionmedicinalproduct).

Key differences from Ontario Digital Health Drug Repository STU3 Profile

Because there was no US Core equivalent profile for MedicationDispense, the Ontario Digital Health Drug Repository (DHIR) Profile was used as a Canadian source of comparison.

The ACCESS profile's dependence on HL7v3 CeRX messages as its source data is the primary driver in differences between the DHIR profile and the ACCESS profile. The cardinality restrictions and bindings that DHIR uses are not feasible for application in the ACCESS profiles because conversion of CeRX messages into FHIR creates limitations and boundaries in what data will available and populated consistently.

Must Support Differences

• The DHIR profile flags identifier, identifier.system, and identifier.value as Must Support elements that are not considered Must Support elements in the ACCESS MedicationDispense Clinician Profile
• category, performer, authorizingPrescription, whenHandedOver, detectedIssue are also included as must support elements in the DHIR MedicationDispense Profile that are not flagged as Must Support elements in the ACCESS MedicationDispense Clinician Profile. -The ACCESS Clinician Profile includes location as a Must Support element
  • location was not present in the DHIR profile because location is a new element FHIR R4 and the DHIR profile is based in STU 3.
• The ACCESS Clinician Profile includes dosageInstruction as a Must Support element (recommendation of SME), the DHIR profile does not.

Cardinality Constraint Differences The ACCESS profiles intentionally did not introduce cardinality constraints into the medication profiles (see Profiling Principle 4 above). The DHIR profile includes a number of cardinality differences that the ACCESS profile does not mirror:

• Elements with upper constraint added in DHIR profile: performer (..2), performerOrganization (..1), performerPractitioner (..1), authorizingPrescription (..1)
• Elements with lower constraint added in DHIR profile: codeableConcepts elements (identifier.system, identifier.value, category.system, category.code, category.display), medicationReference, subject, subjectReference, quantity, quantity.value, daysSupply.value, whenHandedOver
• Elements with both upper and lower constraints added in DHIR profile: identifier, category.coding

Data Type Constraint Differences

• DHIR constrains the medication data type to only include medicationReference (medicationCodeableConcept removed), the ACCESS profile allows for medicationReference and medicationCodeableConcept to cover any situations where only the coded information is known (medicationReference is kept for situations where a compound is used)
• DHIR uses a specific Patient Dispense resource for subject, while the ACCESS profile references the CA Core Patient Profile which does not distinguish between what interaction the patient is being referenced in. -DHIR references its own MedicationRequest Profile, ACCESS references its own MedicationRequest Clinician Profile (MedicationRequest Patient Profile is referenced in the patient-focused dispense profile).
• DHIR references its own profiles for DetectedIssue: DURIntervention, DURResponse, DURTextMessageHNSODB, DURTextMessageNMS, ACCESS references the DetectedIssue Base Resource.

Binding Differences

• The DHIR profile requires a binding to the eHealth Ontario MedicationDispenseStatus subset of the STU3 MedicationDispense Status value set, while the ACCESS profile requires the R4 medicationDispense status value set.
• DispenseCategory is used as a preferred binding in the DHIR profile to help distinguish between drugs, devices, and professionals, ACCESS does not include MedicationDispense category because device dispenses and medicationAdministration were considered out of scope of Phase B.
• The ACCESS profile supports an extensible binding for MedicationDispense.type (ActPharmacySupplyType which is a v3 value set), however, type is not included in the DHIR profiles
• The ACCESS profile supports preferred bindings for substitution type (V3 Value SetActSubstanceAdminSubstitutionCode) and substitution reason (V3 Value SetSubstanceAdminSubstitutionReason) however type is not included in the DHIR profiles