Pharm Tech Minutes 2011.10.04

From IHE Wiki
Jump to navigation Jump to search

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

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

The PCD domain was contacted with regards to the infusion pump topic during summer. The PCD profile in question isIPEC 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. My opinion is that the use cases for infusions need to be clearly defined by IHE Pharmacy. This may ultimately lead to the development of a new profile to support these use cases, in which case the RAS message which has been suggested may be appropriate.
Retrieved from "http://wiki.ihe.net/index.php?title=Pharm_Tech_Minutes_2011.10.04&oldid=54901"