Pharm Tech Minutes 2011.10.04

To see the next day's minutes go to Pharm Tech Minutes 2011.10.05

Attendees

• Bourquard, Karima (IN-SYSTEM)
• Brandstätter, Jürgen (CodeWerk Software Services and Development GmbH)
• Canu, Nicolas (Phast)
• Cocchiglia, Arianna (Arsenal IT)
• Costa Teixeira, Jose (AGFA)
• De Jong, Tom (Nova Pro)
• Demarmels, Marco (Lake Griffin, LLC)
• Estelrich, Ana (Phast)
• Gengler, Winfried (Epic)
• Géraud, Thierry (CareFusion)
• Gibaud, Isabelle (Syndicat Interhospitalier de Bretagne - SIB)
• Lefebvre, Nicolas (INRIA)
• Letellier, Simon (EAHP)
• Parisot, Charles (GE)
• Poiseau, Eric (INRIA)
• Rica, Charles (ASIP Santé)
• Robberecht, Marc (AGFA)
• Robertson, Scott (Kaiser Permanente)
• Rodrigues, Orlando (Glintt - Heatlhcare Solutions, S.A)
• Sprenger, Michiel (Nictiz)
• Surugue, Jacqueline (EAHP)
• Tzimis, Leonidas (EAHP)
• Zalunardo, Luca (Arsenal IT)

By WebEx:

• Peytchev, Vassil (Epic)
• Sebastião Silva (Coimbra University Hospital)

Overview of the Agenda

The Pharm Tech Agenda 2011.10.04 was reviewed.

Workitems: Status overview

A brief status overview was given by each of the main responsible person

Introduction to the Principles of Governance

The domain is undergoing a transition phase with the intention to align with the IHE International processes. Principles of Governance. Several Pharmacy Domain Operations must be decided upon. Please look at the roster and get back to the IHE Pharmacy list with corrections.

The roster is available at: Pharmacy Planning and Technical Roster.

The roster must be discused with the IHE International Board.

Definition of a Change Proposal - an informative note

A Change Proposal (CP) is a formal way of proposing a change to a text published by an IHE Domain and which has been publishe as a Supplement. When a text is published as a supplement, the vendors have already implemented it and the changes requested will affect everybody who has implemented the text. A change in the formal text is proposed using the CP IHE format.

The CP presentation in the Pharmacy folder contains a CP Processes Presentation. The actions around a change proposal are the following:

1. Change proposals are submitted to the committee co-chairs and the whole domain for information.

2. The committee periodically reviews the submitted change proposals, and either marks them rejected, or assigned to a member of the domain committee for further investigation with the goal to produce adequate clarifications or corrections to be applied to the document being updated.

3. If, after assignment, there is a reason for a CP not to be completed (it is withdrawn, combined with another CP, etc.) the CP is cancelled and archived with an explanation of the reason for cancellation

4. A completed Change Proposal has been reviewed and the editing judged complete by the Domain. Completed Change Proposals are then published as a letter/email ballot according to the rules presented earlier

5. Negative votes or issues raised must be resolved by the domain, and may result in the Change Proposal going back to an assigned or receiving cancelled status. Once a change proposal has passed ballot and the comments have been resolved, it is published as final text and considered effective

6. As part of the yearly publishing process, CPs in final text get incorporated in the corresponding supplement or technical framework. Implementers should base their work on all three of the following:

• the current version of a Technical Framework
• the current version of relevant Supplements for Trial Implementation
• all final text Change Proposals to the Technical Framework or Supplements

CP for CMPD to incorporate XDW

The discussion on how to use workflow management for the Pharmacy domain. The proposal consists of a new section of the CMPD with an option to use the workflow management. Luca Zalunardo (Arsenal IT) did an updated XDW presentation.

The following things were looked at:

• How a different action can update the different work
• How each task is related to each other
• What are the actors that can be related to the each other. An option was added to the profile instead of modifying the workflow manager. This will be describe in the introduction in the CMPD and discussed in the text of the profile.
• Review of the poposed changes to CMPD resulting in the Pharmacy CP018.

Question: is CP018 concerning the XDW profile as applied to Pharmacy is ready for the upcoming ballot?

• The prescription has prescription items and this must be reflected.
• The business rules must be integrated.

The workflow document is exchanged between different actors registered in the WF doc and each task has to be been done by each actor and can have a status. The structure of the workflow document was presented (see presentation). These profiles support any kind of identification – NAV for example. The insfrastructure in the XDS will support these functions. This will be tested in May at the Connectathon, and there will be a pilot implementation in January in Chicago.

Suggestions

• 3 weeks to prepare a second verion of the CP with 3 editors – Luca, Arianna, Jurgen, organize 1 hrs t-confs for 3 weeks, done by Nov 25th, approved by December 10th.
• Push it into the next cycle, not a CP, but a supplement – assign it appropriate ressources

CP for PRE/PADV/DIS

The next change proposals concering the content profiles PRE, PADV and DIP were revised. The CPs are present at ftp://ftp.ihe.net/Pharmacy/TF_Maintenance-2011/CPs/Ballots/Ballot-1_v2/Ballot-1_v2.zip. Each CP was explained (see the fpt), schedules was discussed, decision to extend the deadline as per requested from Tom (30 days period, send out the new link after the meeting).

• CP001 - General revision of profile in the PRESCRIPTION Content Profile published in December 2010.
  • Remove the last paragraph in the Patient Medication Instructions as the described use-case in this paragraph can only happen at the point of dispense and when the prescription item is used in a Dispense document.
  • Remove the Fulfillment Instructions based on the same rationale as above
  • Add two templateIds required by the IHE Medications Entry (1.3.6.1.4.1.19376.1.5.3.1.4.7) to indicate that the manufacturedProduct follows the IHE Product Entry specification (1.3.6.1.4.1.19376.1.5.3.1.4.7.2) which is a specialisation of the HL7 rootId
  • Changing from SHOULD to SHALL the Medication Code
  • Changing from SHOULD to SHALL the Medication Brand Name
    • SHOULD in IHE vocabulary is considered "must be filled in if available (R2), SHALL is mandatory and it must be present (R)
  • Changing from "form of the medication" to "pharmaceutical dose form"
  • <pharm:formCode> element represents the form of the package (e.g. tablet container, bottle, ...)
  • Suggest that the Active Ingredient should be ATC

• CP002 - Medicine Entry: Reduce optionality of formCode of medication and package to SHOULD in the PRESCRIPTION Content Profile published in December 2010.
  • Medication Form Code SHOULD be present (instead of SHALL) if not implied by the product. It MAY be present if implied by the product.
  • With regards to packaging: the <pharm:formCode> element SHOULD be present(instead of SHALL), if not implied by the product. It MAY be present if implied by the product. These changes arise to the fact that the requirement that the formCode for either medication and package to be present in a Medicine Entry is too strong. Prescription modules may use medication databases which don’t have this information available. In this case the strict requirement of this information would require the physician to manually add this information at the point of prescription which is impracticable in reality.
  • CP modified in order to better explain the concept, v2 produced

• CP003 - Lower constraint to use UCUM to SHOULD in the PRESCRIPTION and DISPENSATION Content Profiles published in December 2010
  • The strong constraint to UCUM is not crucial for the design to be successful interoperable, it’s sufficient if the domain agrees on a common terminology for units. UCUM is not the only accepted terminology for units, the profile has to be open for other terminologies. The optionality should be lowered from a requirement (SHALL - R) to a recommendation (SHOULD - R2).
  • Tom de Jong indicated that for datatypes R1 only UCUM codes can be used see link link
  • CP withdrawn

• CP004 - General revision of profile in the DISPENSATION Content Profile published in December 2010
  • Revision of the profile removing typos, wrong formats and errors in the specification of the document that would violate the schema or the underlying templates
  • Changes on wording, replacing person with HCP (healthcare professional)
  • The description of the "Quantity Value" has been changed and explained in the same manner as in chapter “Amount of units of the consumable to dispense” in the PRE profile.
  • Edit the "Patient Medication Instructions" and added the last paragraph which was wrongly located in the PRE profile (therefor missing in the DIS profile). Also a typo is corrected (<substanceAdministration> instead of <supply>)
  • Edit the "Fulfillment Instructions" and added the last paragraph which was wrongly located in the PRE profile (therefor missing in the DIS profile). Also the cardinality 0..1 of this element is expressed better - "At most one entry relationship MAY be present to provide the fulfillment instructions."
• CP005 - DISPENSATION Content Profile - New element to indicate that a substitution has taken place at dispense as suggested by HL7.
  • A second version of the CP was submitted for ballot containing the corresponding new XML code.

• CP006 - add Reference to “reason” of Prescription Entry Items in the DISPENSATION AND PHARMACEUTICAL ADVICE Content Profiles published in December 2010.
  • The PRE document includes reasons for the use of the medication via the "“Internal Reference Entry”. This manner of use is acceptable when it is used in the prescription.
  • When a reason is neede in a Pharmaceutical Advice or a Dispensation, it needs to be linked to the Prescription Item so that the information is not lost. Changes in structure to the PADV and DIS were proposed.
• CP007 - General revision of profile in the PHARMACEUTICAL ADVICE Content profile published in December 2010
  • Revision of the profile removing typos, wrong formats and errors in the specification of the document that would violate the schema or the underlying templates
  • Change person to HCP (Healthcare Professional)

Whitepaper: Medication Documentation

• Medication Documentation Overall Presentation

Distributed information, not everything will be available at once. We will not have all the information available all the time, when needed it so some compromise must be done.The medication information is not 100% reliable.

• Identify what information we have available and the different sources it can come from:
  • PRE, PADV, DIS
  • Medication Statement - and this can have conflicting information, especially in the Community Pharmacy
  • The information is not entirely accurate, the person requesting the information has to make a judgement with regards to the reliability of the data
  • The dispense might contradict the prescription.
  • Harmonization - the data must be harmonized, indicating their source
  • Look at queries - how can we get data from whatever source available and how can we extract the data from the collection of data into other types of information in order to harmonize it.
    • Can this be transformed into another kind of informations - The ER might collect patient patient information medication.
    • This already collected information can be used by another user in the hospital so the same action does not have to be done.
  • What is current medication? This is based on local policies.
• The data can be stored already prepared in the local repositories and this data can be exported to someone who would want more complete information (allergies, contraindications)
• Can we use QED? Propose ways of querying using QED

Comments

• Tom will contribute the next day for the joint meeting HL7/IHE
• Vassil asked to go to the first slide - we want to focus on the interoperability aspect of the information and not on application. Look at the first slide:
  • Before - “Query an unknown repository of the patient’s medication history”
  • To - “Define how can the patient’s medication history be documented”
• It is important not to indicate application behaviours but on the interoperability aspects
• Identifying the data sources - messages and documents.
• We want to be very clear this is how we exchange information. We cannot imply things about system, and we must be clear this is how we exchange information focusing on functionality. If we say how is it documented, it might lead to Clinical Documentation which is separate topic and out of scope.
• On the identifying the data sources: Pharmacy documents, messages, and additional sources. Suggestion - start the white paper with the use cases (traditional IHE approach):
  • Case 1: Data sources - one data source - Pharmacy having the actual information
  • Case 2: Clinical system with a physician order-entry because that information itself might be data source itself
  • Case 3: Another data source can be a personal health record may already have gathered information from different sources and it can be a source of information itself.

Agreement on:

• Start with use-cases.
• The paper is too Pharmacy-centric and information can be obtained from other sources.
• Confusion between describing wide use-cases and engaging other domains.

Other ideas:

• The same structure applies in the operation theatres - would this qualify as a Medication Statement?
• Describe the benefit to this paper. It would be useful to consider the setting where this takes place (community vs.hospital)
• Clarify the scope and the approach by describing the use-cases, add the clinical benefit to the use cases in the discussion.
• The result of the discussion call that we had on the white-paper
  • The sources
  • The common structure used for interoperability
  • How can we get the data

The use cases can show reasons where the data has interoperability value outside the query environment. Instead of taking QED, take things step by step and understand where the focus is and how it impacts the patient-care. Better to focus on the use cases rather then focus on the mechanism.

Going over the paper and explaining it. Latest version of the paper is available at: [Medication Documentation v0.4]

• Can this be compared to gathering the data concerned with the Radiation Exposure? Perhaps too early in the paper.

To be discussed tomorrow (Oct 5th, 2011 in the joint HL7/IHE meeting for other points of view).

Whitepaper: Use-case: Community – Hospital

Sebastiao Ferreira da Silva (Coimbra University) presenting (work with Orlando Rodrigues) The paper discussed is available at: Community and Hospital Pharmacy Interactions Whitepaper

The white paper will show sothe interface between the hospital and the ambulatory dispensing. The interactions between the drugs that are dispensed to the patient. There are 3 use cases: 1. Hospital specific medications is dispensed to a patient as an inpatient and then as an outpatient, in order to fullfil a prescription that has been produced in the hospital setting, and then the pharmacotherapy continues as an outpatient.

2. This use case shows how a prescription that has been produced in the hospital setting is divided into two branches. One that is going to be dispensed it the community pharmacy and the other that is going to result in the administration of the medication in the day hospital.

3. This use case shows a patient being admitted to a hospital in result of a heart attack and the changes this event had on the patient’s pharmacotherapeutic profile.

These use cases should trigger change proposals or implementation guidelines for Community and Hospital Pharmacy, as well as presenting a good starting point for a complex workflow management.

Comments

• Can these use cases be useful in XDW?
• Most of the paper is focused on the hospital side - hand off to the community? How about the inverse? We can broaden the scope.
• Information recorded in two places - hopital and community repository, the information is recorded twice.
• How can you pull in multiple sources together? This is splitting of a workflow.
• The total information collected must be considered.
• Dealing with duplicate information is normal since we needed it in two places
• The prescription has an owner, whoever modifies the information has to take resposibility
• Can the scope of this whitepaper be narrowed to the processes and concentrate on the cross-border between hospital and community
• In Austria they are two different worlds - a prescription written in a hospital is not valid in the community.
• Leonidas- first use case is an out-patient, becomes in-patient and then becomes an out-patient again (orphan drugs can only dispensed in the hospital). The second case the patient is an out-patient and the group tried to reconcile this with the out-patient.
• Sebastiao - these worlds should communicate better since when patients are admitted it is difficult to get this information, and when the patient gets discharged the physician has to make an effort to find out what the patient was administered when in the hospital. The transition should be smooth.
• Jurgen - a patient has a community prescrition, it would nice if we can split it in two and continue the patient's treatment in the hospital. It would nice to be able to query the patient's medication. This is not a real cross-over between the two.
• Michiel - different situations in different countries - some countries are very strict and some where the medication is allowed in the hospital from the community. For day care surgery is a cross-over situation and there is no real distinction, and we must deal with the differences.
• The hospital pharmacy will integrate the drug that the patient is taking in some cases.
• Thierry - in a hospital we are in a day to day operation mode that is different than what is outside hospital.
• Ideally we should have a central repository but this is not the case. The medical information for complex cases of pathologies is very difficult.

Please verify if the document on the ftp is the right one

PCD Joint Activities

Infusion Pump Event Communication Profile and Pharmacy

The PCD domain was contacted with regards to the infusion pump topic during summer. The PCD profile in question is IPEC Technical discussions were engaged and the official response from the PCD domain concerning the requirements from the Pharmacy domain were summarized in the following official e-mail from PCD:

• The new Infusion Pump Event Communication profile (IPEC) was developed in response to eMAR vendors who wanted to know detailed operational information about infusions, including in particular stop and start type events, which the Device Enterprise Communication profile (DEC) did not support.
• The primary use of IPEC will likely be in flowsheet-type applications, where this type of detailed information (start, stop, volume infused) about a continuous administration is needed on-demand for flowsheet documentation, specifically, to document infusion events that have occurred since the last time the clinician documented the infusion.
• IPEC is not intended to support applications that need a higher level of information about a medication administration, which seems to be what the IHE Pharmacy group is concerned with. PCD's opinion is that the use cases for infusions need to be clearly defined by IHE Pharmacy.

A CP was not deem to be the most appropriate approach. A suggestion was made from the PCD domain that the activity concerning the IPEC profile may ultimately lead to the development of a new profile in order to support these use cases, in which case the RAS message which has been suggested may be appropriate.

This can be a new work item for the next cycle - 2011-2012.

Point-of-Care Infusion Verification Profile and Pharmacy

The PCD domain is having a face to face meeting the week of October 17th, 2011. The following request was brought forth for discussion to the IHE Pharmacy domain to be considered as a possible future work item between the domains Integrating PIV and HMW.

The PCD PIV profile (Point-of-Care Infusion Verification) is part of the PCD TF and can be found in the PCD Volume 1 and PCD Volume 2.

The PCD domain is coming towards the Pharmacy domain to possibly align these two profiles, and a conf call Integrating PIV and HMW is scheduled for October 13th, 2011, 14:00 CST at https://phast.webex.com

The comments and questions that are asked to our domain by the PCD domain are:

• The infusion-related systems that PCD profiles support include: BCMA (for point-of-care 5 rights verification), eMAR (for capturing when an administration is started) and a flow sheet / chart (time based chart that enables clinicians to view parameters from multiple sources - including devices - at a point in time)
  • Are there similar systems in Europe?
  • Are there similar or additional systems that are in use?

• Examples of real-world systems that implement the Pharmacy domain actors?
• Are there any differences between the Pharmacy system integration / medication administration support in Europe vs. the U.S.?

PCD understands that there are significant differences in clinical practice between the two regions and believes that it would be useful to better understand these differences and how they relate to the profiles that have been defined in two domains.

Supply Chain Whitepaper

The document presented is v0.6 dated Sept 19, 2011. The latest version on the ftp is September 25, 2011, v0.7.

• Separate clinical part from the supply part
• Where does the dispenser fit in?
• The clinical part is covered (assumption) and how is this distributed inside the hospital
• Looking at messages and/or documents
• Some aspects need to be still clarified (use cases)
• Use the HMW glossary and add a new glossary (not specially dedicated to the clinical part)
• The goal is to eventually identify the mechanism from the time of the decision of dispense and follow the medication as a product
• Look at the supply workflow
• The link between validation and the medical preparation is out of scope
• The communication between institutions is out of scope (other interoperability problems). Looking at the most obvious use cases and how would this be implementable in a hospital.
• Go thought the use-case - look at the common story line. Some actors are common, see section 6.1.
• Look at the "Nominative" dispensing (individually named medication). The medication goes to the ward already having the name of the patient. There is an automated dispenser. There is an entity making the decision if this is a "nominative" dispensing or not. An order should follow immediately to a robot, and the pharmacy system is informed and the nurse is notified that the medication is available to the patient (look at the sequence diagram).
• The nominative dispensation is the simplest solution (6.2.1.2).
• The sequence diagram has to be corrected for the "Nominative Dispensing".
• Extract the supply workflow, some of the parts have to be removed. The dispense part it is all clinical. The dispensation is clinical, the separation is not clear. There are differences between the supply logistics and the clinical, and the use-cases will be different.
• Make difference between the full prescription, and the items on the prescription.
• The dispense part could take place in three places (look at the purple arrows in the drawing).
• Discussion concerning the difference between the dispense (assigning a medication to a patient). at some point from the order you must go to the dispense, then it might be a dispense order.
• To summarize:the difference between clinical and supply is being discussed.
• How can you model different actions pertaining to the clinical and the supply process? Can the nurse play two roles? (clinical and supply?) This separation is not appropriate - open issue to be document it - whoever assigns the medication to a dispenser allows us to separate the clinical from the supply. The nurse plays two roles (morning nurse and afternoon).
• On a higher role - assignment of medication to a patient is a clinical action and not a supply action (time is needed to review HMW and think about the resolution)
• Proposition: preparation and the dispense are part of the clinical workflow. Keep it as an open issue and continue with the paper.
• Scott- supply happens through unit dose distribution or central robots. The nurse will get electronic access to the medication. this is not a dispense but a supply. Not an issue with this, but with the Supply Chain Logistics - the terms supply used by Scott is also a clinical action. The supply in the Pharmacy is a clinical action (order to adminsitration workflow is stopped to say this is not a clinical workflow but a supply chain.
• Supply is not part of the order - the doctor does not care where the medication comes.
• Not entirely in agreement, will continue discussion later (next day, October 5th, 2011).

Next Cycle

• Officially start the new cycle for the change of proposals.
• Leave it open until the end of USA Connectathon, have a t-con to see what we have received
• How many people will be at the Connectathon in Chicago?
• Can we use the facilities of the Connectathon at the face to face meeting
• Face to face meetings - Connectathon, Paris/Brussels, and a special occasion
• Call for proposals, planning phase
• Plan for editors and new work items, different cycle for CP
• New work items
• Set up t-confs
• In April - have an offical t-conf of the progress, try to write the CPs earlier.
• How do you organize in terms of the white papers?

Please see tentative draft for the next cycle. This is to be discussed tomorrow (October 5th, 2011).