1 of 39

Actor definitions and transactions

2 of 39

Functional flow / Business actors (approved*)

Medication Treatment

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator/Producer

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Presc

MeOw

Medication Dispense (Repository?)

Dispense

MTLines

The Treatment Plan, Order and Dispense repositories (as well as others) can be specializations of a same type of system.

The Medication Treatment Repository is intended to capture the information about the overall treatment, including advices, comments.

The order repository includes orders as in: Prescriptions, and “validated” prescriptions after the “advice” from a pharmacist (see below for splitting the types of “advice”.

The Treatment Repository thus covers the “medical” aspects of a patient’s medication - what & how & why are the medications for a patient, while the Order and Dispense repositories are more the “logistic/administrative” documents that are needed to execute the process.

Medication Dispenser

MOrders(?)

3 of 39

Role of advice

We should somehow add the Advisor.

​

Roles of Adviser:

  1. As a needed actor: sometimes the “advice” is actually a necessary activity: validating a prescription to make it “dispensable”. Other examples are confirming the dosage, or checking the allowed dispensation while patient is pregnant, or checking the prerequisites for dispensing of controlled medication like narcotics.

​

  • As a “parallel” actor that simply provides feedback or recommendation (e.g. interactions, or overdosages), upon request or automatically. This feedback can be binding or not binding, depending on the implementation options.

​

We propose that in the first case, this is an “order placer” task: The “advice” that changes the order simply becomes an update to the order/plan, and the issuer of that order takes responsibility for the new order/plan.

With this, the “advice” becomes simply the parallel feedback that is not a change to the order, but it is a suggestion to do something with the order, which the order placer can decide to take or not.

4 of 39

Advice on Dispense

In the past we had “advice” on dispense - changes after a medication is dispensed:

  • Change posology
  • Change to another brand
  • Stop the treatment

​

Proposal: Those are changes to the treatment, not to the dispense. From a treatment change, there MAY be a issuance of a new dispense document, for example in the case where the dispense document is where the posology is indicated.

5 of 39

Comments

We also need to add comments to any of these objects: Dispense, Order, Plan, Overview.

These are comments that relate to more than one entry in the list.

  • simple example: “please monitor the kidney function because of medication A and B, and reconsider changing treatment if there are issues.”

Examples:

  • Patient reported medication:
    • Patient reports usage of medication, and comment is that patient has been strongly advised not to do it.
    • Pharmacist comments e.g. “Please note that patient is allergic to lactose and may develop issues with this brand”

6 of 39

Next steps

R4 vs R5:

  • Most implementations are on R4, some are expected to move to R5
  • IHE will then be giving advice on the “next” implementation
  • Also for complete implementations, R5 is best for IHE to have a full solution:
    • MPD is going on R5
    • Supply is for R5

​

  • Treatments:
    • Not decided: CarePlan? Others?
  • Prescriptions / grouping:
    • Not decided: RequestOrchestration? GroupIdentifier?

7 of 39

8 of 39

Data Requirements

Medication-related “raw data” - input to medication overview creator

  • Medication Treatment: A set of 1..n medication treatment lines and associated information, somehow related together (e.g. one same purpose, or one same entry by a professional)
    • 1..* Medication treatment line (this relation should not exist. should be the other way around . MTL → MT)
    • 0..* Advice
      • Advice content
      • Advice issuer, date, etc.
      • Topic (link to treatment OR Link to treatment line OR overview)
    • 0..* Comment
      • Comment content
      • Comment issuer, date, etc.
      • Topic (link to treatment OR Link to treatment line OR overview)

9 of 39

Medication Treatment Line

An entry representing one single medicinal product (or type of product) that is planned, or ordered, or dispensed, or actually reported taken by the patient.

  • 1..1 Medication: an identification or sufficient description of the product (code / composition / …)
    • Dose form
  • 1..1 Status
  • 0..1 Route of administration (not 0..* - if there are changes, will be an update)
  • 0..1 Dosage (strength, amount…)
    • may be a complex model e.g. one dosage for odd days and one for even days.
  • 0..1 Frequency (dose units, timing, etc)
  • 0..1 Effective time (duration, start+duration, start+end...)
  • 0..* reason / indication
  • 0..* Instructions
    • Preparation
    • Usage
    • (may be a link to an external request)
  • Metadata (reporter, reporting date, etc.)
  • 0..* Information sources: other data objects that this line is derived from (Order, Dispense, Line)
  • 0..* category category of a medication line
  • 0..* treatmentGroup (an explicit attribute that serves to associate 2 or more lines, in addition to the grouping that may be obtained from the other existing data elements)

10 of 39

Medication Treatment Plan ?

​

Medication Treatment line that hasn’t been executed yet.

A medication treatment line MAY have status “planned” (or no “actionable” status) but it’s still a line.

​

Subtype of Order, that hasn’t been executed yet and is not yet actionable.

​

For this reason, we will no longer use “Medication Treatment Plan” expression and concept in our specifications.

​

11 of 39

MTL grouping

Grouping based on:

  • Status (MTL.status)
  • Part of same order (MTL.source[request].groupIdentifier)
  • Medication group (MTL.medication.type)
  • Part of same treatment (we need a new attribute
  • ​

12 of 39

  • Patient reporting or HCP professional reporting

​

  • TO DO: Clarify how the medication entries / requests may be associated with other requests,.
    • Medication request may imply another request (e.g. change bandage every day)
    • Other requests may imply medication (e.g. apply some device but use local anesthetic if needed)

​

​

​

13 of 39

Data models

14 of 39

Medication Treatment Overview

Medication Treatment Line

  • status
  • author

Patient

Medication Treatment

Medication Treatment Overview

(assuming that treatment overview is a snapshot in time):

​

​

Medication Prescription

Medication Dispense

Medication PatientStatement(?)

e.g. negative, fuzzy statements

Medication Administration

  • Verification
    • date
    • practitioner
  • verification
    • date
    • practitioner
  • Comments
    • author
    • date
    • content
    • comment on… (line, treatment, or entire overview)

15 of 39

Medication Treatment Overview

Medication Treatment Line

Patient

Medication Treatment

Medication Overview

​

  • Medication Treatment Lines can be
    • Verified,draft,
  • It shall be possible to identify the

16 of 39

Data Requirements

Medication-related “raw data” - input to medication overview creator

  • Medication Treatment: A set of 1..n medication treatment lines somehow related together - e.g. one same purpose, or one same entry by a professional.
    • Advice
      • Advice content
      • Advice issuer, date, etc.
      • Topic (link to treatment OR Link to treatment line OR overview)
    • Comment -
      • Comment content
      • Comment issuer, date, etc.
      • Topic (link to treatment OR Link to treatment line OR overview)
    • Medication treatment line
  • ​
  • Order
    • Advice
    • Comment
  • Dispense
    • Comment

​

Where do we store the advice / comment? As part of the order?

17 of 39

LModels

MedicationOverview

  • Patient
  • …
  • TreatmentLine 0..*
  • Treatment 0..*
    • (link to treatment line 0..*)
  • Advice
    • Advice content
    • Advice issuer, date, etc.
    • Topic (link to treatment OR Link to treatment line OR overview)
  • Comment
    • Comment content
    • Comment issuer, date, etc.
    • Topic (link to treatment OR Link to treatment line OR overview)
  • Details / other input
    • Order
    • Dispense
    • Schedule
    • ReportedUsage
    • Administration

​

Every object must have some sort of “category” or other indication that allows access control - e.g. “patient refused to disclose” or “destroy after treatment”

18 of 39

Data exchange architecture

Exchanging Medication Overview could be done on different ways, depending on the jurisdictional context,

19 of 39

Medication Line

Plan / intent

Prescrip

Dispense

Statement

Plan / followup

Prescrip

Prescrip

Dispense

Dispense

20 of 39

21 of 39

22 of 39

23 of 39

24 of 39

25 of 39

26 of 39

Old materials

27 of 39

Functional flow / Business actors (previous)

Medication Treatment Plan

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator/Producer

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Presc

MeOw

Medication Dispense (Repository?)

Dispense

MTLines

The Treatment Plan, Order and Dispense repositories (as well as others) can be specializations of a same type of system.

28 of 39

OLD: Functional flow / Business actors (if there is a repository of ready made MeOws)

Medication Overview

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Potentially, any of the actors can be grouped with a Medication Advice Consumer actor

MeOw

(Push)

Presc

MeOw

29 of 39

Functional flow / Business actors (approved*)

Medication Treatment Plan

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator/Producer

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Presc

MeOw

Medication Dispense (Repository?)

Dispense

MTLines

The Treatment Plan, Order and Dispense repositories (as well as others) can be specializations of a same type of system.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Medication Treatment Repository

30 of 39

OLD: Functional flow / Business actors (if there is a repository of MedTreatmentLines)

Medication Treatment Lines

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Potentially, any of the actors can be grouped with a Medication Advice Consumer actor

​

To address: Pharmacist issues information / notes about a medication line (this may not be called “advice”)

Presc

MeOw

31 of 39

Old: Transaction actors (detailed actors with Adviser)

Medication Overview

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Medication Advice provider

Medication Advice consumer

Potentially, any of the actors can be grouped with the Medication Advice Consumer actor

32 of 39

Business actors - EE Current plan

​

​

​

​

​

​

​

Central

Medication

Overview

system

(part of Health Management portal)

Medication Overview

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator

Medication Overview

Consumer

Medication Order Placer

(internal API)

Medication Dispense (Repository)

33 of 39

Functional flow / Business actors (bad, bad slide!)

Medication Treatment Plan

(Repository?)

Medication Order (Repository?)

Medication Overview

Creator/Producer

Medication Overview

Consumer

Medication Order Placer

Medication Treatment Planner

Presc

MeOw

Medication Dispense (Repository?)

Dispense

MTLines

The Treatment Plan, Order and Dispense repositories (as well as others) can be specializations of a same type of system.

Medication Dispenser

Medication Advice Consumer

Medication Advice Producer*

34 of 39

Notes

Decision support: Should we do interaction check in pairs only? No - it’s best to support a list of medications and let the system provide any advice. This way, if the list contains 2 meds, it’s simple. But if the list contains 6 meds, it’s still one query and the system can find all combinations of each of the different combinations.

35 of 39

36 of 39

Technical Actors / Transactions

Medication Order Placer

Medication Order Filler

Order

Repository

PHARM-aaa

„PlaceMedicationOrder“

PHARM-ccc

„PlaceMedicationDispense“

Content: FHIR MedicationRequest

Dispense Repository

Content: FHIR MedicationDispense

PHARM-bbb

„QueryMedicationOrder“

​

Predefined queries:

GetMedicationRequestById

GetMedicationRequestsReadyToBeFilled

:

Content: FHIR Medication�Request(s) found

PHARM-aaa

„UpdateMedicationOrder“

PHARM-aaa

„CancelMedicationOrder“

PHARM-aaa

„CancelMedicationDispense“

Medication Treatment Planner

Plan

Repository

PHARM-aaa

„PlaceMedicationPlan“

Medication Overview

Work-item

Information

Information flow

37 of 39

Technical Actors / Transactions

Medication Order Placer

Medication Order Filler

PHARM-aaa

„PlaceMedicationOrder“

PHARM-ccc

„PlaceMedicationDispense“

Content: FHIR MedicationRequest

Content: FHIR MedicationDispense

PHARM-bbb

„QueryMedicationOrder“

​

Predefined queries:

GetMedicationRequestById

GetMedicationRequestsReadyToBeFilled

:

Content: FHIR Medication�Request(s) found

PHARM-aaa

„UpdateMedicationOrder“

PHARM-aaa

„CancelMedicationOrder“

PHARM-aaa

„CancelMedicationDispense“

Order

Receiver

Order

Responder

Dispense

Receiver

Dispense

Responder

38 of 39

Medication Order Placer

Order

Repository

Medication Order Filler

Dispense Repository

Medication Order Filler

Medication Order Filler

Medication Order Filler

Medication Order Placer

Medication Order Placer

Medication Order Placer

Medication Order Placer

Medication Order Placer

Order

Repository

Medication Order Placer

Order

Repository

Medication Order Placer

Order

Repository

Medication Order Filler

Dispense

Repository

Medication Order Filler

Dispense

Repository

Medication Order Filler

Dispense

Repository

Content: FHIR MedicationRequest

Content: FHIR MedicationDispense

Content: FHIR MedicationRequest

Content: FHIR MedicationDispense

39 of 39

Which of these other transactions shall we define?

  • ChangeMedicationRequest
    • Technically: New MedicationRequestOrder replacing the old one
    • Covered by PlaceMedicationOrder or own transaction (e.g. because there are content constraints attached to it)?
  • CancelMedicationRequest
    • Technically: New MedicationRequestOrder replacing the old one with a different status „cancelled“
    • Covered by PlaceMedicationOrder or own transaction (e.g. because there are content constraints attached to it)?

​

  • QueryMedicationDispense
    • Like QueryMedicationOrder

​

  • ChangeMedicationDispense
    • Like above

​

  • CancelMedicationDispense
    • Like above

​

  • Others?

​