<status value="draft" /> <date value="2021-03-22T16:05:12.5060946+00:00" /> <description value="This profile is scoped for usage within the Patient Chart" /> <fhirVersion value="4.0.1" /> <mapping> <identity value="workflow" /> <uri value="http://hl7.org/fhir/workflow" /> <name value="Workflow Pattern" /> </mapping> <mapping> <identity value="rim" /> <uri value="http://hl7.org/v3" /> <name value="RIM Mapping" /> </mapping> <mapping> <identity value="w5" /> <uri value="http://hl7.org/fhir/fivews" /> <name value="FiveWs Pattern Mapping" /> </mapping> <mapping> <identity value="v2" /> <uri value="http://hl7.org/v2" /> <name value="HL7 v2 Mapping" /> </mapping> <kind value="resource" /> <abstract value="false" /> <type value="MedicationStatement" /> <baseDefinition value="http://hl7.org/fhir/StructureDefinition/MedicationStatement" /> <derivation value="constraint" /> <differential> <element id="MedicationStatement"> <path value="MedicationStatement" /> <comment value="***** Add adherence code extension Conformance Rule: If the EMR is able to distinguish that the patient was the source/data enterer of the medication information (eg entered by the patient in the patient portal or into a e-questionnaire/qnaire), this must be conveyed as a Medication Statement. Example: Questionnaire may capture existing drugs. This is a potential use case where an EMR is able to distinguish that the patient is the source of the information. Conformance Rule: A medication Statement will always trigger the creation of a plan; as a plan is required in order to convey changes in status, eg on-hold, stopped, etc Conformance Rule: A medication statement is only to be used when EMRs can detect that the patient is the information source. It is not always possible for the EMR to distinguish the patient/related person as the information source is not alwasy recorded discretely. In this case the key data (eg patient not taking due to side effect) will be captured on the plan as a note. Conformance Rule: The status of a medication statement will always be set to "complete" TO BE REVIEWED --- Patient Chart Usage Guidelines: 1. In the context of sending a consultation request/referral it is usually not necessary to send the Prescription information along with the Medication Statement. . Prescription details may be very important when referring to an oncologist, or to share dose, interval frequency (once a day) 2. There will be a medication statement for each new SIG. There will be a new medication statement for each status change (eg on hold, discontinued). 3. A single med statement could include multiple prescriptions; OR multiple medication statements may reference a single prescription (eg dose change) OR a medication statement may be sent without a prescription (eg prescribed by specialist, non-prescription (eg aspirin) or prescribed medication that was reported by the patient or a mediication that was started by another doctor (aka external prescription). 4. Type of Medication Statements: 1. A patient chart will cover a period of time that a patient was on the same dose of a medication. 2. Dose changes over a fixed schedule, over a period of time as specified in the presciption dosage instructions (eg warafin). If there is a new SIG, there will be a new medication statement. 3. PRN - this is a valid medication period 6. Conformance Rule: If the patient follows the dose on the prescription, we would expect a single medication statement which may have multiple dosage lines. If the dose changes unexpectedly, or in a way that was not indicated on the original SIG, there will be multiple medication statements; one for each consecutive period and dosage instructions for that period. CONFIRM: NEW MED STATEMENT WHEN WE CHANGE DOSAGE DW - Use Case Example - Warafin - a patient on warafin could be represented by multiple medication statements; one for each interval of time/dosage instruction. The prescription is a "proposed" treatment, whereas the medication statement is a retrospective view/what the patient actually took (dosage/frequency). PSS: This is captured in treatment history, which captures the discrete dosage, time interval Example - Anti-depressant. Ramp up approach. This can be represented as 2 med statements; the first is the ramp up period and the second being the final dosage. Alternatively, this could be one med statement with two dosage lines (first this, then that). EXAMPLES: https://simplifier.net/onlyfortestingmedication/medicationstatement-example https://build.fhir.org/ig/HL7/ccda-on-fhir-r4//MedicationStatement-medication-statement.xml.html https://fhir.ch/ig/ch-emed/MedicationStatement-2-7-MedStatBeloczok.xml.html https://simplifier.net/finnishphr/medicationstatement-example-max PHARMACY WORKING GROUP FHIR - https://confluence.hl7.org/display/PHAR/May+2020+-+Virtual+Pharmacy+Meetings ** THE .wasNotTaken DATA ELEMENT NO LONGER EXISTS; WAS REMOVED IN R3 Use Case 1 - Sending Patient Chart to Specialist: Send "active" medications always and any relevant completed medications that pertain to the specific case. May wish to share "intended" as well. Use Case 2 - Sharing full Patient Chart (eg switching physicians). ALL history/all status's will be sent. Use Case 3 - DW - only "active" medications will be shared; will could be extended in the future EMR will not be aware of whether a drug is taken or not taken. PSS will know whether it was prescribed but not taken; it is then discontinued. MA - would support one medication statement, per prescription recorded in the EMR. If there is no prescription recorded ("external prescription"), this would be a single medication statement for each record. We can SEND: Status=Active = Taking (as of today's date) Status=Completed = Taken in past (no future prescription, was a prescription in past) Status=Active + NotTaken=T = Not currently taking Status=Completed + NotTaken=T = Not taken in the past Status=Intended = No intention of taking Status=Active + NotTaken=F = Taking, but not as prescribed Status=Active + NotTaken=F = Taking Status=Intended +NotTaken= F = Will be taking (not started) Status=Completed + NotTaken=F = Taken in past Status=In Error + NotTaken=N/A = In Error." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.id"> <path value="MedicationStatement.id" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.meta"> <path value="MedicationStatement.meta" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.meta.lastUpdated"> <path value="MedicationStatement.meta.lastUpdated" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.meta.source"> <path value="MedicationStatement.meta.source" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.meta.profile"> <path value="MedicationStatement.meta.profile" /> <comment value="Usage: Each implementation will determine if this will be used. It may be useful to validate a message instance against this profile. It is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set." /> <max value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.text"> <path value="MedicationStatement.text" /> <comment value="************ lots of work to be done on narrative in ALL Resources to ensure it can be summarized into a bigger picture for recipients who cannot accept discrete data CA-Core - not supported Discussion: Important for mapping into CDA with CDX Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.text.status"> <path value="MedicationStatement.text.status" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.text.div"> <path value="MedicationStatement.text.div" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.extension"> <path value="MedicationStatement.extension" /> <slicing> <discriminator> <type value="value" /> <path value="url" /> </discriminator> <rules value="open" /> </slicing> <min value="0" /> </element> <element id="MedicationStatement.extension:RenderedDosageInstruction"> <path value="MedicationStatement.extension" /> <sliceName value="RenderedDosageInstruction" /> <definition value="Concatenation of all dosage lines in a human readable form." /> <comment value="Alignment: This is a pre-adoption of an R5 element; this is also prsent in PrescribeIT" /> <min value="0" /> <max value="1" /> <type> <code value="Extension" /> <profile value="http://telus.com/fhir/patientChart/StructureDefinition/ext-rendered-dosage-instruction" /> </type> <isModifier value="false" /> </element> <element id="MedicationStatement.basedOn"> <path value="MedicationStatement.basedOn" /> <comment value="Usage: The detailed prescription should be shared when known. This may be a prescription from the sending system, or a prescription that was imported from another system or recorded by the clinician (eg 'external prescription'). CA-Core - not supported but they are supporting derived from - ? References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.basedOn.reference"> <path value="MedicationStatement.basedOn.reference" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.partOf"> <path value="MedicationStatement.partOf" /> <comment value="Alignment: This data element will be supported for DW Extract. Not supported by Core-CA Patient Chart This data element will not be used as we have scoped med statement to particular use when patient advises of a medication they are taking and there is no prescription that has been created. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository." /> </element> <element id="MedicationStatement.status"> <path value="MedicationStatement.status" /> <comment value="Conformance Rule: For Patient Chart, only "completed" is supported; other status's (active | on-hold | cancelled | completed | entered-in-error | stopped | draft | unknown) will be conveyed in the Medication Request.status of the associated Plan. Rationale: In R5, many of these status's will no longer be supported For Dw, this is a list of medications that the patient is currently taking, is planning to take or has taken. As such all status's are relevent. Note: The restricted code set aligns with R5, MedicationUsage. Conformance Rule: Status of unknown and entered-in-error will not be sent for the Patient Chart. Rationale: EMRs do not have an indicator for unknown and entered-in-error are not clinically relevant or have been removed from the chart Medication Statement used to capture a change in medication at a given date. Example: There may be one "active" med statements for the same drug, with effective date "x" and another "completed" med statement with where dosage instructions have changed. FDG: what statuses would be considered as active (ex: recently active? Added to issues list Conformance Rule: FDG *** confirm what status's are expected to be shared. Added to issues list Mappings: EMRAPI: Status (CC) CA-Core: supported PSS - Discuss in FDG to confirm what status are appropriate. Active-> Active, completed->N/A N/A-> Inactive (won't show in CPP). entered-in-error-> N/A intended-> N/A stopped->Auto-discontinue ??--> discontinue (may or may not be codified, ask FDG for guidence), on hold-> on hold unknown-> N/A not taken-> "not currently taking" (compliance, not codified) MS : See value from Medication object. active -> active completed -> check stopped date in the past entered-in-error-> N/A intended -> N/A stopped -> stop (check SIG field in prescriber) on-hold -> N/A unknown -> N/A not-taken-> N/A. Looks for deactivation date. If deactivation date is null it is considered active. MA - Active - specific logic to drive active or inactive. Falls from active to inactive (dynamic/derived), based on calc based on end date and half-life of a drug (time it takes for drug to disappear 50% in patient's system). Discontinue=stopped. Hold=on-hold. Inactive=completed. Manual interventions (discontinue, renew) are also part of the logic. Example: Renewal -> instance of inactive /effective period+ instance of activ/start date _>> Two medication statements Example: RX/dose 1, then renew same RX/dose2 with overlap effectiveDate -> renewal would always replace the first one, and this would be a single med statement. CHR - if re-presecribing, replacing the original; implicitly end and start; can technically be represented either way. Warfarin - 1mg tab and 5mg tab - different med; different RX, Warafin - 1mg tab, second RX, 1mg tab - replace - single line, single med statement, start date from original End date is not definitive (eg if on hold, end date is bumped) - auto-calc MA - Early renewal. if you take meds with days remaining, and then renew, it defaults the start date of next RX to be the expected end date. 2 med statements in MA. To make this a single med statement, heuristic 1 med statement in PSS For FDG: what statuses would be considered as active (ex: recently active?) Core-CA - supported FHIR: MedicationStatement is a statement at a point in time. The status is only representative at the point when it was asserted. The value set for MedicationStatement.status contains codes that assert the status of the use of the medication by the patient (for example, stopped or on hold) as well as codes that assert the status of the medication statement itself (for example, entered in error). This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid." /> <fixedCode value="completed" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.statusReason"> <path value="MedicationStatement.statusReason" /> <comment value="Usage Rule: This is supported as text only Alignment: This is not supported in the Core-CA; also support for DW Extract This is generally only used for "exception" statuses such as "not-taken", "on-hold", "cancelled" or "entered-in-error". The reason for performing the event at all is captured in reasonCode, not here." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.statusReason.text"> <path value="MedicationStatement.statusReason.text" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.category"> <path value="MedicationStatement.category" /> <comment value="Mappings: Core-CA - not supported EMRAPI: N/A MA: N/A PSS: N/A MS: N/A Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination." /> </element> <element id="MedicationStatement.medication[x]"> <path value="MedicationStatement.medication[x]" /> <comment value="Conformance Rule: This will be the "prescribed" medication, rather than the "dispensed" medication. The dispensed medication is assumed to be equivalent and therefore is not relevant to the medication statement. DISCUSSION IPS - has added an absent reason slice - https://build.fhir.org/ig/HL7/fhir-ips/ValueSet-absent-or-unknown-medications-uv-ips.html to convey "no medication info" or "no known reasons". ADD A SLICE (codeable concept) - AS PER IPS AND MAYBE CANADIAN CORE? FOR THIS IPS value set: no-medication-info No information about medications There is no information available about the subject's medication use or administration. no-known-medications No known medications There are no medications for the subject that have to be reported in this record. This can mean either that there are none known, or that those known are not relevant for the purpose of this record. MS - does not capture explictly - could map to no-medication-info MA - ? PSS - ? JIM -- DO WE WANT TO SUPPORT THIS EXTENSION TO CONVEY NO MEDICATION INFO? alternatively we could put a null flavour on the reference from composition Core-CA - supported If only a code is specified, then it needs to be a code for a specific product. If more information is required, then the use of the medication resource is recommended. For example, if you require form or lot number, then you must reference the Medication resource." /> <type> <code value="CodeableConcept" /> </type> <type> <code value="Reference" /> <aggregation value="contained" /> </type> <mustSupport value="true" /> </element> <element id="MedicationStatement.subject"> <path value="MedicationStatement.subject" /> <comment value="Core-CA - supported References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository." /> <type> <code value="Reference" /> <targetProfile value="http://hl7.org/fhir/StructureDefinition/Patient" /> <aggregation value="bundled" /> </type> <mustSupport value="true" /> </element> <element id="MedicationStatement.subject.reference"> <path value="MedicationStatement.subject.reference" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.subject.display"> <path value="MedicationStatement.subject.display" /> <comment value="Usage Note: This should contain the name of the Patient, which can then be used in narrative This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.context"> <path value="MedicationStatement.context" /> <comment value="EMRAPI: Not supported Core-CA; Not supported PSS - Encounters are available via stamps and custom forms. MA, MS - N/A References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository." /> </element> <element id="MedicationStatement.effective[x]"> <path value="MedicationStatement.effective[x]" /> <comment value="Conformance Rule: This may be a fuzzy start date where the patient does not know exactly when the medication began. Usage Note: The default rule is that the most recent effective date (Prescribed/renewed date) should be used for episodic events, eg repeated bladder infection Med Statement. effective Period *if no end date, this is ACTIVE OR ON-HOLD in the plan; med statement is a fixed status of "completed" *IF end date is present AND Med Statement Date is less than= end date then it is ACTIVE in the plan *If end date is present AND Med Statement date is greater than end date, then it is COMPLETED in the plan If status Start date (of active record) and date the record was marked as completed Alignment-PS-ON: Question to them: If it is an episodic drug, what is expected? Most recent episode, or original episode dates? Example: repeated bladder infections. Please update the specification to clarify Answer from ON: Clinical consultation will be required to provide guidance for this. Ontario Health will look for opportunities to seek clinical guidance in the future. This attribute reflects the period over which the patient consumed the medication and is expected to be populated on the majority of Medication Statements. If the medication is still being taken at the time the statement is recorded, the "end" date will be omitted. The date/time attribute supports a variety of dates - year, year/month and exact date. If something more than this is required, this should be conveyed as text." /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dateAsserted"> <path value="MedicationStatement.dateAsserted" /> <comment value="EMRAPI: N/A Core-CA - supported MA/MS: n/a PSS: One of 3 sources: a)"Prescribed on Date" may be used for medications that were prescribed by the doctor. b) For other recorded medications, the change date may be used. c) Date Issued may be used when treatment is entered via the Fast Profile Entry. Date when the patient told the PCP about it. FDG: Unless we really need this we can drop it." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.informationSource"> <path value="MedicationStatement.informationSource" /> <comment value="Conformance Rule: If the EMR is able to distinguish that the patient was the information source of the medication information (eg entered by the patient in the patient portal or into a e-questionnaire/qnaire), then the information source must be the patient. Conformance Rule: This is only expected to be populated with the patient or related person (mother, child) or an organization in the case of a nursing home when discretely recorded in the EMR. If the information source is not discretely Core-CA - supported DHDR - is this the Pharmacy? References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository." /> <type> <code value="Reference" /> <aggregation value="bundled" /> </type> <mustSupport value="true" /> </element> <element id="MedicationStatement.informationSource.reference"> <path value="MedicationStatement.informationSource.reference" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.informationSource.display"> <path value="MedicationStatement.informationSource.display" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.derivedFrom"> <path value="MedicationStatement.derivedFrom" /> <comment value="Conformance Rule: This is supported in order to align with the CA-Core profile. To date, we do not have a specific use case for inclusion of this data. There is no expectation that this will be supported at this time for this implementation, though it may be used in other implementations in Canada. Core-CA - supported and also supported in US Core. CA- Core has scoped to support MedRequest, MedDispense, Claim, ObservationProfile (General Use) Likely references would be to MedicationRequest, MedicationDispense, Claim, Observation or QuestionnaireAnswers. The most common use cases for deriving a MedicationStatement comes from creating a MedicationStatement from a MedicationRequest or from a lab observation or a claim. it should be noted that the amount of information that is available varies from the type resource that you derive the MedicationStatement from." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.derivedFrom.reference"> <path value="MedicationStatement.derivedFrom.reference" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.derivedFrom.display"> <path value="MedicationStatement.derivedFrom.display" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode"> <path value="MedicationStatement.reasonCode" /> <comment value="Conformance Rule: A local code must be included if known. Text must also be included where known. Core-CA - not supported PSS: Local codes or for free text just send display. PSS: ICD9/10, SNOMED via FDB, encode MA: ICD9, SNOMED, free text, local code system MS: N/A DHDR: ODB reason for use code This could be a diagnosis code. If a full condition record exists or additional detail is needed, use reasonForUseReference." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode.coding"> <path value="MedicationStatement.reasonCode.coding" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode.coding.system"> <path value="MedicationStatement.reasonCode.coding.system" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode.coding.code"> <path value="MedicationStatement.reasonCode.coding.code" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode.coding.display"> <path value="MedicationStatement.reasonCode.coding.display" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonCode.text"> <path value="MedicationStatement.reasonCode.text" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.reasonReference"> <path value="MedicationStatement.reasonReference" /> <comment value="Core-CA - not supported This is a reference to a condition that is the reason why the medication is being/was taken. If only a code exists, use reasonForUseCode." /> </element> <element id="MedicationStatement.note"> <path value="MedicationStatement.note" /> <comment value="Usage Notes: Used to capture any information from the patient that is pertinent to the statement. Information that is specific to dosage should be captured under dosage where possible. Example: Some EMRs record whether the medication is "successful" or "not successful" and general text comments that may be captured here. EMRAPI: Notes Core-CA - not supported MA: Patient instructions go in the dosage object PSS: Any comment can be added into medication, in addition the dosage.text/SIG? MS: Patient chart-->summary-->active medication --> comment For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. *Annotations SHOULD NOT* be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible)." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage"> <path value="MedicationStatement.dosage" /> <comment value="Conformance Rule: This is the dosage that the patient actually took, which may differ than the dosage that is on the prescription. Conformance Rule: This must always be included where known Core-CA - supported - text only is supported Usage: It is rare that a medication statement, will not have dosage (minimally text), but it may occur. Usage: This captures what the patient is actually taking. This COULD be the same as the dosage in the prescription (steady, ramp-up, ramp-down). If there is a change after the patient has started to take it, it is recorded in the EMR (not included in the prescription) Usage: Dosage instruction can be a single instance, with multiple dosage instructions/lines (eg one a night for 7 nights, then 2/day) Usage: Unexpected Dosage change - update to the dosage from the prescription. This would be recorded in the EMR and would have a different effective period. This is a trigger to send a new medication statement. *** For MS, this will be challenging; you dont' have a sense of history. eg active meds have an end date in 2017. RX for ongoing drug; renewal deactivates the previous one without changing dates on the old one or adapting on the new one (if you had the drug for years, it creates a new record) *** PSS - dosage/renewals are separate line; works well for a new med statement. Conformance Rule: Where possible, each renewal could be a new/second med statement if the dosage changes. Conformance Rule: Where possible, If the same drug, same dosage, many RX's, this can be rolled up and effective period would start at first RX. Notes: SIG can change multiple times for a single prescription. Doctors have the ability to change dosages and the prescription dosage is only valid at the time of writing and can be overridden at any point in the future. Prescription is a single event in the series of events that occur for that drug. including dosage instructions. Dosage instructions can be changed at any time; update/change within the system. Events: Prescription, Dosage Change, On-Hold, Discontinued, StartedAgain, etc. Conformance Rule: If sending systems are capable, they should send the discrete data. This will be captured using the same mechanisms as PrescribeIT. Rationale: this may be useful for dosage checking and monitoring compliance to guidelines. Usage Note: An Excel spreadsheet published by PrescribeIT provides guidance on how to populate dosage instructions. Mappings: IPS - support text, timing and route - https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-MedicationStatement-uv-ips.html When the dose or rate is intended to change over the entire administration period, e.g. Tapering dose prescriptions, multiple instances of dosage instructions will need to be supplied to convey the different doses/rates. Another common example in institutional settings is 'titration' of an IV medication dose to maintain a specific stated hemodynamic value or range e.g. drug x to be administered to maintain AM (arterial mean) greater than 65. The dates included in the dosage on a Medication Statement reflect the dates for a given dose. For example, "from November 1, 2016 to November 3, 2016, take one tablet daily and from November 4, 2016 to November 7, 2016, take two tablets daily." It is expected that this specificity may only be populated where the patient brings in their labeled container or where the Medication Statement is derived from a MedicationRequest." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.sequence"> <path value="MedicationStatement.dosage.sequence" /> <comment value="Usage Note: This is mandatory as it indicates the dosage instruction sequence. Mapping Note: This concept is represented in PrescribeIT as an extension on dosage. Core-CA - not supported ? 32 bit number; for values larger than this, use decimal" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.text"> <path value="MedicationStatement.dosage.text" /> <comment value="Conformance Rule: When providing multiple dosage lines can be expressed individually. All dosage lines (full text content) must be concatenated into MedicationStatement.extension(RenderedDosageInstruction) for recipients who can support the receipt of individual lines. Usage Note: This is a string composed of any available discrete MedicationStatement.dosage child elements such as timing, asNeeded[x], siteCodeableConcept, route, dose[x], rate[x], and maxDosePerPeriod for each repetition sequence line. Example: Prednisone; variable dosage instruction, or concurrent instructions (1 pill morning and 1 pill before bed) or sequential dosages (1 pill for 2 days, then 2 pills)." /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.additionalInstruction"> <path value="MedicationStatement.dosage.additionalInstruction" /> <comment value="EMRAPI: Not supported Core-CA - not supported PrescribeIT Usage Notes below - MAY NOT BE ALL APPROPRIATE; DISCUSSION REQUIRED Usage Note:: To convey explicit instructions to the Pharmacist/dispenser related to this medication order. Usage Note: If the PMS solution is unable to display the entire instructions, then it is expected that the current solution has a fail-over process and will create a printout of the prescription. Conformance Rule: When 'compliance pack' is indicated on the prescription within the EMR, populate the pharmacist instruction/dispenser instructions with 'COMPLIANCE PACK REQUESTED' Usage Note: In the case where the prescriber indicates the concept of ‘do not adapt’ (meaning that the pharmacist should not alter the prescription based on the patient's weight as an example), this direction to the pharmacist should be conveyed in human language in this field. Conformance Rule: If a prescriber wishes to indicate that there is no substitution it must be included as part of the pharmacy instructions. Conformance Rule: LU Codes must be clearly conveyed as part of the Pharmacists Instructions. If vendors are programmitically mapping into this field, they should use a prefix of LU Code before the identifier. Information about administration or preparation of the medication (e.g. "infuse as rapidly as possibly via intraperitoneal port" or "immediately following drug x") should be populated in dosage.text." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.patientInstruction"> <path value="MedicationStatement.dosage.patientInstruction" /> <comment value="Core-CA - not supported Discussion required: PSS: Label Instruction. Note: this is also part of text. Note, with meals", "may cause drowsiness are included here but FHIR shows under additional instructions. Note that FHIR strings SHALL NOT exceed 1MB in size" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing"> <path value="MedicationStatement.dosage.timing" /> <comment value="Core-CA - not supported Conformance Rule: If an EMR cannot send discrete elements in all cases for timing.repeat element, this is acceptable as long as RENDERED_DOSAGE_INSTRUCTION captures the timing. This attribute might not always be populated while the Dosage.text is expected to be populated. If both are populated, then the Dosage.text should reflect the content of the Dosage.timing." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat"> <path value="MedicationStatement.dosage.timing.repeat" /> <comment value="Conformance Rule: If an EMR cannot send discrete elements in all cases for timing.repeat element, this is acceptable as long as RENDERED_DOSAGE_INSTRUCTION captures the timing." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.bounds[x]"> <path value="MedicationStatement.dosage.timing.repeat.bounds[x]" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.count"> <path value="MedicationStatement.dosage.timing.repeat.count" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.countMax"> <path value="MedicationStatement.dosage.timing.repeat.countMax" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.duration"> <path value="MedicationStatement.dosage.timing.repeat.duration" /> <comment value="Example: "5 mL Q6H for 4 day(s)" For some events the duration is part of the definition of the event (e.g. IV infusions, where the duration is implicit in the specified quantity and rate). For others, it's part of the timing specification (e.g. exercise)." /> <requirements value="API Mapping: *.currentMedications.dosageInstructions.duration.value Some activities are not instantaneous and need to be maintained for a period of time." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.durationMax"> <path value="MedicationStatement.dosage.timing.repeat.durationMax" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.durationUnit"> <path value="MedicationStatement.dosage.timing.repeat.durationUnit" /> <comment value="Example: "5 mL Q6H for 4 day(s)" Note that FHIR strings SHALL NOT exceed 1MB in size" /> <requirements value="API Mapping: *.currentMedications.dosageInstructions.duration.unit.coding Unit of time (required) s/min/h/d/wk/mo/ a MA: urn:telus:emr:ma:*:codetable:medication-frequency PSS: urn:telus:emr:pss:*:codetable:dose-duration" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.frequency"> <path value="MedicationStatement.dosage.timing.repeat.frequency" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.frequencyMax"> <path value="MedicationStatement.dosage.timing.repeat.frequencyMax" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.period"> <path value="MedicationStatement.dosage.timing.repeat.period" /> <requirements value="5 mL Q6H for 4 day(s)" API doesn't break this out by period and period unit. API Mapping: *.currentMedication.doageInstructions.frequency.coding" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.periodMax"> <path value="MedicationStatement.dosage.timing.repeat.periodMax" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.repeat.periodUnit"> <path value="MedicationStatement.dosage.timing.repeat.periodUnit" /> <comment value="5 mL Q6H for 4 day(s)" ****Don't think API frequency value will work as it is a single code and doesn't break out both the amount and unit. Note that FHIR strings SHALL NOT exceed 1MB in size" /> <requirements value="API Mapping: *.currentMedication.doageInstructions.frequency.coding" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.code"> <path value="MedicationStatement.dosage.timing.code" /> <comment value="EMRAPI: *.currentMedication.doageInstructions.frequency.coding ??? this is NOT supported in PrescriebIT, so we need to revisit to ensure we need this. Mapping is pretty clear **Maybe API frequency element would be better used here? BID etc. are defined as 'at institutionally specified times'. For example, an institution may choose that BID is "always at 7am and 6pm". If it is inappropriate for this choice to be made, the code BID should not be used. Instead, a distinct organization-specific code should be used in place of the HL7-defined BID code and/or a structured representation should be used (in this case, specifying the two event times)." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.code.coding"> <path value="MedicationStatement.dosage.timing.code.coding" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.timing.code.coding.code"> <path value="MedicationStatement.dosage.timing.code.coding.code" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.asNeeded[x]"> <path value="MedicationStatement.dosage.asNeeded[x]" /> <comment value="Core-CA - not supported EMRAPI: .currentMedications.dosageInstructions.asNeeded Usage Note: FHIR: Can express "as needed" without a reason by setting the Boolean = True. In this case the CodeableConcept is not populated. Or you can express "as needed" with a reason by including the CodeableConcept. In this case the Boolean is assumed to be True. If you set the Boolean to False, then the dose is given according to the schedule and is not "prn" or "as needed"." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.site"> <path value="MedicationStatement.dosage.site" /> <comment value="Core-CA - not supportedIf the use case requires attributes from the BodySite resource (e.g. to identify and track separately) then use the standard extension [bodySite](extension-bodysite.html). May be a summary code, or a reference to a very precise definition of the location, or both." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.site.coding"> <path value="MedicationStatement.dosage.site.coding" /> <max value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.site.text"> <path value="MedicationStatement.dosage.site.text" /> <min value="1" /> </element> <element id="MedicationStatement.dosage.route"> <path value="MedicationStatement.dosage.route" /> <comment value="EMRAPI: *.currentMedications.route Core-CA - not supported Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.route.coding"> <path value="MedicationStatement.dosage.route.coding" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.route.text"> <path value="MedicationStatement.dosage.route.text" /> <min value="1" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.method"> <path value="MedicationStatement.dosage.method" /> <comment value="Core-CA - not supported Terminologies used often pre-coordinate this term with the route and or form of administration." /> </element> <element id="MedicationStatement.dosage.doseAndRate"> <path value="MedicationStatement.dosage.doseAndRate" /> <comment value="EMRAPI: *.dosageInstructions.doseRangeLow and *.doseRangeHigh Core-CA - not supported" /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.doseAndRate.dose[x]"> <path value="MedicationStatement.dosage.doseAndRate.dose[x]" /> <requirements value="API Mapping: *.dosageInstructions.quantity *.dosageInstructions.doseRangeLow FHIR: The amount of therapeutic or other substance given at one administration event." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.doseAndRate.rate[x]"> <path value="MedicationStatement.dosage.doseAndRate.rate[x]" /> <comment value="Example: "5 mL Q6H for 4 day(s)" PrescribeIT - always a ratio I think It is possible to supply both a rate and a doseQuantity to provide full details about how the medication is to be administered and supplied. If the rate is intended to change over time, depending on local rules/regulations, each change should be captured as a new version of the MedicationRequest with an updated rate, or captured with a new MedicationRequest with the new rate. It is possible to specify a rate over time (for example, 100 ml/hour) using either the rateRatio and rateQuantity. The rateQuantity approach requires systems to have the capability to parse UCUM grammer where ml/hour is included rather than a specific ratio where the time is specified as the denominator. Where a rate such as 500ml over 2 hours is specified, the use of rateRatio may be more semantically correct than specifying using a rateQuantity of 250 mg/hour." /> <mustSupport value="true" /> </element> <element id="MedicationStatement.dosage.maxDosePerPeriod"> <path value="MedicationStatement.dosage.maxDosePerPeriod" /> <comment value="Core-CA - not supported This is intended for use as an adjunct to the dosage when there is an upper cap. For example "2 tablets every 4 hours to a maximum of 8/day"." /> </element> <element id="MedicationStatement.dosage.maxDosePerAdministration"> <path value="MedicationStatement.dosage.maxDosePerAdministration" /> <comment value="Core-CA - not supported This is intended for use as an adjunct to the dosage when there is an upper cap. For example, a body surface area related dose with a maximum amount, such as 1.5 mg/m2 (maximum 2 mg) IV over 5 – 10 minutes would have doseQuantity of 1.5 mg/m2 and maxDosePerAdministration of 2 mg." /> </element> </differential> </StructureDefinition>