There is an e-mail thread by Lloyd MacKenzie about the growing interest at the TSC for a new ITS project to develop a new "wire format compatible" ITS that is based on Datatypes Abstract R2 intended to exist in parallel with the existing HL7 R2 Datatypes ITS (ISO 21090). This is due to some limitations in R1. But rather than creating a 1.1, interest is to have two R2 standards.
There is no specific timeline set yet but the TSC will meet Monday
If we have comments, we need to feed comments to Steering Division rep.
If the topic is controversial enough the decision might be deferred - expect a lot of discussion.
OO will officially stay out of this debate.
The scope statement and other administrivia should be taken care of shortly.
May WGM is the last opportunity to submit a new proposal, after which we get ready for V2.8 ballot in the September roun.
We reviewed this proposal with InM group this week.
They expressed a preference to call it segment group header.
They indicated that we not only need to have a beginning, but also indicate the end, because you could have prior results segment group for each order in a set of multiple orders, so now we are actually requesting 1 new segments!
This proposal is picked up by InM with full agreement.
Need to clarify when to use Trigger Events (control codes) and therefore the order message, vs. when a state change is communicated for Cancel in particular Hans will take a first cut at this language.
Need to create a V2.8 proposal to add a new control code to enable an LIS to send an order cancellation message (Cancel Process Step (CP)). Andrzej will create this.
Need to determine whether a new Result Status is required at the OBX level to indicate that indicates that the test was attempted, but could not be completed. Ken McCaslin will follow-up with ACLA to determine need and naming. March 3 target to review with ACLA.
No update yet. Notes below are from past meetings for ease of reference.
Motion to respond that RP/RU/… is the available means to replace (and link old inactive with new active) orders. If that is not sufficient, a business case is required to propose an update in V2.8/9 Scott Robertson, Patrick Loyd.
Scott will check with Tom to see whether this works.
Will pick it up next week as we ran out of time.
Background - The yellow highlighted is from Scott Robertson e-mail:
A question has been lingering in Orders and Pharmacy concerning the ability to "link" orders together. HL7 v2.x has limited capability for defined relationships between orders:
Replacement Orders - RP/RU/RO/UM/RQ Order Control Codes define a specific relationship between two orders in which one order replaces another. This has been fairly consistently described since (or prior to) v2.2. In v2.6, it is found in Section 4.23.1 "HL7 Table 0119 - Order Control Codes":
"A replacement is the substitution of one or more orders for one or more previously ordered services.
The replaced orders are treated as though they were canceled. If and when an ordered service can be replaced are local site-specific determinations "
This is the preferred method for indicating that one order (the replacement order [RO]) is superseding another (the replaced order [RP/RU])
Parent/Child Orders - PA/CH Order Control Codes defines a relationship in which one or more orders are spawned from original order. The original/parent order remains intact. This is described in v2.6 Section 4.23.1 "HL7 Table 0119 - Order Control Codes":
"The parent (PA) and child (CH) order control codes allow the spawning of "child" orders from a "parent" order without changing the parent (original order). One or more ORC segments with an ORC-1-order control value of PA are followed by one or more ORC segments with an ORC-1-order control value of CH. Whether OBR segments must be present is determined by the value of ORC-6-response flag. "
PA/CH are also referred to in the discussion under RO:
"Use the parent/child order control codes if the site specifies that the original order must remain intact. Do not use the replacement codes under this circumstance."
Thus, it is possible establish a relationship between many orders (multiple parents/multiple children), although the parent/child relationship does imply some hierarchy. Also, any one child order can only reference a single parent in ORC-8 - Parent (i.e., this field does not repeat).
Proximate Orders. The structure of (most) order messages permits more than one ORC structure within the message. This is necessary for direct relationships, such as RP/RO messages, but may also be used to imply relationships between multiple orders in the message. This could imply that the orders are part of some larger association (e.g., a panel or pre-defined/standing orders), or have a more directed relationship (e.g., Discontinue (DC) and New Order (NW) - although RP/RO is preferred in this case). Since this is not described to any extent in the standard, it is up to implementation to define the intention (if any) of proximate orders.
Link/Unlink Orders - LI/UN Order Control Codes are intended for linking orders to patient care problems/goals. This is described in Chapter 12, Section 18.104.22.168 "Rule 6":
Order segments are sent with Problem and Goal segments in order to establish a linkage between them, NOT to communicate new orders or changes to those orders. For purposes of these messages, an LI (Link) and a UL (Unlink) code have been added to HL7 table 0119 - Order control. "
Note that the intent is not to link orders to other orders.
The question which started the thread had specific questions:
How do you judge each of these approaches [a message with DC/NW vs a message with RP/RO]?
Yes, well, it is ... sort of. Addition of narrative specifically addressing the DC/NW vs RP/RO would be helpful. We could consider adding narrative describing the "linking options" (above). In anticipation of the changes, we could add this discussion to the V2 FAQ wiki page (http://wiki.hl7.org/index.php?title=HL7_V2_FAQ) (or other appropriate place).
Another point from the originating question: When is a "replacement" order necessary? In my experience, this is a local policy and/or jurisdictional issue. I would venture that changing the medication in an order would force a replacement in any implementation. Changing the quantity may be permitted as an edit for some locations/products, while other situations may force a new order for a quantity change.