José Costa Teixeira January 2015 Medication Data Capture and Management

Typically a medication list is provided by the patient in a form of an aggregated list. But there are opportunities: 1.A world of data that can be captured, which can support new applications Pharmacovigilance Medication falsification Traceability 2.A growing number of applications, contexts, visualisations, that can benefit from enriched data. Vision

Looking at work from other domains, we know how to exchange, reconcile... aggregated lists of medication Some applications may require some details that we can help capture, and reuse the current work for our purposes We deal with the details, and reuse current work Expected outcome

Medication Documentation: Capture and exchange of medication details Vision

This is not a Patient Record... We do not want to re-analyse “what is the data needed to support the medication processes”. We want to focus on the medication details – The “backstage” of the medication lists – Allergies, lab results, etc. are elsewhere

...this is not a list There is no universal, complete format for “List of patient’s medications” A summary list exists and is based on definitions / assumptions: – A certain scope: e.g. Help professionals understand “what medication is the patient on” to infer conclusions – Intended use (e.g. Short summary vs detailed list) – A certain period of time (e.g. “recent”, “active”, etc) – Existing data (e.g. Prescriptions, Dispenses)

How to feed a list Summary lists are good for their purpose – They can be exchanged*, and they provide a set of data that addresses the expected needs – How are these lists created? Patient-provided description Using available data (Prescriptions, Dispenses,...) In Pharmacy, we can look at HOW to build such lists Goal 1: What data can be captured to feed such a list, and the data conditioning necessary

Goal 1: Data capture Overview of data sources and types that can be used to feed a “list” of medication – Prescription data (including details) – Dispense data (including details) – Administration data (including details) –......And what is needed to know to feed such a list (independent of what that list is) – Consistency of data Patient ID, product ID...

The list must be created and exchanged PCC (Incl. DAF) explains mechanisms and containers to exchange summary lists We also look at cross-context interoperability, exchanging lists where the assumptions (data, filters, intended use) may differ

Goal 2 *Exchange of medication lists – For summary lists: Exchange of medication summary lists must rely on same assumptions on both ends: Exchanging/reconciling a summary based on “dispenses” and one based on “prescriptions” has risks. – Unless we know what type of data they contain: Dispenses or Prescriptions Definitions of “active”, or “recent” must be compatible, or there are risks How to exchange non-summary lists, or cross- context lists?

Goal 2: Support interoperability of any medication list By finding the “primary” elements of such a list: – Exchange data that is not subject to assumptions Administration has clear meaning: Patient took the medication Prescription is also clear and different from Dispense... – Abstract from intended use Maybe a summary for display (limited data) Or maybe a source for rich data visualisation Or maybe for cross-patient studies : farmacovigilance, adherence, etc.

Guidelines Preserve original data, when making summaries and assumptions (not unlike compressed images in RAD) Exchange semantically correct data

Where is medication data NCPDP SCRIPT CCR IHE Pharm Others HL7 Immunization IG These (should) fit together. e.g. HL7 immunization contains taken and expected immunization doses. In CCR, the planned medication is present. While “planned” and “expected” may be combined, the same may not be true with “taken”. Exchanging data across several sources should Be possible! Not alter the original context/meaning NCPDP LIST

Summary lists NCPDP SCRIPT CCR IHE Pharm Others HL7 Immunization IG * * * * = Format as medication list (incl assumptions) Using this interoperability model, a common format exists, assuming that the different sources of data are “transformed” into that format. Some data may be lost Use of data collected from this model is conditioned to the choices in the source

Medication Documentation – Capture and exchange of medication details NCPDP LIST CCR IHE Pharm Others HL7 Immunization IG Dispensed Ordered Administered others Using this interoperability model, each dimension has its clear meaning and expected data. Data can be decomposed in its Components. Dispenses are dispenses Orders are orders Several models co-exist Any data exchange will preserve the original meaning NCPDP LIST contains DISPENSED medications (TBC) CCR informs “Prescribed” medication (TBC) IHE handles prescription, dispense and administration separately Immunization contains Planned and Administered

Approach To interchange across different data containers… …define the data exchange primary dimensions Formalize the requirements for interoperability Examples of uses: – NCPDP dispenses can linearly be combined (added / compared) with HL7/IHE dispenses – CCR prescription data can be combined with IHE documents by using IHE prescription data, not combining (but eventually preserving) IHE dispense data. – Data that is not of the same type can still be collected, but implementers should be aware that processing may be needed. – Processing may be automated or manual. This depends on a set of rules Do not try to define new “boxes” for the processes for creating or using the data – E.g. Reconciliation can be done with existing methods (RECON). This is simply a harmonization of the content that feeds reconciliation. Not a new process, data source, or model. Harmonization and awareness work

Outcomes Definition (and requirements) for a semantically exact container for medication data – A la “Data Vault” – Already Profiled in PHARM Medication List Requirements for – Where to collect data – Nice-to-knows for processing (aggregating, filtering) the data

Opportunities Support new repositories – ISO Dispense Record –... Reuse DAF for federation of data, bypassing the cross-context interoperability concerns

Impact Explain Medication list details – Enable implementers to use a summary or a detailed list Reuse of DAF – summary (as is ) or detailed (with link to detailed lists)