• José Costa Teixeira January 2015

Medication DataCapture 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 sourcesof 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

othersUsing this interoperability model, each dimension has its

clear meaning and expected data.

Data can be decomposed in its

Components.

Dispenses are dispensesOrders 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)