Healthcare Product Supply Interoperability Challenges and first steps Presented by Jose Costa Teixeira August 2014

Summary Scope Ongoing work Challenges Process and Deliverables

Scope Support the current clinical flows with the “Supply” dimension. Devices following the same rules as medication Devices: “consumable” devices, implanted devices.. Should also support ancilliary devices like consumables, diagnostic and therapeutic devices.. Flexibility of procedures and flows Software and Devices Vendors Material flows Business and Billing models Operational preferences Legal variations Support emerging operational aspects: Inventory maintenance and optimization Traceability Automatic product identification / authentication Flexible billing

Preliminary/Ongoing work Capture use cases Pharmacy Supply and Catalog Other domains Review literature and existing international guidance Review in IHE DCC for establishing cross-domain work + new domain Preparation HL7 alignment / Change proposals Preparation DICOM supplement (Contrast administration) Submit Work Item proposals Prepare generic architecture Some references (non standards): http://www.saludcastillayleon.es/sanidad/cm/images?idMmedia=110933 http://www.nehta.gov.au/implementation-resources/national-infrastructure/EP-1727-2014

Challenge 1: Clinical + Logistics Clinical and Logistics processes have different perspectives. And they must coexist. There is no clear cut between Logistics and Clinical Flow of information is continuous Several activities may be done on either side Convert internal or Clinical codes into Trade item codes Aggregate several patient orders into one replenishment orders Aggregate / split orders across shipments Most organizations are expected to have mixed flows Consignment + in-house inventory Internal + external product codes Patient-specific + bulk Ordering Different billing models for different item types / suppliers ... These vary per region, per product type... Making an isolated “Logistics” process would not address real issues

Challenge 1: Solution Define pivotal processes, support variations Support activities like “dispense” “prepare” whether they happen at bedside, or in pharmacy. Define a unified international Profile + regional implementation guides

Challenge 2: Several Standards involved Types of standards Interoperability Catalog of medicinal products Logistic data exchange Inventory Control Supply Management Ordering Consumptions Operational support (e.g. Billing) AIDC With semantics, international Barcodes (e.g. GTIN) RFIDs... Without semantics Barcodes (proprietary / internal numbering) AIDC: Automatic Identification and Data Capture AIDC = Automatic Identification and data capture

Challenge 2: Solution Profile standards (one of the key goals of IHE) Align where needed (e.g. Harmonizations, CPs) Define IHE model, detached from any specifics of the standards Validate with key standards

Profiling example – Hospital Supply HL7 v2 Wide adoption in Hospital systems Message-based GS1 Growing adoption in Healthcare logistics Identification and message based Broad scope GS1-HL7 collaboration in place (MoU,...) Different standards have different scopes and architectures, so an alignment is needed MoU – Memo of Understanding between HL7 and GS1

Usage report & tracking Predominant standards (typical) Logistics (GS1) Clinical (HL7) Profiling summary example – WIP Dispensing Systems Manufacturer Distributor Hospital Point of care Catalog maintenance Selection of vendors | Pricing & Contracts | Update product data Internal data (Clinical data, internal prices, usage rules, usage instructions) Consult product data Inventory management Availability and recall Permissions, availability, recall Orders and returns Stock orders and bulk orders Point of care ordering & order processing Consignment items Usage report & tracking Consignment items Patient usage Stock status, consumption Billing Patient charges / intra-hospital charges Hospital billing

Continuity of Interoperability Given the overlap of scope, the transition across standards must be continuous. i.e. The profiles must ensure that the transition from e.g. HL7 to GS1 can happen in different points in the same process chain Solution is to have one single interoperability architecture that can be implemented with different standards

Preliminary results1 (WIP) Transaction Name GS1 XML v3.1 HL7 v2 .8 2 CAT-1 Catalog update request 3 CAT-2 Catalog update Item Data Notification MFN (WIP*) SUP-1 Supply Order Order RDE / OMS SUP-2 Order response Order Response WIP SUP-3 Dispense notice Dispatch Advice RDS SUP-4 Reception notice Receiving Advice SUP-5 Consumption report Consumption Report RDS (WIP) INV-1 Refill request Replenishment request OMS INV-2 Stock refill proposal Replenishment proposal N/A INV-3 Inventory query MFN? (WIP) INV-4 Inventory update INVRPT *Work In Progress 1 Based on current work, these transactions should consist the basic building blocks for a working profile 2 Only as of v2.6 does HL7 have some of the mandatory mechanisms. V2.9 can be expected to incorporate present work 2 Profiling work in progress

Challenge 3: Traceability & Privacy Full traceability is great but... Is an additional constraint in order handling e.g. Aggregating orders for several patients may break traceability Is a special constrain in the delivery process Keep item identification from source to use May collide with privacy concerns Use of specific (individualized) device or medication may expose private information. This information must therefore be protected.

Challenge 3: Traceability & Privacy Answer: Traceability and Privacy must be built-in, not “extra” transactions. Reusing ATNA and other IHE (ITI) recommendations Providing guidance for use

Challenge 4: Very big scope Solution: iterative design (IHE way) Start with well established models and needs. Define an architecture which Covers current needs Is expandable to foreseeable cases The results consists in using IHE as a methodology

Process and deliverables Collect known needs from use cases Delivery: White papers (IHE Pharmacy) Supply Catalog Define and publish Architecture Delivery: Technical Framework(s) (IHE Pharmacy, other domains) Define national extensions (Deployment committees) Delivery: National extentions (TF Vol. 4) Validate (Connectathon) and iterate

Cross-profile and Cross-domain PHARM HMW: Supply Mechanisms are foreseen PHARM CMPD: No overlap (supply is from Pharmacy to Vendor) RAD SWF: Integrated with SWF – New whitepaper proposed August 2014, deferred to 2015 Others TBD (part of the work) No comment

Conclusion / next steps IHE Whitepapers Proposal (Done) Acceptance (Done) Writing (WIP) Publication Technical framework Acceptance Alignment with other domains Writing (started in parallel with HMW) Next: As described for Challenge 4: Delimit the scope for a first deliverable, and advance on supply frameworks Work cycle 2014-2015 of IHE international

Healthcare Product Supply Diagnosis or therapy usually requires products: Medication, devices, consumables, nutrition products… These products are explicitly requested or implicitly expected. But a lot has to happen in the background for this to happen Clinical workflows are not isolated from the management of these products and their supply and lifecycle (availability, traceability…) We propose to handle the interoperability concerns of supply of health products

Example Use Cases Management of inventory, expired products… Traceability What items/batches have been given to patient X? Which patients have been given batch ABC? When ordering a product, physician considers availability …

Opportunity Increasing awareness – traceability for patient safety, counterfeit drugs, operational efficiency There are norms and guidance (e.g. GS1, HL7…) Supply seems a side concern for most profiles Pharmacy has an intrinsic concern – Usually pharmacies handle most materials, not only medication. Other domains have their workflow – This diversity should be respected IHE Pharmacy is outlining a vision, and does not want to go alone Only by bridging to other domains can improvement be optimal: For the patient For the institutions

Goal Define an interoperability framework for supply, enabling: Better patient safety by better information Better management of operations Close the gap between supplier and patient Enable healthcare processes to be compatible with supply solutions and best practices Integrate supply of medical products with the rest of enterprise interoperability

Integration with a clinical process (example) Clinical path Order Processing / validation Preparation Administration Transport, inventory mgmt, product identification Besides supporting the procurement, purchase, labelling, distribution and preparation… We can also integrate these concerns into the “clinical” process. Purchasing… Purchasing… Materials path

Inside / outside logistics For IHE, focus on the enterprise (institution, or group of institutions). Articulate with – not redo – the supply mechanisms outside the institution

Scope Supply (e.g. of medication) Supply of Healthcare products Supporting all expected distribution rules Nominal/bulk dispense, consignment, ordered or ad-hoc Supply of Healthcare products Medication (obvious need) Supporting / Extendable to all expected product types Medical devices Nutrition products Other consumables Non-traceable, batch- or serial-traceable. Support other products and flows beyond “order” or “prescription” Articulate with formulary / catalog; articulate with billing Analyse (keeping flexibility) product coding, barcoding, RFID… Enable best practices, not depend on them Gather much existing knowledge into applicable guidance

Scope exclusions Should not define rules like “How to calculate ideal stock levels” => concepts like “refill when stock reaches minimum” are use cases, not design constraints. Assuming them as universal would harm the model Should not hardcode other business rules that may change with Location Regulation Product type Defining a business model is out of scope. We should provide support for communication. “Anchor” or limit any freedom from supply chain or data is not good for interoperability - innovative models or views will exist and should be supported. Should not replace formulary or catalog of items/services. Must not enforce or block any billing options

Use Cases “Simple” order – supply (e.g. medication) Forward and reverse traceability Extra: support product recall Internal redistribution (inventory balancing) Product replacement In daily operations due to shortage After new purchase contract Give the prescriber visibility about supply Determine whether supply is limited (easy for medication, more complex for long lead time products, or perishable items)

Business Vision Full bidirectional traceability Identify shortage before ordering Predict shortages before they happen Review purchasing based on actual consumption Allowing finer-grained forecasts? Easy and safer identification of the right product

Changing the Way Healthcare CONNECTS http://www.ihe.net