Austrian e-Medication project

Approaches for „Medication list“

Jürgen Brandstätter

According to our Whitepaper

The Austrian „Medication list“ is an „Unreconciled Medication list“(or maybe an „Aggregated medication list“, but just to a very minor extent)

Austrian Medication list facts

• Main purpose of the project• Unreconciled list (of aggregated list)• Data sources limited to:

– … Prescriptions (+ Pharmaceutical Advices)– … Dispenses (+ Pharmaceutical Advices)– No other (foreign = not in Pharmacy domain) data-sources planned!

• Resulting data set categorized in 2 groups:– (1) Dispense items– (2) Prescription items

• Results– All medication dispensed within the last year (fixed)

• Filtering deferred to client side

– All medication prescribed and ready to be dispensed

ScreenshotDispenseitems

Prescriptionitems

Screenshot

MedicineEntry

Active ingredient Last dosage Last dispense

Prescribing date

Screenshot

Dispensesaggregated

Aggregation details(One dispense line each for the same medicine)

Content Format

• Medication list is a CDA document– With unique id (for logging)– With all Dispense items within a given time-frame– With all Prescription items within a given time-frame– No aggregation

• Aggregations will take place at client• (Possibly) processing: Mapping of „active ingredient ATC“ to

„ingredient class ATC“

• Generated on-demand at request– Stored on server-side for logging

How to get the CDA document?Implementation options: Variant 1

• Variant 1: Use ITI-18 with dedicated document class1. Client-actor queries ITI-18 with dedicated document class

„Medication list“ as search criteria2. Backend generates document on-demand and returns document

reference3. Client-actor retrieves document

• Advantages– Purely just an „implementation scenario“ (fully IHE compliant)

• Disadvantages– Whole e-Medication architecture does not support ITI-18, but

totally relies on PHARM-1 (therefore they don‘t want to open ITI-18)• Would have to open ITI-18 just for this purpose

It was a learning during the project specification that in a Standard CMPD scenario ITI-18 is not necessary (and not recommended), because it does not deliver related documents.

How to get the CDA document?Implementation options: Variant 2

• Variant 2: Extend PHARM-1 with a dedicated new query „GetMedicationList“1. Client-actor queries PHARM-1 with new query „GetMedicationList“2. Backend generates document on-demand and returns document

reference3. Client-actor retrieves document

• Advantages– No need to open ITI-18– Pharmacy request would be played by PHARM-1 transaction (which

makes sense, since it is a „Pharmacy-related“ task)• Disadvantages

– Not just an „implementation scenario“ -> IHE extension required

How to get the CDA document?Implementation options: Variant 2

• Variant 2: Extend PHARM-1 with a dedicated new query „GetMedicationList“1. Client-actor queries PHARM-1 with query „GetMedicationList“2. Backend generates document on-demand and returns document

reference3. Client-actor retrieves document

• Advantages– No need to open ITI-18– Pharmacy request would be played by PHARM-1 transaction (which

makes sense)• Disadvantages

– Not just an „implementation scenario“ -> IHE extension required

This is the project‘s decision

Wishlist to IHE - First

• Content Profile „Pharmacy Medication List (PML)“– Defines the CDA document for the Medication list– Proposal for structure:

• Standard CDA header (like e.g. in Prescription)• First CDA Section „Medication list – Dispense items“

– List of Dispense items (unchanged in structure, as derived from the Dispense-documents found)

• Second CDA Section „Medication list – Prescription items“– List of Prescription items (unchanged in structure, as derived

from the Prescription-documents found)

Wishlist to IHE - Second

• New query „GetMedicationList“ at PHARM-1 transaction– When the user queries “GetMedicationList” the expected

result is a CDA document containing the information.– This CDA document is generated on demand according to

the “Pharmacy Medication List (PML)” profile.– No further constraints for generation defined to keep it

flexible and open for projects to use this transaction– Only the important things are defined:

• How to query for the Medication list (GetMEdicationList)• What is the format the data is returned (PML profile)

Conflicts with current Whitepaper work• No conflicts

– … but our current Whitepaper work assumes generic data-sources for Pharmacy information, whereas this approach limits it to Pharmacy data sources (Pharmacy repositories)

• Due to its generic approach our current Whitepaper work aims to a generic „Data requestor – Data gatherer“ actor topology– … whereas this approach uses the already given „Community Pharmacy Manager“

as the gathering actor– Remark: The generic „Data requestor – Data gatherer“ approach has to be

introducted in ITI (= long process), because this topology would be used not only in Pharmacy

• For us to consider:– Either we wait at least another 2 years until our generic „Data requestor – Data

gatherer“ is ready to be used in Pharmacy– Or we introduce this „GetMedicationList“ query as a immediate approach for

Medication lists for projects which want to go that way• If this is chosen in the end we have to possibilities for Medication lists:

– The one limited to Pharmacy domain data sources only– The „larger“ one providing the ability for data sources outside of the Pharmacy domain

Thank you