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

Screenshot Dispense items Prescription items

Screenshot Medicine Entry Active ingredient Last dosage Last dispense Prescribing date

Screenshot Dispenses aggregated 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 class 1.Client-actor queries ITI-18 with dedicated document class „Medication list“ as search criteria 2.Backend generates document on-demand and returns document reference 3.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 reference 3.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 reference 3.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