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
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.