ACCESS Gateway EHR Specification HL7 FHIR® Implementation Guide-v1.0.0-WIP-draft

Medication Statement (Clinician) Profile

FHIR Requirements for medication statement information displayed to a clinician.

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

This profile was generated from HL7 MedicationStatement 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. No alternative CeRX message type could be found for New Brunswick that supported Medication Profile/Statement information, so New Brunswick mappings were excluded from this profile.

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 MedicationStatement (Clinician) Profile

ACCESS MedicationStatement (Clinician) Profile

identifierIdentifier
statusScodeBinding
medicationCodeableConceptCodeableConcept
medicationReferenceReference(http://hl7.org/fhir/ca/core/StructureDefinition/profile-medication)
subjectSReference(http://hl7.org/fhir/ca/core/StructureDefinition/profile-patient)
effectiveDateTimedateTime
effectivePeriodPeriod
dateAssertedSdateTime
informationSourceSReference(Patient | Practitioner | PractitionerRole | RelatedPerson | Organization)
codecode
displaystring
systemuri
textstring
dosageDosage

Key differences from MedicationStatement Base Resource:

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

    • basedOn, partOf, statusReason, category, context, derivedFrom, reasonReference, and note

  • Flagged the following elements as "Must Support":

    • status, medication, subject, effective, dateAsserted, informationSource, and reasonCode

  • Changed the cardinality of the following elements:

    • N/A - no cardinality changes

Key differences from ACCESS MedicationStatement Patient Profile:

Must Support Differences

  • dateAsserted is flagged as a Must Support element for ACCESS Medication Statement Clinician Profile but is only noted as optional in the patient-focused profile. This was due to SME recommendation, given that the date of statement assertion was primarily valuable for clinicians performing medication management & reconciliation.
    • Note: This element does not have an airtight mapping to a CeRX element and may need to be ascertained from metadata (message creation time) in the wrapper of the query/response
  • informationSource is flagged as a Must Support element for ACCESS Medication Statement Clinician Profile but is only noted as optional in the patient-focused profile.
    • Source and verifiability of the medication statement impact clinical decision particularly if medicationStatements support patient & caregiver creation use cases.

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 MedicationStatement R4 Profile:

Much like MedicationRequest, the ACCESS MedicationStatement profile has intentional alignment with the US Core MedicationStatement profile.

Because both profiles are focused on clinician access, differences between the two profiles are largely due to natural constraints and variances from the anticipated data sources (CeRX Medication Profile Summary Query Response: PORX_IN060400CA).

Differences between the two profiles are as follows:

Must Support Differences

  • derivedFrom is flagged as a Must Support element for US Core, but is not in the ACCESS profile. This was due to the available source data (CeRX messages) only supporting boolean values for whether or not the statement was derived from a secondary source.
  • informationSource is flagged as a Must Support Element for this ACCESS profile. While it is not the same as the derivedFrom element, informationSource was included as a must-support because it allowed Clinicians more information to help validate the MedicationStatement when the clinician isn't the source of truth for the resource.
  • reasonCode is flagged as a Must Support element for ACCESS profile, but not US Core. The availability of observationDiagnosis/Symptom/Indications in the CeRX messages makes this a reasonable value to expect from implementors.
    • reasonCode was marked as must support in the clinician profile to support medication management activities and enrich the medication review conversations between patient and clinician when the clinician is not the source of the medicationStatement.

Cardinality Constraint Differences

  • US Core creates a lower cardinality constraint on the dateAsserted element (1..1), however CeRX semantic mapping limitations for dateAsserted the ACCESS profile did not take on the same 1..1 cardinality put forth by the US Core.

Data Type Constraint Differences

  • US Core binds to its own profile for Medication and Patient, while the ACCESS profile references the CA Core Medication and Patient Profiles.

Binding Differences