140 likes | 287 Views
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 ).
E N D
Austrian e-Medicationproject Approachesfor „Medicationlist“ Jürgen Brandstätter
Accordingtoour Whitepaper The Austrian „Medicationlist“ is an „UnreconciledMedicationlist“ (ormaybe an „Aggregatedmedicationlist“, but just to a veryminorextent)
Austrian Medicationlistfacts • Main purposeoftheproject • Unreconciledlist (ofaggregatedlist) • Data sources limited to: • … Prescriptions (+ PharmaceuticalAdvices) • … Dispenses (+ PharmaceuticalAdvices) • Noother (foreign = not in Pharmacy domain) data-sourcesplanned! • Resultingdatasetcategorized in 2 groups: • (1) Dispense items • (2) Prescriptionitems • Results • All medicationdispensedwithinthe last year (fixed) • Filteringdeferredtoclientside • All medicationprescribedandreadytobedispensed
Screenshot Dispense items Prescription items
Screenshot Last dispense Activeingredient Last dosage Medicine Entry Prescribingdate
Screenshot Dispenses aggregated Aggregation details (Onedispenselineeachforthe same medicine)
Content Format • Medicationlistis a CDA document • Withuniqueid (forlogging) • With all Dispense itemswithin a given time-frame • With all Prescriptionitemswithin a given time-frame • Noaggregation • Aggregationswill takeplaceatclient • (Possibly) processing: Mapping of „activeingredient ATC“ to „ingredientclass ATC“ • Generated on-demandatrequest • Stored on server-sideforlogging
Howtogetthe CDA document?Implementation options: Variant 1 • Variant 1: Use ITI-18 withdedicateddocumentclass • Client-actorqueries ITI-18 withdedicateddocumentclass „Medicationlist“ assearchcriteria • Backend generatesdocument on-demandandreturnsdocumentreference • Client-actorretrievesdocument • Advantages • Purely just an „implementationscenario“ (fully IHE compliant) • Disadvantages • Whole e-Medicationarchitecturedoes not support ITI-18, but totallyrelieson PHARM-1 (thereforetheydon‘twantto open ITI-18) • Wouldhaveto open ITI-18 just forthispurpose It was a learningduringtheprojectspecificationthat in a Standard CMPD scenario ITI-18 is not necessary (and not recommended), becauseitdoes not deliverrelateddocuments.
Howtogetthe CDA document?Implementation options: Variant 2 • Variant 2: Extend PHARM-1 with a dedicatednewquery „GetMedicationList“ • Client-actorqueries PHARM-1 withnewquery„GetMedicationList“ • Backend generatesdocument on-demandandreturnsdocumentreference • Client-actorretrievesdocument • Advantages • Noneedto open ITI-18 • Pharmacy requestwouldbeplayedby PHARM-1 transaction (whichmakes sense, sinceitis a „Pharmacy-related“ task) • Disadvantages • Not just an „implementationscenario“ -> IHE extensionrequired
Howtogetthe CDA document?Implementation options: Variant 2 • Variant 2: Extend PHARM-1 with a dedicatednewquery „GetMedicationList“ • Client-actorqueries PHARM-1 withquery „GetMedicationList“ • Backend generatesdocument on-demandandreturnsdocumentreference • Client-actorretrievesdocument • Advantages • Noneedto open ITI-18 • Pharmacy requestwouldbeplayedby PHARM-1 transaction (whichmakes sense) • Disadvantages • Not just an „implementationscenario“ -> IHE extensionrequired This istheproject‘sdecision
Wishlistto IHE - First • Content Profile „Pharmacy Medication List (PML)“ • Definesthe CDA documentfortheMedicationlist • Proposalforstructure: • Standard CDA header (like e.g. in Prescription) • First CDA Section „Medicationlist – Dispense items“ • List of Dispense items (unchanged in structure, asderivedfromtheDispense-documentsfound) • Second CDA Section„Medicationlist – Prescriptionitems“ • List ofPrescriptionitems (unchanged in structure, asderivedfromthePrescription-documentsfound)
Wishlistto 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)
Conflictswithcurrent Whitepaper work • Noconflicts • … but ourcurrent Whitepaper workassumesgenericdata-sourcesfor Pharmacy information, whereasthisapproachlimitsitto Pharmacy datasources (Pharmacy repositories) • Due toitsgenericapproachourcurrent Whitepaper workaimsto a generic „Data requestor – Data gatherer“ actortopology • … whereasthisapproachusesthealreadygiven„Community Pharmacy Manager“ asthegatheringactor • Remark: The generic„Data requestor – Data gatherer“ approachhastobeintroducted in ITI (= longprocess), becausethistopologywouldbeusednot only in Pharmacy • Forustoconsider: • Eitherwewaitat least another 2 yearsuntilourgeneric„Data requestor – Data gatherer“ isreadytobeused in Pharmacy • Orweintroducethis „GetMedicationList“ queryas a immediate approachforMedicationlistsforprojectswhichwanttogothatway • Ifthisischosen in the end wehavetopossibilitiesforMedicationlists: • The one limited to Pharmacy domaindatasourcesonly • The „larger“ oneprovidingtheabilityfordatasources outside ofthe Pharmacy domain