Pharm Tech Minutes 2010.06.07-08

Day 1 Notes : Monday : HMW profile development

Day 1 Attendees

• Ana Estelrich

member of normalisation mission of GIP-DMP

co-chair of IHE QRPH (Quality, Research and Public Health) domain.

• Charles Rica

member of Normalisation mission of GIP-DMP

co-chair of HL7 France CDA group.

• Thierry Geraud

Pyxis cabinets, Carefusion.

• Geert Claeys

Agfa Healthcare, Belgium.

• Jürgen Branstätter

CodeWerk, Standardization, Austria

On behalf of Franz Pfeifer, Vendor Cochair (excused)

CMPD editor

• Jose Costa Teixeira

Agfa Healthcare, Portugal

HMW editor

• Orlando Rodrigues

Glintths, Portugal

• Michiel Sprenger

Nictiz, the Netherlands

• Simon Letellier

IHE Pharmacy secretary, Hospital Pharmacist, France

Introduction

Work on the Technical Framework :

- volume 1 Integration profiles & volume 2 Transactions

Jürgen introduce the structure of the TF documents in 3 parts . the table 1 is very important : link Volume 1 and Volume 2 , the detailled transactions.

8 transactions [PHARM-1] to [PHARM-8]

Transactions can be used by ( max. 7 ) differents actors.

1) CMPD discussion

Introduce the new actor Pharmacy document registry :

Glue together repository and registry.

XDS is eb-XML

Define the interface of the interface for the PR (prescription repository) if it's possible to query a "black box" : XDS or something else like a DB (database)

Blackbox have to support the complexity , to know how and where integrate datas.

Interfaces are the crucial point.

Registries are in a repository. Interface (XDS based or not) is at the entry of the repository.

Registries are databases.

Labelleing the document ? in order to do it (pharmaceutical advise) validated. Use status on prescription document.

Link between the different items ?

2) HWM profile

• Status on documents are not necessary : messages based. Status are implicit.

Messages are not send until validation, change of status in the workflow.

• Postscription : prescription after administration

use case usefull for Pyxis cabinet in ICU not present in the White Paper.

• Addition of OMS : HL7v2 message request for refill cabinets.

Not necessary against business /stock refill rules. Define triggers !

• Trigger from nurse report (stock order)

Something the pharmacy already known the stock levels ans the needs for the next weeks (based on prescriptions).

• Introduce administration report send to Pharmaceutical adviser to inform pharmacist (human actor) which medications are really administer to the patient.

• Discussion on "medication aviability" ==> it's the dispense report

It's what needed for cabinet management.

• Check the IHE's "Security Cookbook" for security issues

• Looking for a common Master Model for HMW.

3) Back to CMPD profile

• Ref : volume 3 Content Specifications

Discussion about page 13 of TF volume 3

• Management of medication items inside each prescription:

• How pharmaceutical advisor validate the prescription items

links between prescription, pharmaceutical advise and dispense.

• Looking for ITI specifications

Decisions

• Maintain prescription as a document

• Workflow will not be really defined (rules management)

• Rules to retrieve a single prescription item.

• "Define a proposal for ITI" ,

Day 2 Notes : Tuesday : CMPD profile development

Day 2 attendees

• Jacqueline Surugue

IHE Pharmacy User Cochair, Hospital Pharmacist, France

• Ana Estelrich

member of normalisation mission of GIP-DMP

co-chair of IHE QRPH (Quality, Research and Public Health) domain.

• Charles Rica

member of Normalisation mission of GIP-DMP

co-chair of HL7 France CDA group.

• Geert Claeys

Agfa Healthcare, Belgium.

• Jürgen Branstätter

CodeWerk, Standardization, Austria

On behalf of Franz Pfeifer, Vendor Cochair (excused)

CMPD editor

• Jose Costa Teixeira

Agfa Healthcare, Portugal

HMW editor

• Orlando Rodrigues

Glintths, Portugal

• Michiel Sprenger

Nictiz, the Netherlands

• Simon Letellier

IHE Pharmacy secretary, Hospital Pharmacist, France

• Viktor Hafner

Community Pharmacist, Austria

Discussions

Organization of a Skype call with Vassil Peytchev, IHE ITI, Epic Systems

How to organize the Technical Framework documents ?

Community and Hospital are using the same Model.

A CDA definition use the Model to define the Community Medication Prescription and Dispense.

A HL7v2 messages definition use the Model to define the HMW profile.

The Model will be located in the TF itself, it's a Content profile, the base of the CDA specification as well as the message specifications, but not an implementable profile.

Work on the Technical Framework :

- volume 1 Integration profiles

- volume 2 Transactions

- ITI-18 Registry Stored Query, - ITI-41 Provide and Register Document Set-b & - ITI-43 Retrieve Document Set

for XDS query and retrieve datas, can be implemented either as : XDS or databases - volume 3 Content Specifications

IHE Pharmacy Planning committee

- Roadmap

- Communications

- IHE 2010 webinars serie

Minutes

General decisions

What profiles shall be produced

The model will be located in the TF itself.

Rational: it’s the base of the CDA Content Specifications as well as the message specifications, but not an implementable profile itself

Content Profiles (derived from the model)

• CDA Prescription
• CDA Pharmaceutical Advice
• CDA Dispense

Integration Profiles

• CMPD: referring to the Content Profiles
• HMW: embedding the content specifications for the messages (which are derived also from the model)

What documents shall actually be produced

One “common” document, including common descriptions of pharmacy

the model

Supplements

• CMPD (Integration profile)
• HMW (Integration profile)
• Prescription (Content profile, new!)
• Pharmaceutical Advice (Content profile, new!)
• Dispense (Content profile, new!)

The content of the current documents will be transferred and the new documents will be sent out to the group. The current documents will be kept in background for later processing.

Rational

The voting procedure is “per profile”.

To prevent a situation, that all profiles have to be accepted at once, the splitting into separate documents according to the IHE rules will be performed.

Decisions for Hospital Pharmacy

Standard to use

Decision : HL7 v2.5

May require Z segments (that is the purpose of IHE)

Rationale

• HL7 V3 is not available for trial implementation
• Semantics and interoperability model will be made independent from the messaging model to facilitate transitions

Document-based vs Message-based architecture

Message-based architecture

Rational

In a Message-based architecture, Status (and sub-status if cascading needed) is implicit by message location (e.g. RAS=Administration).

Validity of the model

Keep transaction PHARM-H3 between prescription placer and Dispenser (as well as for administration), because of the parallel modes. This is described in the whitepaper. This supports parallel and sequential modes. In parallel modes, “Validation” is seen as a “GO”, and it is required to proceed.

For medication that does not need validation, or where validation is not possible (a posteriori validation): Validation still exists, but it is default true.

A posteriori validation would thus be simply shown to the pharmacist in a list of prescriptions to be validated.

• To confirm with Isabelle Gibaud – PHARM-H1, PHARM-H2, PHARM-H3 are for different purposes.

An “Encoding” sub-process (at an atomic level) may be foreseen for the “active substance prescription” to keep model integrity.

Medication Availability

Is really a “Dispense Report”

Partial delivery

Dispensing report indicates the amount dispensed. The prescription placer is responsible for keeping track of the status of the order dispensing.

The split between Community and Hospital should be reduced as needed

Retrocession

Different software applications running for the same patient (e.g. Medication module, chemotherapy, Operating Theatre… )

Security

Decision

We’ll check the Security Cookbook

Data model consistancy

Decision

Add the link between Dispense item and Pharmaceutical Advice.

Metadata and common data structures for interoperability

Need

Common vocabulary to ensure interoperability

Decision

Coding system information is mandatory. It is not mandatory for the compliant applications to share the same coding system. –

Example medication:

Drug or Product ID = 00001 Paracetamol 500 mg = Drug or Product Name (optional) Coding system = UCD

Receiving Application

Coding system	Received Product ID	IHE-Compliant	Will work
PZN	00001^Paracetamol 500 mg	No	?
PZN	00001^Paracetamol 500 mg^UCD	YES	NO
UCD	00001^Paracetamol 500 mg^UCD	YES	YES
UCD	00001^ ^UCD	TBD	YES

At the end, we will check the terminology between real-world and HL7 terms.

Decisions for Community Pharmacy

Proposed Status Management mechanism will be excluded

Question

Keep to the proposed status mechanism stated in chapter PHARM-TF3:3?

Decision

• The proposed mechanism for status management will be excluded from the TF.
• The actors and transactions will be stated as standard XDS Source/Consumer transactions.
• No status information will be published into the metadata.
• No constraints will be made how implementers shall use or not use document associations when submitting documents.

Rationale

• Status management is decided also to be counted to “Workflow”, which already has been handed over to ITI to bring up a general solution for all ordering tasks (e.g. Lab, Referral, Pharmacy, ...).
• The proposed solution would be yet another way of doing workflow/status management with XDS and can’t be considered as the way ITI will decide to specify it.
• Indirect influencing of ITI in their decision shall be avoided.
• The ITI taskforce of working out this work package shall be strengthened.

Advantages

• By not using document associations implementers can build systems for working also on cross-community (not only single domain)

Disadvantages

• By missing the workflow/status part the profile can’t be considered as complete. The dependency on ITI causes this status to be held up for an uncertain time.
• The status of documents is stated in the document content only. Also the relation between documents (e.g. which dispense belongs to which prescription) is stated in the document content only. By that implementers are forced to always retrieve all documents (Prescription, Advice, Dispense) for a patient and to parse and analyze the relations between them before the actual status of the prescription can be determined.

Repository actors shall implement both query and retrieve transactions

Question

In XDS systems query transaction target a “registry” and submit and retrieve transaction target a “repository”. Shall the repository actors (of the whitepaper) be divided into XDS registry and repository actors to be more aligned to XDS? If combining these two, users or vendors who already implemented database solutions would not be affronted by restricting the specification to XDS.

Decision

• No, the actors shall stay divided into registry and repository
• Two separate actors shall be defined for each document type
• e.g. Prescription repository, Prescription registry

• At least the following transactions shall be covered:

Prescription / Pharmaceutical advice / Dispense REGISTRY Registry Stored Query, ITI-18

• Prescription / Pharmaceutical advice / Dispense REPOSITORY

Provide and Register Document Set-b, ITI-41 Retrieve Document Set, ITI-43

• An explaining chapter shall be included which summarizes the implantation possibilities when using XDS, Database or other systems.
• Actor names stay like they are, but there are no own transactions for community

Direct referencing to the ITI XDS transaction

Rationale

• The combination of these two causes problems in terms of flexibility of topologies

Open Issue

• Shall these actors also provide all other XDS related transaction necessary for having a functional XDS registry/repository system (e.g. like “Register document, ITI-42” for a repository)?

Decision

This decision is postponed to later. The documents shall be created with the essential transactions in the first step. By having that the decision is easier, if the other transactions are necessary as well.

List of possible statuses

Question

The list of statuses in the whitepaper does not show exactly, which statuses belong to each document type. Furthermore the detailed work on the profile revealed that there is the possible need of additional statuses. What is the exact list of possible document statuses per document?

Decision

The list of statuses per document is a subsequent result of the possible situations which can appear according to the use-cases. Jürgen and Jose will work out a complete set of statuses per document type, which is correct from an informatics point of view and covers all situations. This list is presented to the group for final discussion.