FW: Pharmacy question - dispensing
Tom de Jong
Since, the IHE Pharmacy list is mentioned, it’s probably good to forward Hans’ response there… Not sure if everybody is subscribed to both lists…
Best,
Tom
Van: Buitendijk, Hans [mailto:hans.bu...@siemens.com]
Verzonden: maandag 18 maart 2013 16:17
Aan: Jose Costa Teixeira; Berge, Ruth E (GE Healthcare)
CC: 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong
Onderwerp: RE: Pharmacy question - dispensing
Sorry for jumping in late into this discussion as other threads kept me occupied.
RXE-40 is not a great choice since in V2.7 it is being deprecated in favor of a PRT segment. This actually opens up all kinds of opportunities as the Participation table could be extended to cover dispensing cabinets (either as location PRT-9 and/or device PRT-10)
Furthermore, PRT has an action code, so if one wishes to change from Cabinet A to Cabinet B, then Cabinet A’s PRT is sent with action code DE and Cabinet B’s PRT uses AD.
The question on changing package form then comes completely down to whether that is within policy of the pharmacy, when to allow changes. But I would think that the RDS message could deal with that, or the RDE if for the remaining of the prescription.
Discontinue does not sound right, unless policy requires that on the package form change. Agreed with Bas van Poppel on the IHE thread though that we should separate logistics from clinical flow.
So my direction would be to consider (pre-)adopting V2.7.1.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org] On Behalf Of Jose Costa Teixeira
Sent: Monday, March 18, 2013 3:33 AM
To: Berge, Ruth E (GE Healthcare)
Cc: Buitendijk, Hans; 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong
Subject: RE: Pharmacy question - dispensing
Thanks Ruth
Using RXE-40 would indeed need a clarification or revision. Sometimes there is no mention of a dispensing pharmacy, but a dispensing entity/system. HL7 could change the description to allow for this additional use or add a specific field for "dispensing system identifier".
I also agree that there would be a conflict if we want to put the pharmacy AND a dispensing system. - Ideally HL7 should be extended for that, and I would like to help prepare a proposal.
For dispensing to another device, I think HL7 v2.6 and 2.7 are short there as well. The closest we could get is RXE-8, and that would not be appropriate.
To make such proposal, maybe the just-started work on healthcare supply would be helpful.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Berge, Ruth E (GE Healthcare)" <ruth....@ge.com>
To: Tom de Jong <t...@nova-pro.nl>, Jose Costa Teixeira/AXGBB/AGFA@AGFA, "'Buitendijk, Hans'" <hans.bu...@siemens.com>, "scott.m....@kp.org" <scott.m....@kp.org>
Cc: "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>
Date: 18/03/2013 04:52
Subject: RE: Pharmacy question - dispensing
Sent by: owner-p...@lists.hl7.org
Thanks to all! It has proved to be very informative, especially Joses views.
In addition to everything you have said, I find it hard to swallow the (RXE-40 ?) pharmacy as being the same as a cabinet. If that is true, then I would hope that language would clarify that because I certainly dt get that from the definition. Also I wonder if using it that way invalidates it for some other use case where it really should be the pharmacy system.
Also what about a case where the drug is dispensed to yet another device? The pharmacy system in our IHE use case did just that, dispensing from a dispensing cabinet to a portable cabinet.
From: Tom de Jong [mailto:t...@nova-pro.nl]
Sent: Sunday, March 17, 2013 2:35 PM
To: Berge, Ruth E (GE Healthcare); 'Jose Costa Teixeira'; 'Buitendijk, Hans'; scott.m....@kp.org
Cc: 'o...@lists.HL7.org'; phar...@lists.hl7.org
Subject: RE: Pharmacy question - dispensing
Hi Ruth,
m going to back out of this debate, because I really think the authors of Chapter 4 need to provide feedback at this point (Hans? Scott?).
I totally see your point about the RDE referring to the order as a whole (and not just a separate dispense request). As far as I know, HL7v2 doesnt have specific support for separate dispense requests of the type that Jose describes (although I can see the use case for those). And youre right that theyre not necessary if the dispensing system is able to process updates in the order and infer the proper dispensing cabinets accordingl
By the way, I dt think the proper way to solve this would involve using either RDS or RGV messages, because those have a different application. Your use case requires a message from a Pharmacy system to an automated dispensing system, feeding it with the information needed to schedule and perform dispenses. RDE (encoded medication order) can certainly be used for that. RDS is to be used when an actual dispense occurs (so in this case the automated dispense would trigger it). RGV is used to populate the administration schedule, representing one scheduled administration each. This would normally be sent from a pharmacy system to a nursing system. I realize that the information content can be very similar in all these messages, but there is a hierarchy when it comes to the scale to which the information refers:
RDE encoded order, leading to zero to many dispenses and one to many administrations (not all orders require a dispense)
RDS actual dispense, one for each dispense, which can be used to perform one to many administrations
RGV scheduled administration, one for each administration that is scheduled to occur
I think wre left with two distinct issues here:
How to specify a dispensing cabinet in RDE and RDS messages.
Differences in business rules for updates to existing orders.
I think Jose has provided a good opening for solving the first issue (I agree that the definitions would only need a slight rewording to support the dispensing cabinet use case). The second issue seems more of a challenge. I hope Hans or Scott can pick it up from here.
Best,
Tom
Van: Berge, Ruth E (GE Healthcare) [mailto:ruth....@ge.com]
Verzonden: zaterdag 16 maart 2013 0:20
Aan: Jose Costa Teixeira
CC: 'Buitendijk, Hans'; 'o...@lists.HL7.org'; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong
Onderwerp: RE: Pharmacy question - dispensing
For clarification, the order message used to send from the pharmacy to the cabinet (really to the system that controls the cabinet) is an RDE. Pharmacy Encoded Order Message. The order placer number in that message is the unique order id for the order. There is no field in RXE for a different number. Therefore, if a system cancels an order with that unique order id, then they are cancelling the entire order starting with what the provider entered.
The RDS and RGV messages are different and do have different identifiers. They are specifically listed as exceptions to the above rule. However historically they are not well accepted in the industry- meaning that the normal method is for the dispensing system (using that to mean the dispensing cabinet system) to receive an RDE. One reason for this is that sending an RDE is a way of communicating the entire medication encoded order. A smart dispensing system then receives that order and it controls the dispensing. The dispensing system doet have to receive a message each time it is due to dispense. It also allows for prn orders where there is no systematic way for the pharmacy system to know that the patient needs the medication.
I think what you are saying is that if the pharmacy system is sending an RDS or RGV message for each dispense or give instance, then it can revoke those with a DC in the message. I still dont see how that helps in the instance of an automated dispensing system. I still see a gap in HL7 for that use case. It is not addressed in the transaction flow diagram.
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org] On Behalf Of Jose Costa Teixeira
Sent: Friday, March 15, 2013 1:23 PM
To: Berge, Ruth E (GE Healthcare)
Cc: 'Buitendijk, Hans'; 'o...@lists.HL7.org'; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong
Subject: RE: Pharmacy question - dispensing
Thanks for this discussion Ruth
I think your last sentence can explain the difference in points of view that was present in this mail thread.
What is your interpretation of a DC?
1 - Discontinue the prescription, start over
or
2 - Discontinue this particular dispense request, prescription stays the same.
In my understanding, the message that you send to the dispensers is actually a dispense order, so a Discontinue applies only to the current dispense order. One prescription may trigger several dispense requests. Prescriptions and Dispense requests are very different terms, although they are represented with the same RDE. We've seen this in IHE and it keeps coming back. Discontinuing a Dispense request is not the same as discontinuing the prescription.
I am now under the impression that the difference is between the 2 options above. Is this a good guess?
All of this to explain that if you are on case 1 above, then I understand why you don't want to accept a DC . That would not make sense indeed. And that if your system is including a set of roles (prescription, decision to dispense, where to dispense from) then your system should not see the DC as a "discontinue the whole thing" but "discontinue this particular dispense request". I expect that this can be challenging to differentiate these 2 , but we can address that separately.
I assume (subject to disagreement from others) that you are not expected to discontinue the whole prescription or order if te package is changed. What you can /should discontinue is a dispense request for that package and reissue with another one.
On the RXE-40, I have no issues in "abusing" a dispensing Pharmacy and using it as a "dispensing entity", especially because it is a CWE. I'd consider Given that many times the dispensing entity is what matters, and there is only one pharmacy, this falls under an acceptable use of the norm. If not for a local interpretation of the term, then I would think that for most hospitals in Europe HL7 would still be needing a lot (more) of Z segments.
Using it in MSH has one meaning (also subject to local "abuse") - that the "receiving application" univocally represents the dispensing location.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Berge, Ruth E (GE Healthcare)" <ruth....@ge.com>
To: Jose Costa Teixeira/AXGBB/AGFA@AGFA, Tom de Jong <t...@nova-pro.nl>
Cc: "'Buitendijk, Hans'" <hans.bu...@siemens.com>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "owne...@lists.hl7.org" <owne...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>, "scott.m....@kp.org" <scott.m....@kp.org>
Date: 15/03/2013 19:07
Subject: RE: Pharmacy question - dispensing
Sent by: owner-p...@lists.hl7.org
Thanks Jose et.al.
When I read the definition of a dispensing pharmacy it does not sound like a dispensing cabinet. The cabinet is stocked by the dispensing pharmacy but is a separate arm of it. I do not see that as meeting the need to identify one or more cabinets that can be used to fulfill the order.
I wholeheartedly disagree that a DC transaction should be used unless the actual order is discontinued. I think that HL7 should consider that case where there is nothing wrong with the order as written by the provider so asking that it be discontinued and rewritten is counterintuitive. The only issue is that either the packaging is different (e.g. instead of two 25 mg tablets it is 1 50 mg tablet).and that means changing the dispensing cabinet.
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org] On Behalf Of Jose Costa Teixeira
Sent: Friday, March 15, 2013 1:11 AM
To: Tom de Jong
Cc: 'Buitendijk, Hans'; 'o...@lists.HL7.org'; owne...@lists.hl7.org; phar...@lists.hl7.org; Berge, Ruth E (GE Healthcare); scott.m....@kp.org
Subject: RE: Pharmacy question - dispensing
Hi All
Allow me to quickly state what I think - please let me know if you don't agree.
1. in HL7 v2.6 (unsure if in 2.5) there is a RXE-40 "Dispensing Pharmacy (CWE) that can be used for this purpose of saying "I want a drug from that location". This can be used for a physical pharmacy, but i see no need why not for a dispensing entity of any sort.
this is one of the reasons why in IHE we kept the supply aspects as depending on V2.6
2. I believe that what is behind Ruth's question is that there are 2 possibilities that we briefly touched in supply management:
a) the SENDER knows which is the dispensing location (because it knows where drugs are available). In this case, the sender must have control and the use of a DC message makes sense.
b) the RECEIVER knows how to forward the messages to the dispensing locations, and in this case the requested only asks for drugs, and the receiver contains the "broker" that deals with the rest.
c) a hybrid model where the sender has a clue, but the receiver kbnows better
I have worked in a project where these were common and also the additional questions that Ruth asks (how to hear back from the dispensing cabinet)
With the knowledge I have, I believe that HL7 v2.6 actually covers all this, even the reponse from the dispensers.
Would working on a set of example messages help for clarifying this and for the group to start proposing guidance?
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Tom de Jong" <t...@nova-pro.nl>
To: "'Berge, Ruth E \(GE Healthcare\)'" <ruth....@ge.com>
Cc: <phar...@lists.hl7.org>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, <scott.m....@kp.org>, "'Buitendijk, Hans'" <hans.bu...@siemens.com>
Date: 14/03/2013 19:16
Subject: RE: Pharmacy question - dispensing
Sent by: owne...@lists.hl7.org
Hi Ruth,
Several things in your e-mail triggered me. Based on HL7v2.4 sps (so hardly the latest version):
Our system provides a location from which we think it will be dispensed as MSH-4.
Arggh, thats just awful. MSH should only contain transport-level information (where you send the message), not a physical dispensing location.
I was unable to find a field in the HL7 v2 message that expressed this concept
Theres something we need to fix then. I usually implement v2.4 and I agree thers no real place for a dispense locati (as in a cabinet) in RXE.
Nor do I see any way to hear back from the automated dispensing system as to which cabinet or cabinets are actually selected.
Well, there is RXD-13 Dispense-to location, but I agree thats the nursing ward the dispense is intended for and not the dispensing cabinet.
I would like to see a response from the people who actively worked on versions v2.5 and above. Maybe we have simply identified a gap here.
Thanks for your feedback,
Tom
Van: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org] Namens Berge, Ruth E (GE Healthcare)
Verzonden: donderdag 14 maart 2013 17:52
Aan: phar...@lists.hl7.org; 'o...@lists.HL7.org'
Onderwerp: RE: Pharmacy question - dispensing
I have asked for more information and will reply back to the group.
The way the problem was presented to me was simply that they wanted to vend the dose from a different cabinet. However, in the detailed example they actually changed the package and the new package was only available in a different cabinet.
Also they mention their concern that the package remains available on the first dispensing cabinet (Here I mean an automated dispensing cabinet and in this case I understand it to be a profile cabinet meaning that the order and patient information is part of what the cabinet has).
My experience is that the pharmacy system has really no control over where which automated dispensing cabinet is selected by the automated dispensing system. Our system provides a location from which we think it will be dispensed as MSH-4. When I reviewed this several years ago, I was unable to find a field in the HL7 v2 message that expressed this concept. Nor do I see any way to hear back from the automated dispensing system as to which cabinet or cabinets are actually selected.
In fact, although this particular facet of pharmacy is something that our system deals with commonly (and I believe it is a common workflow), it is not really covered in HL7 v2. In can be fit into the use cases but the entire workflow involving dispensing cabinets and override orders is not directly addressed (unless it is in the most current version).
From: Marco Demarmels [mailto:marco.d...@lakegriffin.ch]
Sent: Thursday, March 14, 2013 8:45 AM
To: Tom de Jong
Cc: Berge, Ruth E (GE Healthcare); phar...@lists.hl7.org; 'o...@lists.HL7.org'
Subject: Re: Pharmacy question - dispensing
Hi
Just to confirm Tom's view: We always cancel and re-issue orders in similar cases.
Out of curiosity: Can you provide a use case where the fact that an order has been rerouted is of value to you?
Apart from some sort of quality measurement I cannot imagine such a use case.
Thanks
Marco
mit freundlichen Grssen - kind regards
--
Lake Griffin LLC
Marco Demarmels, MD, eMBA
Managing Partner
Neuwiesstrasse 1, CH-8309
E-Mail, fon: +41 44 500 25 88, mob: +41 76 588 18 00
-
Request for appointment: Doodle-Link
Bio: MyOpenID
Am 14.03.2013 um 16:20 schrieb "Tom de Jong" <t...@nova-pro.nl>:
Apologies, where I wrote they do need specify below I meant to saythey do NOT specify .
Best,
Tom
Van: Tom de Jong [mailto:tom@nova-pro.nl]
Verzonden: woensdag 13 maart 2013 9:23
Aan: 'Berge, Ruth E (GE Healthcare)'
CC: phar...@lists.hl7.org; 'o...@lists.HL7.org (o...@lists.hl7.org)'
Onderwerp: RE: Pharmacy question - dispensing
Hi Ruth,
First of all, let me clarify that Pharmacy is no longer a subgroup of O&O. The groups are now equals under the Domain Experts steering division.
I have copied the Pharmacy list, to make sure that some of the HL7v2 Pharmacy experts also shed their light on this. As a general comment, I can say that is always tricky to determine the business rules for when an order can or cannot be modified. Both the V2 and V3 standards provide a mechanism for exchanging modifications, but they do need specify hard and fast rules for when a modification of an existing order is allowed.
What I dt understand is why the receiving system would need a discontinue plus a new order, and then still need a special flag to specify that the dispensing location was changed. It would seem that a simple comparison (whether the change gets sent as a modification or as a new order) would suffice to determine the nature of the changes. Also, can you share which order control code you are now using in the modify messag
Best wishes,
Tom
Van: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org] Namens Berge, Ruth E (GE Healthcare)
Verzonden: dinsdag 12 maart 2013 17:48
Aan: o...@lists.HL7.org (o...@lists.hl7.org)
Onderwerp: Pharmacy question - dispensing
I know I could request this of the pharmacy sub group but am hoping that this broader audience will help. I have a semi-permanent conflict with the Thursday meetings.
In the role of Pharmacy system, our system sends out an RDE^O11 (version 2.6)with the drug packages requested of an automated dispensing system. Our message optionally includes an attempt to direct this to a specific location m going to say in the message header receiving application but this is a high level question and I could be forgetting some other field in the message). In the course of events, a change is made to the encoding of the order. Our system then sends out a modify message which could have a new requested dispensing location. Our customer has requested that we instead send out a discontinue message and then (presumably although they dit say this) a new order. They are specifically talking about the change in the requested dispensing location, not in the package changes. They would like a special flag to tell them that we have changed the requested dispensing location from one cabinet to another. They are saying that the modify control code is not specific enough. m sending this out for thoughts and comments in both v2 and v3.
_________________________________________________________________________________________________________________________________________________________________________________
Ruth Berge
GE Healthcare
Principal Software Designer
T+ 206 607 5854
D* 607 5854
E ruth....@ge.com
www.gehealthcare.com
Fourth and Madison Bldg
925 Fourth Ave, Suite 600
Seattle, WA, 98104-1157, USA
General Electric Company
Dreaming is, after all, a form of planning.
Gloria Steinem, US author, feminist
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2904 / Virusdatabase: 2641/6166 - datum van uitgifte: 03/12/13
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2904 / Virusdatabase: 2641/6166 - datum van uitgifte: 03/12/13
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2904 / Virusdatabase: 2641/6175 - datum van uitgifte: 03/14/13
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
***********************************************************************************
Manage your subscriptions | View the archives | Unsubscribe | Terms of use
This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation
Geen virus gevonden in dit bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 2013.0.2904 / Virusdatabase: 2641/6185 - datum van uitgifte: 03/17/13
Jose Costa Teixeira
Preadopting 2.7.1 seems good, i'd like to check the impact on the current IHE work and change what is needed.
I had not seen PRT but I agree that it would solve the "dispensing system ID" better than squeezing it to RXE-40. It does contain intent which adds a new level of flexibility (and need for guidance imo).
Question: In the use of PRT that you indicate, it seems that the "dispense requester" re-routes the order from one "dispensing system" to the other, by sending a DE to one and an AD to another. Can you confirm if i understand correctly?
If so, i think we should take the opportunity to discuss the use of ORC-1 in HL7 Pharmacy, since with 2.6 we considered that. for example, a DC of a "dispense request" means "discontinue this request", not "discontinue the whole order".
This may be wrong, but unless we adopt 2.7 AND find out a way to differentiate "encoded order" and "prescription dispense request", i see that it would be difficult to have proper interface segregation.
Can we take that up in a next discussion?
We should keep in mind that there is an actor (/action) whose task is to determine which medication comes from where. This is a separate action, that can be either in the order placer or the order filler, and is a supply aspect, and as such is not detailed out yet.
In other words, the decision of where to get the medication from should not be hardcoded in any actor - the pharmacy or the dispensers.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
To: Jose Costa Teixeira/AXGBB/AGFA@AGFA, "Berge, Ruth E (GE Healthcare)" <ruth....@ge.com>
Cc: "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "owner-p...@lists.hl7.org" <owner-p...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>, "scott.m....@kp.org" <scott.m....@kp.org>, Tom de Jong <t...@nova-pro.nl>
Date: 18/03/2013 17:07
Subject: RE: Pharmacy question - dispensing
Sent by: owner-p...@lists.hl7.org
RXE-40 is not a great choice since in V2.7 it is being deprecated in favor of a PRT segment. This actually opens up all kinds of opportunities as the Participation table could be extended to cover dispensing cabinets (either as location PRT-9 and/or device PRT-10)
In addition to everything you have said, I find it hard to swallow the (RXE-40 ?) pharmacy as being the same as a cabinet. If that is true, then I would hope that language would clarify that because I certainly dt get that from the definition. Also I wonder if using it that way invalidates it for some other use case where it really should be the pharmacy system.
Also what about a case where the drug is dispensed to yet another device? The pharmacy system in our IHE use case did just that, dispensing from a dispensing cabinet to a portable cabinet.
From: Tom de Jong [mailto:t...@nova-pro.nl]
Sent: Sunday, March 17, 2013 2:35 PM
To: Berge, Ruth E (GE Healthcare); 'Jose Costa Teixeira'; 'Buitendijk, Hans'; scott.m....@kp.org
Cc: 'o...@lists.HL7.org'; phar...@lists.hl7.org
Subject: RE: Pharmacy question - dispensing
Hi Ruth,
m going to back out of this debate, because I really think the authors of Chapter 4 need to provide feedback at this point (Hans? Scott?).
I totally see your point about the RDE referring to the order as a whole (and not just a separate dispense request). As far as I know, HL7v2 doesnt have specific support for separate dispense requests of the type that Jose describes (although I can see the use case for those). And youre right that theyre not necessary if the dispensing system is able to process updates in the order and infer the proper dispensing cabinets accordingl
By the way, I dt think the proper way to solve this would involve using either RDS or RGV messages, because those have a different application. Your use case requires a message from a Pharmacy system to an automated dispensing system, feeding it with the information needed to schedule and perform dispenses. RDE (encoded medication order) can certainly be used for that. RDS is to be used when an actual dispense occurs (so in this case the automated dispense would trigger it). RGV is used to populate the administration schedule, representing one scheduled administration each. This would normally be sent from a pharmacy system to a nursing system. I realize that the information content can be very similar in all these messages, but there is a hierarchy when it comes to the scale to which the information refers:
RDE encoded order, leading to zero to many dispenses and one to many administrations (not all orders require a dispense)
RDS actual dispense, one for each dispense, which can be used to perform one to many administrations
RGV scheduled administration, one for each administration that is scheduled to occur
I think wre left with two distinct issues here:
How to specify a dispensing cabinet in RDE and RDS messages.
Differences in business rules for updates to existing orders.
I think Jose has provided a good opening for solving the first issue (I agree that the definitions would only need a slight rewording to support the dispensing cabinet use case). The second issue seems more of a challenge. I hope Hans or Scott can pick it up from here.
Best,
Tom
Van: Berge, Ruth E (GE Healthcare) [mailto:ruth....@ge.com]
Verzonden: zaterdag 16 maart 2013 0:20
Aan: Jose Costa Teixeira
CC: 'Buitendijk, Hans'; 'o...@lists.HL7.org'; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong
Onderwerp: RE: Pharmacy question - dispensing
For clarification, the order message used to send from the pharmacy to the cabinet (really to the system that controls the cabinet) is an RDE. Pharmacy Encoded Order Message. The order placer number in that message is the unique order id for the order. There is no field in RXE for a different number. Therefore, if a system cancels an order with that unique order id, then they are cancelling the entire order starting with what the provider entered.
The RDS and RGV messages are different and do have different identifiers. They are specifically listed as exceptions to the above rule. However historically they are not well accepted in the industry- meaning that the normal method is for the dispensing system (using that to mean the dispensing cabinet system) to receive an RDE. One reason for this is that sending an RDE is a way of communicating the entire medication encoded order. A smart dispensing system then receives that order and it controls the dispensing. The dispensing system doet have to receive a message each time it is due to dispense. It also allows for prn orders where there is no systematic way for the pharmacy system to know that the patient needs the medication.
Jose Costa Teixeira
It isolates the clinical flow and the supply flow - each one of these see the other as a "black box".
Also the notion of "dispense" that we defined was crucial for that separation, to avoid contaminating the clinical workflows with the many supply preferences and locations.
PS:
My feeling: For the dispensing systems I'd actually use RDE for a very simple system but I'd go serious and use OMS when it comes to branching, resupplying, etc. it makes no sense to have a clinical order being split and re-routed across a set of dispensing systems.
Buitendijk, Hans
Jose:
If there is one management system controlling both cabinets, it would be two PRTs with a DE / AD action code respectively.
If the “message” to switch cabinets must be sent to two separate systems, then we have two choices:
· Cancel the dispense to one cabinet and send a new one to the other cabinet, using ORC-1 control codes in the RDS^013 message. That requires new control codes as existing ones really apply to the order or result as a whole.
· Send the RDS^013 with the DE on the PRT to one cabinet and another RDS^013 with the AD to the other. That can be done with existing capabilities, but the removal of that cabinet is not evident until one reads the PRT.
I think both are very acceptable approaches. The second would support a consistent approach whether one or multiple systems are in play.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org]
On Behalf Of Jose Costa Teixeira
Sent: Tuesday, March 19, 2013 4:07 AM
To: Buitendijk, Hans
Cc: 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; Berge, Ruth E (GE Healthcare); scott.m....@kp.org; Tom de Jong; ihe-ph...@googlegroups.com
Subject: RE: Pharmacy question - dispensing
Thank you Hans
Preadopting 2.7.1 seems good, i'd like to check the impact on the current IHE work and change what is needed.
I had not seen PRT but I agree that it would solve the "dispensing system ID" better than squeezing it to RXE-40. It does contain intent which adds a new level of flexibility (and need for guidance
imo).
Question: In the use of PRT that you indicate, it seems that the "dispense requester" re-routes the order from one "dispensing system" to the other, by sending a DE to one and an AD to another.
Can you confirm if i understand correctly?
If so, i think we should take the opportunity to discuss the use of ORC-1 in HL7 Pharmacy, since with 2.6 we considered that. for example, a DC of a "dispense request" means "discontinue this
request", not "discontinue the whole order".
This may be wrong, but unless we adopt 2.7 AND find out a way to differentiate "encoded order" and "prescription dispense request", i see that it would be difficult to have proper interface segregation.
Can we take that up in a next discussion?
We should keep in mind that there is an actor (/action) whose task is to determine which medication comes from where. This is a separate action, that can be either in the order placer or the order
filler, and is a supply aspect, and as such is not detailed out yet.
In other words, the decision of where to get the medication from should not be hardcoded in any actor - the pharmacy or the dispensers.
Berge, Ruth E (GE Healthcare)
I just want to point out that there is a use case for switching the dispensing cabinet without any other change to the order. Our customer reports that they may need to do this because the dispensing cabinet is being depleted too quickly for that medication so they want to switch the source back to the main pharmacy.
Also noting that there can be more than one source- there may be multiple dispensing cabinets nearby (to the patient) and I have seen dispensing systems allowing dispense from multiple cabinets.
Jose Costa Teixeira
This actor then decides whether to send to one intelligent dispenser, or to separate "not-so-intelligent" dispensers.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
To: <ihe-ph...@googlegroups.com>
Cc: "Buitendijk, Hans" <hans.bu...@siemens.com>, Jose Costa Teixeira/AXGBB/AGFA@AGFA, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "owner-p...@lists.hl7.org" <owner-p...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>, "scott.m....@kp.org" <scott.m....@kp.org>, Tom de Jong <t...@nova-pro.nl>
Date: 20/03/2013 10:21
Subject: Re: [IHE-Pharmacy:1661] RE: Pharmacy question - dispensing
Hi Ruth,
So your cabinets work together in an intelligent way . . .
You could mode this by abstracting this intelligence from the requestor that sends the dispense request. You arrive at an actor like cabinet-manager.
IMHO we should chose between either disparate cabinets (as Hans pointed out) or a cabinet-network that logically is one cabinet.
With kind regards
BAS VAN POPPEL
Solution Architect
CSC
Mendelweg 32, 2333 CS Leiden, The Netherlands
Healthcare Group | t: +31 (071) 5256 786 | bvanp...@csc.com | www.csc.com
CSC brengt nieuwe slagkracht in de Nederlandse gezondheidszorg.
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose • iSOFT Nederland BV • Registered Office: Mendelweg 32, 2333 CS Leiden, The Netherlands • Registered in The Netherlands No: 28069101
______________________________________________________________________
This isoft.nl-email has been scanned by the MessageLabs Email Security
System.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
You received this message because you are subscribed to the Google Groups
"IHE Pharmacy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ihe-pharmacy...@googlegroups.com.
To post to this group, send email to ihe-ph...@googlegroups.com.
Visit this group at http://groups.google.com/group/ihe-pharmacy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Bas van Poppel
So your cabinets work together in an intelligent way . . .
You could mode this by abstracting this intelligence from the requestor that sends the dispense request. You arrive at an actor like cabinet-manager.
IMHO we should chose between either disparate cabinets (as Hans pointed out) or a cabinet-network that logically is one cabinet.
With kind regards
BAS VAN POPPEL
Solution Architect
CSC
Mendelweg 32, 2333 CS Leiden, The Netherlands
Healthcare Group | t: +31 (071) 5256 786 | bvanp...@csc.com | www.csc.com
CSC brengt nieuwe slagkracht in de Nederlandse gezondheidszorg.
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose • iSOFT Nederland BV • Registered Office: Mendelweg 32, 2333 CS Leiden, The Netherlands • Registered in The Netherlands No: 28069101
Cc: "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "owner-p...@lists.hl7.org" <owner-p...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>, "scott.m....@kp.org" <scott.m....@kp.org>, Tom de Jong <t...@nova-pro.nl>, "ihe-ph...@googlegroups.com" <ihe-ph...@googlegroups.com>
Date: 19-03-2013 18:28
______________________________________________________________________
This isoft.nl-email has been scanned by the MessageLabs Email Security
System.
For more information please visit
Buitendijk, Hans
Jose and I had a quick side-bar and somehow the following questions raised to the top that may help us converge on an answer:
1 - We must discuss whether a dispense request is a"child" of an order, or a continuation. Meaning: during a prescription order workflow, if there is derived orders/requests (like dispense), do they have the same ORC-2 or they get a new ORC-2 and ORC-8 gets the prescription ID?
2 - We must further discuss / agree whether ORC-1 codes apply to the whole order mentioned in ORC-2, or just to the current message and corresponding part of the workflow - i.e. if a DC in a dispense request is just about the dispense part, or in the whole prescription?
3 – What is the difference between Validated Prescription and Dispense Request. What are the possible mechanisms to say "This encoded order has been processed enough, now it is ready for dispensing"?
4 – When should one use an RDS message vs. an OMS message?
Very interested in feedback. I’ll put mine on the next one.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
Tom de Jong
Hi Hans,
My responses are (without claiming to be an expert in implementing medication logistics, since my work has mostly been on the order side):
Ø 1 - We must discuss whether a dispense request is a"child" of an order, or a continuation. Meaning: during a prescription order workflow, if there is derived orders/requests (like dispense), do they have the same ORC-2 or they get a new ORC-2 and ORC-8 gets the prescription ID?
It’s obviously a child, since there is a hierarchical relationship. If the ‘prescription’ gets cancelled, there is no need for the dispense request anymore, so we need an umbrella and not simply a chain. That doesn’t answer the question about the ID’s though. Fact is that it’s impossible to manage a child order separate from the parent order if it doesn’t have a distinct ID. Fact is also that most systems are not capable of assigning a separate ID to the dispense requests. That discrepancy seems to be the main issue we are dealing with here.
Ø 2 - We must further discuss / agree whether ORC-1 codes apply to the whole order mentioned in ORC-2, or just to the current message and corresponding part of the workflow - i.e. if a DC in a dispense request is just about the dispense part, or in the whole prescription?
The order control code refers to the order that the ID in ORC-2 refers to. If that’s the same ID in the dispense request as in the prescription, then it’s impossible to cancel the dispense request without cancelling the whole order. This conforms we need separate ID’s for child orders
Ø 3 – What is the difference between Validated Prescription and Dispense Request. What are the possible mechanisms to say "This encoded order has been processed enough, now it is ready for dispensing"?
A validated prescription is now used as a dispense request (see Ruth’s use case), simply because they are linked to (roughly) the same stage in the workflow (pharmaceutical evaluation has taken place, logistical process can be set in motion). Of course it would be much better to separate the two, since the former is a form of medical feedback, whereas the latter is a logistical request. I have no experience with the OMS message, but it seems like it’s perfect for separating the two (and also handling the logistics in a way that is product-independent).
Ø 4 – When should one use an RDS message vs. an OMS message?
I don’t understand the question. It is my understanding that RDS is used AFTER a dispense occurs (i.e. medication is tied to a specific patient, for example when medication is transferred to a cabinet). As far as I can tell, the OMS message is used to initiate a dispense. Different ‘mood code’…
Best,
Tom
Versie: 2013.0.2904 / Virusdatabase: 2641/6189 - datum van uitgifte: 03/19/13
Bas van Poppel
IMHO the essence is point numer 3 of Hans: decoupling the medical validation (it is validated enough) and the subsequent request for dispensing.
I'm in favour to take this as a starting point.
with kind regards, Bas
BAS VAN POPPEL
Solution Architect
CSC
Mendelweg 32, 2333 CS Leiden, The Netherlands
Healthcare Group | t: +31 (071) 5256 786 | bvanp...@csc.com | www.csc.com
CSC brengt nieuwe slagkracht in de Nederlandse gezondheidszorg.
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose • iSOFT Nederland BV • Registered Office: Mendelweg 32, 2333 CS Leiden, The Netherlands • Registered in The Netherlands No: 28069101
______________________________________________________________________
This isoft.nl-email has been scanned by the MessageLabs Email Security
System.
For more information please visit
Buitendijk, Hans
See responses in-line.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org]
On Behalf Of Tom de Jong
Sent: Thursday, March 21, 2013 6:26 AM
To: Buitendijk, Hans
Cc: 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; ihe-ph...@googlegroups.com; 'Berge, Ruth E (GE Healthcare)'; 'Jose Costa Teixeira'
Subject: RE: Pharmacy question - dispensing
Hi Hans,
My responses are (without claiming to be an expert in implementing medication logistics, since my work has mostly been on the order side):
Ø 1 - We must discuss whether a dispense request is a"child" of an order, or a continuation. Meaning: during a prescription order workflow, if there is derived orders/requests (like dispense), do they have the same ORC-2 or they get a new ORC-2 and ORC-8 gets the prescription ID?
It’s obviously a child, since there is a hierarchical relationship. If the ‘prescription’ gets cancelled, there is no need for the dispense request anymore, so we need an umbrella and not simply a chain. That doesn’t answer the question about the ID’s though. Fact is that it’s impossible to manage a child order separate from the parent order if it doesn’t have a distinct ID. Fact is also that most systems are not capable of assigning a separate ID to the dispense requests. That discrepancy seems to be the main issue we are dealing with here.
[Buitendijk, Hans] Agreed that it is something different and needs to be identified independently from the originating order, but must be linked so the “group” can be acted on as one where needed. Challenge is that in the current V2 definitions this is not easily achieved. While it is possible to address the individual identification (by clarifying that ORC-2/ORC-3 apply to the focal segment of the message, e.g., OMP – RXO, RDS – RXD, etc.) the linking may be problematic. There is only one ORC-8, so should the ORC/RXD pair point to the ORC/RXE or the ORC/RXO pair? How do you know which one it is as one does not have to start with an ORC/RXO, or may skip the ORC/RXE. Is there a clear rule we can establish, or do we need to add support for multiple parents? Or do we need to include in one message the full tree and require a different structure:
NOW: ORC [RXO][RXE] RXD
PERHAPS: [ORC RXO][ORC RXE] ORC RXD
(note I left the non-essential segments out, so they would have to be included where appropriate)
Either way, the standard needs to be updated to clarify this as today that is not clear from the language, i.e., open to interpretation, thus variation.
Ø 2 - We must further discuss / agree whether ORC-1 codes apply to the whole order mentioned in ORC-2, or just to the current message and corresponding part of the workflow - i.e. if a DC in a dispense request is just about the dispense part, or in the whole prescription?
The order control code refers to the order that the ID in ORC-2 refers to. If that’s the same ID in the dispense request as in the prescription, then it’s impossible to cancel the dispense request without cancelling the whole order. This conforms we need separate ID’s for child orders
[Buitendijk, Hans] When we solve the focal segment question of 1, this one becomes easy. We don’t need to have solved the parent linking for this to be clear.
Ø 3 – What is the difference between Validated Prescription and Dispense Request. What are the possible mechanisms to say "This encoded order has been processed enough, now it is ready for dispensing"?
A validated prescription is now used as a dispense request (see Ruth’s use case), simply because they are linked to (roughly) the same stage in the workflow (pharmaceutical evaluation has taken place, logistical process can be set in motion). Of course it would be much better to separate the two, since the former is a form of medical feedback, whereas the latter is a logistical request. I have no experience with the OMS message, but it seems like it’s perfect for separating the two (and also handling the logistics in a way that is product-independent).
Ø 4 – When should one use an RDS message vs. an OMS message?
I don’t understand the question. It is my understanding that RDS is used AFTER a dispense occurs (i.e. medication is tied to a specific patient, for example when medication is transferred to a cabinet). As far as I can tell, the OMS message is used to initiate a dispense. Different ‘mood code’…
[Buitendijk, Hans] I understand the OMS to be a request to dispense, e.g., nursing unit asks Pharmacy, Central Supply, whoever, to send them some stuff that may or may not be designated for a particular patient. On the other hand, I understand the RDS to be a set of dispense instructions indicating that this is being dispensed. The problem with our interpretations is that the standard is going both ways:
The RDS message may be created by the pharmacy/treatment application for each instance of dispensing a drug or treatment to fill an existing order or orders. In the most common case, the RDS messages would be routed to a Nursing application or to some clinical application, which needs the data about drugs dispensed or treatments given.
[Buitendijk, Hans] The first sentence implies now/future (“to fill”), while the second sentence implies past/after (“drugs dispensed or treatments given”). So go figure!
But OMS is clearly a stock requisition. So if we want to turn that into a dispense order, we need to clean up the definition a bit to enable the pharmacy system to tell the dispense cabinet what they are supposed to dispense (order control NW). And wouldn’t we be missing a number of the RXD fields?
It sounds like we need a clear interaction diagram of the interactions involving the stocking, replenishment, etc. of dispensing cabinets that may or may not be patient specific, and determine whether to use RDS, OMS, and/or some chapter 17 messages. I can very well see that we want to use RDS only for notifying the pharmacy that a dispense actually occurred (dispense cabinet issued 10 tablets to clinician ABC for administration to patient XYZ). But if so, OMS may be too generic for certain interactions, not having enough RXO, RXE, or RXD information and needs fixing or a new message. Whether that is Chapter 4 or Chapter 17 is tbd.
Best,
Tom
Van: Buitendijk, Hans [mailto:hans.bu...@siemens.com]
Verzonden: woensdag 20 maart 2013 21:22
Versie: 2013.0.2904 / Virusdatabase: 2641/6189 - datum van uitgifte: 03/19/13
***********************************************************************************
Jose Costa Teixeira
While i am looking at the parent / child orders, I would add two things to the discussion:
1. "The RDS message may be created by the pharmacy/treatment application for each instance of dispensing a drug or treatment to fill an existing order or orders. In the most common case, the RDS messages would be routed to a Nursing application or to some clinical application, which needs the data about drugs dispensed or treatments given. "
Given the fields and structure of RDS, my interpretation of this has been "The RDS message may be created by the pharmacy/treatment application for each instance of dispensing a drug or treatment that was needed to fill an existing order or orders"
The RDS appears after a dispense, which may necessary to fill an order.
If this is acceptable, then the RDS is the report of a dispense for a prescription. But i believe there is no better candidate than RDE for the functionality "Drug is to be dispensed" - which is one of the things we are missing.
2. Related to the dispense, there is one additional aspect: The fact that a prescription is ready for dispensing does not mean that a supply has to happen: for example if the patient still has that medication.
I'll be working to propose a diagram with the messages (just the functionality).
Again, thanks for this discussion.
Buitendijk, Hans
If there is general agreement/understanding that RDS is to be used to report on the dispense of a medication (but not yet administered), then we should prepare a V2.9 proposal to clarify this as the current text can lead one in multiple directions.
With such an adjustment, the logistics aspects are not clearly addressed either. Should we use OMS (Chapter 4) which is not drug focused (may be o.k.) and very much appears as a request for new supply, not an instruction to dispense, or should we use Chapter 17, section 17.5 where STI looks an awful lot like OMS, but focused on sterilization lots.
I’m looking forward to Jose’s interaction diagram where we then can determine what we could use, or whether we have to create something new (which is what I think where we’ll end up).
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
Jose Costa Teixeira
Just a short note to say that I had a virus problem and i should finish and send the diagrams tomorrow evening (American time).
I want to include the 2 cases - dispensers that can forward a change to another, or dispensers that simply obey, while the pharmacy system reroutes the orders.
I think the flow should be end-to-end, integrated with a prescription, so I am considering the dispensers that produce the outcome shown in the picture:
is this ok?
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Buitendijk, Hans" <hans.bu...@siemens.com>
To: Jose Costa Teixeira/AXGBB/AGFA@AGFA
Cc: "ihe-ph...@googlegroups.com" <ihe-ph...@googlegroups.com>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, "owner-p...@lists.hl7.org" <owner-p...@lists.hl7.org>, "phar...@lists.hl7.org" <phar...@lists.hl7.org>, "'Berge, Ruth E (GE Healthcare)'" <ruth....@ge.com>, "scott.m....@kp.org" <scott.m....@kp.org>, Tom de Jong <t...@nova-pro.nl>
Date: 22/03/2013 21:43
Subject: RE: Pharmacy question - dispensing
Sent by: owner-p...@lists.hl7.org
With such an adjustment, the logistics aspects are not clearly addressed either. Should we use OMS (Chapter 4) which is not drug focused (may be o.k.) and very much appears as a request for new supply, not an instruction to dispense, or should we use Chapter 17, section 17.5 where STI looks an awful lot like OMS, but focused on sterilization lots.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
mailto:hans.bu...@siemens.com
www.siemens.com/healthcare
Sent: Friday, March 22, 2013 4:21 PM
To: Buitendijk, Hans
Cc: ihe-ph...@googlegroups.com; 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; 'Berge, Ruth E (GE Healthcare)'; scott.m....@kp.org; Tom de Jong
[Buitendijk, Hans] Agreed that it is something different and needs to be identified independently from the originating order, but must be linked so thgrou can be acted on as one where needed. Challenge is that in the current V2 definitions this is not easily achieved. While it is possible to address the individual identification (by clarifying that ORC-2/ORC-3 apply to the focal segment of the message, e.g., OMP RXO, RD RXD, etc.) the linking may be problematic. There is only one ORC-8, so should the ORC/RXD pair point to the ORC/RXE or the ORC/RXO pair? How do you know which one it is as one does not have to start with an ORC/RXO, or may skip the ORC/RXE. Is there a clear rule we can establish, or do we need to add support for multiple parents? Or do we need to include in one message the full tree and require a different structure:
2 - We must further discuss / agree whether ORC-1 codes apply to the whole order mentioned in ORC-2, or just to the current message and corresponding part of the workflow - i.e. if a DC in a dispense request is just about the dispense part, or in the whole prescription?
[Buitendijk, Hans] When we solve the focal segment question of 1, this one becomes easy. We dt need to have solved the parent linking for this to be clear.
3 What is the difference between Validated Prescription and Dispense Request. What are the possible mechanisms to say "This encoded order has been processed enough, now it is ready for dispensing"?
4 When should one use an RDS message vs. an OMS message?
I dt understand the question. It is my understanding that RDS is used AFTER a dispense occurs (i.e. medication is tied to a specific patient, for example when medication is transferred to a cabinet). As far as I can tell, the OMS message is used to initiate a dispense. Differenmood co
The RDS message may be created by the pharmacy/treatment application for each instance of dispensing a drug or treatment to fill an existing order or orders. In the most common case, the RDS messages would be routed to a Nursing application or to some clinical application, which needs the data about drugs dispensed or treatments given.
[Buitendijk, Hans] The first sentence implies now/future to fi), while the second sentence implies past/after (drugs dispensed or treatments giv). So go figure!
But OMS is clearly a stock requisition. So if we want to turn that into a dispense order, we need to clean up the definition a bit to enable the pharmacy system to tell the dispense cabinet what they are supposed to dispense (order control NW). And woult we be missing a number of the RXD fields?
It sounds like we need a clear interaction diagram of the interactions involving the stocking, replenishment, etc. of dispensing cabinets that may or may not be patient specific, and determine whether to use RDS, OMS, and/or some chapter 17 messages. I can very well see that we want to use RDS only for notifying the pharmacy that a dispense actually occurred (dispense cabinet issued 10 tablets to clinician ABC for administration to patient XYZ). But if so, OMS may be too generic for certain interactions, not having enough RXO, RXE, or RXD information and needs fixing or a new message. Whether that is Chapter 4 or Chapter 17 is tbd.
Best,
Tom
Van: Buitendijk, Hans [mailto:hans.bu...@siemens.com]
Verzonden: woensdag 20 maart 2013 21:22
Aan: Berge, Ruth E (GE Healthcare); Jose Costa Teixeira
CC: 'o...@lists.HL7.org'; owner-p...@lists.hl7.org; phar...@lists.hl7.org; scott.m....@kp.org; Tom de Jong; ihe-ph...@googlegroups.com
Onderwerp: RE: Pharmacy question - dispensing
Jose and I had a quick side-bar and somehow the following questions raised to the top that may help us converge on an answer:
1 - We must discuss whether a dispense request is a"child" of an order, or a continuation. Meaning: during a prescription order workflow, if there is derived orders/requests (like dispense), do they have the same ORC-2 or they get a new ORC-2 and ORC-8 gets the prescription ID?
2 - We must further discuss / agree whether ORC-1 codes apply to the whole order mentioned in ORC-2, or just to the current message and corresponding part of the workflow - i.e. if a DC in a dispense request is just about the dispense part, or in the whole prescription?
3 What is the difference between Validated Prescription and Dispense Request. What are the possible mechanisms to say "This encoded order has been processed enough, now it is ready for dispensing"?
4 When should one use an RDS message vs. an OMS message?
If thmessage to switch cabinets must be sent to two separate systems, then we have two choices:
Buitendijk, Hans
Glad you, or your computer (whoever had the virus) is feeling better! J
Sounds good to me.
Tom de Jong
Hi Hans, Jose,
I have kept my promise and have left this discussion (after making sure it’s in safe hands;-) but I will surely look at José’s work flow diagrams. Thanks in advance for providing that input José! Like I said, I’m not an expert in the field of pharmacy logistics (I focus on the clinical aspects), but I was surprised how there could have been a misunderstanding about the proper use for RDS (especially coming from one of the chapter authors). As long as 8 years ago, I was teaching about the fact that RDS is used to report on dispense events occurring (and not being ordered to occur). Although the current description can certainly be improved, I don’t think it’s ambiguous. Anyway, that still leaves many questions to be answered. I’m glad Ruth’s question opened up the can of worms, because a good description of pharmacy logistics (and the relationship between pharmacy-specific and general logistics messages for that purpose) will be a valuable addition to the standard. Thanks both for taking on this challenge.
Best wishes,
Versie: 2013.0.2904 / Virusdatabase: 2641/6203 - datum van uitgifte: 03/25/13
Jose Costa Teixeira
Here is a descriptive use case and interaction diagram (transaction diagram and sequence diagram) for the drug dispensing, considering the demand placed by automated dispensers. I believe this covers all the current discussions.
First, I propose a scenario (please excuse me for not putting any real drug names) and then I proceed with listing the interoperability mechanisms. Then I apply the interoperability mechanisms to a storyline.
The storyline was actually my starting point, but since we want a set of interoperability mechanisms, I think the document should start with the design and then use the stories as a design validation.
There are lots of assumptions and scope constraints for sake of keping it reasonably clear. They are listed and i believe do not affect the scope.
As a next step, i think we can work on the Interaction Diagram and Summary part (page 7) and see if we have the mechanisms for that.
The way of working on this can be for example with more edge use cases to see if they are covered by these same mechanisms.
My opinion is that at least one interaction mechanism is missing in HL7; Also, working on this actually changed my mind when it comes to the way of using some of the messages (will be part of this next discussion).
PS: I decided to send this around as is for a first review - please feel free to comment on the form, template, any missing aspects etc.
PPS: Really sorry for the delay.
Diagram :
Diagram source:
Diagram done with PlantUML, http://plantuml.sourceforge.net/
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
Product Manager BI | HE/IMPAX BI Solution/Product Management
T +32 3444 8150
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Tom de Jong" <t...@nova-pro.nl>
To: "'Buitendijk, Hans'" <hans.bu...@siemens.com>, Jose Costa Teixeira/AXGBB/AGFA@AGFA
Cc: <ihe-ph...@googlegroups.com>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, <owner-p...@lists.hl7.org>, <phar...@lists.hl7.org>, "'Berge, Ruth E \(GE Healthcare\)'" <ruth....@ge.com>, <scott.m....@kp.org>
Date: 27/03/2013 01:46
Subject: RE: Pharmacy question - dispensing
Sent by: owne...@lists.hl7.org
I have kept my promise and have left this discussion (after making sure it’s in safe hands;-) but I will surely look at José’s work flow diagrams. Thanks in advance for providing that input José! Like I said, I’m not an expert in the field of pharmacy logistics (I focus on the clinical aspects), but I was surprised how there could have been a misunderstanding about the proper use for RDS (especially coming from one of the chapter authors). As long as 8 years ago, I was teaching about the fact that RDS is used to report on dispense events occurring (and not being ordered to occur). Although the current description can certainly be improved, I don’t think it’s ambiguous. Anyway, that still leaves many questions to be answered. I’m glad Ruth’s question opened up the can of worms, because a good description of pharmacy logistics (and the relationship between pharmacy-specific and general logistics messages for that purpose) will be a valuable addition to the standard. Thanks both for taking on this challenge.
Best wishes,
Versie: 2013.0.2904 / Virusdatabase: 2641/6203 - datum van uitgifte: 03/25/13
***********************************************************************************
Buitendijk, Hans
Great document to tease out what we have and what we need. Thank you!
A couple of comments using transactions listed on page 7/8 and then jumping to the suggested Event/Transaction tables starting page 9:
· I’m missing transaction 9 in the diagram on page 8. Would be helpful to have that in this summary diagram.
· Curious why we would consider RDE for event/transaction 1. Suggest we focus on OMP and let it be as encoded as the EHR-S/CPOE/OrdMgmtSystem can be.
· Agreed that event/transaction 2 is always RDE. We may need 2 back to CPOE as well to notify of any adjustments that Rx may have made that the ordering system should be aware of. Or do we prefer to use OMP messages back and forth using change requests/notification control codes?
· Not convinced that RDE is the right transaction for event/transaction 3. Does that require always the entire order to be sent (in which case that could work), or dispense requests one day at a time, or either? If dispenses need to be cancelled, changed, etc. would get confusing with the RDE that overall is not necessarily changing, e.g., order stays the same, but patient moves, so dispense instructions/locations/etc. need to adjust. My initial reaction is to consider a new dispense request message where the RDS is the to that message what RXA is to OMP/RDE.
· Based on e-mails, it seems to be most appropriate that event/transaction 4 uses RDS.
· If event/transaction 4 is RDS, then what is used to distinguish other dispense events from the actual dispense event? Could that be on the “new” Dispense Request message where the order control code could already manage most of that? May depend on whether we allow for one dispense request at a time (frequency “1”) or multiple dispense requests within one message (frequency “>1”, e.g., dispense 4 tablets daily for the next 5 days.) Or are there other events to be reported on that would not fit?
· If the intent is to only communicate the standard stock level, not the actual stock level, I can see using MFN messages, but the moment that we communicate actual stock levels with/without replenishment requests, they would be a kind of OMS message. Not convinced the current OMS message is sufficient with its RQD segment to support drugs, but that can be reviewed/expanded as needed.
· Event/transaction 7 and 6 are similar in intent, just between different systems and independent, hence using OMS in event/transaction 7 makes sense to me.
· Not sure what to use for event/transaction 8. RDS without PID may just work, or even RDS with PIDs, but not tied to any RXO/RXE specifically.
Looking forward to other comments and the next draft.
Thank you!
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org]
On Behalf Of Jose Costa Teixeira
Sent: Friday, March 29, 2013 12:02 PM
To: Tom de Jong
Cc: Buitendijk, Hans; ihe-ph...@googlegroups.com; 'o...@lists.HL7.org'; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; 'Berge, Ruth E (GE Healthcare)'; scott.m....@kp.org
Subject: RE: Pharmacy question - dispensing
Hello
Hi Hans, Jose,
I have kept my promise and have left this discussion (after making sure its in safe hands;-) but I will surely look at Jos work flow diagrams. Thanks in advance for providing
that input Jos! Like I said, Im not an expert in the field of pharmacy logistics (I focus on the clinical aspects), but I was surprised how there could have been a misunderstanding about the proper use for RDS (especially coming from one of the chapter authors).
As long as 8 years ago, I was teaching about the fact that RDS is used to report on
dispense events occurring (and not being ordered to occur). Although the current description can certainly be improved, I dt think its ambiguous. Anyway, that still leaves many questions to be answered. Im glad Rus question opened up the can of worms,
because a good description of pharmacy logistics (and the relationship between pharmacy-specific and general logistics messages for that purpose) will be a valuable addition to the standard. Thanks both for taking on this challenge.
Buitendijk, Hans
Tom de Jong
Hi José,
As usual, you’ve done an impressive job in handling this. I don’t have the time to dive into it right now (and like I said, I don’t consider myself a domain expert when it comes to the logistics side). I do hope others besides Hans will take a look. Would you like to discuss on a conference call?
Best wishes,
Tom
Jose Costa Teixeira
I think that after a few round trips we should indeed discuss on a tcon and define the scope(s) and impact.
Some quick comments while i update the document (i'll put this discussion in the doc to avoid mining mail threads.):
(...)
· Not convinced that RDE is the right transaction for event/transaction 3. Does that require always the entire order to be sent (in which case that could work), or dispense requests one day at a time, or either? If dispenses need to be cancelled, changed, etc. would get confusing with the RDE that overall is not necessarily changing, e.g., order stays the same, but patient moves, so dispense instructions/locations/etc. need to adjust. My initial reaction is to consider a new dispense request message where the RDS is the to that message what RXA is to OMP/RDE.
[JoseCT] I think that RDE may be right, but not RDE^O11. O11 means “order encoded”. We need an event ^OXX, similar to O25, but clearly aiming at the Dispense request. Since RDE has accumulated some stuff that seems required for dispense requests, this would still not be ideal but would increase backwards compatibility.
(...)
· If event/transaction 4 is RDS, then what is used to distinguish other dispense events from the actual dispense event? Could that be on the “new” Dispense Request message where the order control code could already manage most of that? May depend on whether we allow for one dispense request at a time (frequency “1”) or multiple dispense requests within one message (frequency “>1”, e.g., dispense 4 tablets daily for the next 5 days.) Or are there other events to be reported on that would not fit?
[JoseCT] if I understand what you mean, I believe that if we go for parent/child orders AND clear up the use of ORC-1 and ORC-5 in those scenarios, this would clear itself. Also we'd have to use statuses for things like "i was asked to dispense 4 x 5 items, so far I managed to dispense 1x5, it's in progress".
· If the intent is to only communicate the standard stock level, not the actual stock level, I can see using MFN messages, but the moment that we communicate actual stock levels with/without replenishment requests, they would be a kind of OMS message. Not convinced the current OMS message is sufficient with its RQD segment to support drugs, but that can be reviewed/expanded as needed
[JoseCT] I think we must make a very clear distinction between requesting an item and stating the current inventory level. The status update can be done after a change in stock levels (for example a dispense, or a refill) or as response to a request. So I’d definitely separate OMS from this “stock status update”. In addition, some systems may use one message, or the other, or both. Should I elaborate on that?
Default stock level is a typical case for MFN indeed. But I think that the current definition of M16 is for actual stock levels:
“8.12.1: (…) the dispensing system would communicate the lot numbers, expiration date and quantity on hand for service items in inventory using the Inventory Item Master file message.”
· Event/transaction 7 and 6 are similar in intent, just between different systems and independent, hence using OMS in event/transaction 7 makes sense to me.
[JoseCT] As above, one of the events for 6 may be the same as the event for 7, but the intent is different. One is “I need more”, the other one is “here’s my current level, someone will decide whether I need more, or if I have too many...”.
· Not sure what to use for event/transaction 8. RDS without PID may just work, or even RDS with PIDs, but not tied to any RXO/RXE specifically.
[JoseCT] That would be very clean and would work well.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
http://blog.agfahealthcare.com
Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer
From: "Tom de Jong" <t...@nova-pro.nl>
To: Jose Costa Teixeira/AXGBB/AGFA@AGFA
Cc: "'Buitendijk, Hans'" <hans.bu...@siemens.com>, <ihe-ph...@googlegroups.com>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, <owne...@lists.hl7.org>, <owner-p...@lists.hl7.org>, <phar...@lists.hl7.org>, "'Berge, Ruth E \(GE Healthcare\)'" <ruth....@ge.com>, <scott.m....@kp.org>
Date: 03/04/2013 03:30
Subject: RE: Pharmacy question - dispensing
Sent by: owne...@lists.hl7.org
As usual, you’ve done an impressive job in handling this. I don’t have the time to dive into it right now (and like I said, I don’t consider myself a domain expert when it comes to the logistics side). I do hope others besides Hans will take a look. Would you like to discuss on a conference call?
Best wishes,
Tom
Van: Jose Costa Teixeira [mailto:jose.cost...@agfa.com
Verzonden: vrijdag 29 maart 2013 17:02
Buitendijk, Hans
Having a conference call to step through the diagram and the suggested flows (pros/cons, proposed transaction) would be great. Would using an IHE call work? Should we have a separate call of interested parties?
See some comments below.
Hans J. Buitendijk M.Sc., FHL7
HS Standards & Regulations Manager
Siemens Healthcare
Siemens Medical Solutions USA, Inc.
51 Valley Stream Parkway,
Malvern, PA 19355-1406
Phone: +1 610 219 2087
Mobile: +1 484 354 6474
Fax: +1 610 219 1273
From: owne...@lists.hl7.org [mailto:owne...@lists.hl7.org]
On Behalf Of Jose Costa Teixeira
Sent: Wednesday, April 03, 2013 5:53 PM
To: Tom de Jong
Cc: Buitendijk, Hans; ihe-ph...@googlegroups.com; 'o...@lists.HL7.org'; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; 'Berge, Ruth E (GE Healthcare)'; scott.m....@kp.org
Subject: RE: Pharmacy question - dispensing
Thank you
I think that after a few round trips we should indeed discuss on a tcon and define the scope(s) and impact.
Some quick comments while i update the document (i'll put this discussion in the doc to avoid mining mail threads.):
(...)
(...)
If event/transaction 4 is RDS, then what is used to distinguish other dispense events from the actual dispense event? Could that be on thene Dispense Request message where the order control code could already manage most of that?
May depend on whether we allow for one dispense request at a time (frequenc1) or multiple dispense requests within one message (frequency >,
e.g., dispense 4 tablets daily for the next 5 days.) Or are there other events to be reported on that would not fit?
[JoseCT] if I understand what you mean, I believe that if we go for parent/child orders AND clear up the use of ORC-1 and ORC-5 in those scenarios, this would clear itself. Also we'd have to use statuses for things like "i
was asked to dispense 4 x 5 items, so far I managed to dispense 1x5, it's in progress".
[Buitendijk, Hans] Another way is to use RDS only for event/transaction 5, and create new trigger event for 4, using the same message structure. Then we don’t necessarily need new control codes, but with other fields work through it.
Event/transaction 7 and 6 are similar in intent, just between different systems and independent, hence using OMS in event/transaction 7 makes sense to me.
[JoseCT] As above, one of the events for 6 may be the same as the event for 7, but the intent is different. One is I need mo, the other one is hers my current level, someone will decide whether I need more, or if I have too many..
[Buitendijk, Hans] Agreed, but either way current OMS message may not be sufficient anyway, so have to look at having additional segments, and/or trigger events.
Not sure what to use for event/transaction 8. RDS without PID may just work, or even RDS with PIDs, but not tied to any RXO/RXE specifically.
[JoseCT] That would be very clean and would work well.
Kind Regards,
Jose Costa Teixeira | Agfa HealthCare
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer:
http://www.agfahealthcare.com/maildisclaimer
From: "Tom de Jong" <t...@nova-pro.nl>
To: Jose Costa Teixeira/AXGBB/AGFA@AGFA
Cc: "'Buitendijk, Hans'" <hans.bu...@siemens.com>,
<ihe-ph...@googlegroups.com>, "'o...@lists.HL7.org'" <o...@lists.hl7.org>, <owne...@lists.hl7.org>, <owner-p...@lists.hl7.org>,
<phar...@lists.hl7.org>, "'Berge, Ruth E \(GE Healthcare\)'" <ruth....@ge.com>, <scott.m....@kp.org>
Date: 03/04/2013 03:30
Subject: RE: Pharmacy question - dispensing
Sent by: owne...@lists.hl7.org
Hi Jé,
As usual, yve done an impressive job in handling this. I dot have the time to dive into it right now (and like I said, I dot consider myself a domain expert when it comes to
the logistics side). I do hope others besides Hans will take a look. Would you like to discuss on a conference call?
Hi Hans, Jose,
I have kept my promise and have left this discussion (after making sure s in safe hands;-) but I will surely look at Jÿs work flow diagrams. Thanks in advance for providing that input Jo! Like I said, m not an expert in the field of pharmacy logistics (I focus
on the clinical aspects), but I was surprised how there could have been a misunderstanding about the proper use for RDS (especially coming from one of the chapter authors). As long as 8 years ago, I was teaching about the fact that RDS is used to report on
dispense events occurring (and not being ordered to occur). Although the current description can certainly be improved, I dont think s ambiguous. Anyway, that still leaves many questions to be answered. m glad Ruts question opened up the can of worms,
because a good description of pharmacy logistics (and the relationship between pharmacy-specific and general logistics messages for that purpose) will be a valuable addition to the standard. Thanks both for taking on this challenge.
Simon Letellier
Uses of automated dispensing systems
- Goal : step through the diagram (shared on the mailing lists) and the suggested flows (pros/cons, proposed transaction)
1) scope : 20 minutes
2) discussion : 30 min
3) wrap up & next steps : 10 min
Meeting information
-------------------------------------------------------
Topic: IHE Pharm "Supply chain" meeting
Date: Monday, April 15, 2013
Time: 4:00 pm, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 951 176 558
Meeting Password: (This meeting does not require a password.)
-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to https://phastinternational.webex.com/phastinternational-en/j.php?ED=211101337&UID=507572&RT=MiMyMw%3D%3D
-------------------------------------------------------
Audio conference information
-------------------------------------------------------
Call-in toll number (UK): +44-203-478-5289
Global call-in numbers: https://phastinternational.webex.com/phastinternational-en/globalcallin.php?serviceType=MC&ED=211101337&tollFree=0
Access code:951 176 558
Simon Letellier
IHE Pharmacy secretary
sletellier@ihe.net
Integrating the Healthcare Enterprise
Come to Connectathon, Istanbul, Turkey, 14-19 April 2013
-------------------------------------------------------------------------------
--
Stephen Chu
Hi Simon,
Monday 4:00pm US Eastern is the regular HL7 Pharmacy call. Is this call that you have scheduled arranged with HL7 Pharmacy?
I would prefer the call to be at 5:00pm US Eastern.
Regards,
Stephen
-------------------------------------------------------------------------------
Simon Letellier
IHE Pharmacy secretary
slete...@ihe.net
Integrating the Healthcare Enterprise
The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files.
Simon Letellier
it means midnight for Sydney time (GMT+10).
Our other Tcon is the regular one.
I hope you'll be able to join it May 2nd :
Best,
-------------------------------------------------------------------------------
Simon Letellier
IHE Pharmacy secretary
slete...@ihe.net
Integrating the Healthcare Enterprise
http://www.ihe.net
Come to Connectathon, Istanbul, Turkey, 14-19 April 2013
http://cat2013.org
-------------------------------------------------------------------------------
IHE Pharmacy secretary
sletellier@ihe.net
Jacqueline Surugue
Dear Simon,
I am sorry I will not be in the position to attend this Tconf. I have to co Chair the IHE Europe General Assembly and IHE Europe Steering Committee which take place on that very day in Instanbul, Turquey.
With sincere apologies,
Best wishes,
Jacqueline
Jacqueline Surugue
IHE Europe Co Chair for Users
Integrating the Healthcare Enterprise
Come to Connectathon, Istanbul, Turkey, 15-19 April 2013
Pharmacien Chef
Centre Hospitalier Georges Renon
40 avenue Charles de Gaulle
79021 NIORT
France
Secrétariat: +33 (0)5 49 78 32 05
Fax: +33 (0)5 49 78 32 13
Courriel: jsur...@gmail.com
De : ihe-ph...@googlegroups.com [mailto:ihe-ph...@googlegroups.com] De la part de Simon Letellier
Envoyé : mardi 9 avril 2013 23:44
À : IHE Pharmacy Google Group
Cc : Jose Costa Teixeira; Tom de Jong; o...@lists.HL7.org; owne...@lists.hl7.org; owner-p...@lists.hl7.org; phar...@lists.hl7.org; Berge, Ruth E (GE Healthcare); scott.m....@kp.org
Objet : Re: [IHE-Pharmacy:1691] RE: Pharmacy question - dispensing
slete...@ihe.net
Integrating the Healthcare Enterprise
Jose Costa Teixeira
Recently, with your use case of the ADCs, you presented a complete end-to-end use case that touches these questions. Before, there were no clarity on the HL7 mechanisms, so it would be difficult to implement such use case.
If you agree, I would try to have this discussion as planned, and then I suggest a discussion on IHE about Jacqueline's use case and dispensing mechanisms in a tcon (ad-hoc or scheduled).