Orders & Observations Conference Call 10–March-2011 +1 770 657 9270, Passcode: 653212# Attendees




Дата канвертавання24.04.2016
Памер37.43 Kb.
Orders & Observations Conference Call

10–March-2011

+1 770 657 9270, Passcode: 653212#
Attendees:


Name

Organization

Rita Altamore

Washington State Department of Health

Austin Kreisler

SAIC / CDC

Scott Robertson

Kaiser Permanente

Rob Savage

NGC / CDC


Ken McCaslin

Quest Diagnostics

Lynn Laakso

HL7

Hans Buitendijk

Siemens Healthcare

Riki Merrick

IConnect Consulting / APHL

Cindy Vinion

NGC / CDC

Brian Pech

Kaiser Permanente

Debbie Bogert

Canada Health Infoway

Patrick Loyd

GP Informatics

Ron van Duyne

CDC

Rob Hausam

OntoReason

Elaine Ayers

NIH


























Co-Chair: Hans Buitendijk

Scribes: Riki Merrick, Hans Buitendijk
Agenda/Minutes:

  • Meeting Minutes Approval

    • Conf Call Meeting Minutes: 3 March 2011

      • Clarify what yellow highlights mean.

      • Motion to accept. Rob Savage, Ken McCaslin

        • Against: 0; Abstain: 0; In Favor: 12



  • S&I Framework Lab Initiative – Update – Rob Hausam

    • A couple of meetings are in progress

    • The scoping sub-group meeting needs to be done by Thursday next week.

      • Meetings tomorrow and Monday, but still an impossible deadline.

      • Concerned that we end up rushing this losing buy-in.

      • The group does not want to exclude full departments. Working on how to include without excluding full departments.

      • Considering parent/child exclusion, but counter argument is to include bread/butter micro.

    • Structured Data – Unknown deadline. Hans and Austin will join the meeting tomorrow.

    • The main meeting this afternoon is expected to focus on comment resolution.



  • Mission Statement Follow-Up – Patrick Loyd

    • FLUPs: (not discussed – next week)

      • Consider “commands” Chapter 13 to be covered somewhere. General agreement, but need to be wordsmithed (Patrick/Andrzej).

      • Update formal relationships when above is agreed to.



  • Behavioral Model Update – Patrick Loyd

    • Training for facilitators has been set up for next week Tuesday. Lorraine/John will teach

    • This will help to create the ballot materials

    • Other progress delayed to prep for the training

    • Then start to move forward again.



  • Composite Order Model Update – Patrick Loyd

    • We looked at lab order last week

    • We will pick up ballot reconciliation today after the remainder of the agenda

    • Patrick has been working to update to most current RIMish representation, RMIM, DMIM and lab order and can look at those next week

    • Also we will have project scope statement for review to the group next week

    • We re-started ballot reconciliation. The updates are attached.





  • ITS Position

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



  • V2.8 Proposals

    • Timeline

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

    • 658 - http://wiki.hl7.org/index.php?title=OO_CR037-658_Timing_Quantity_Fix

      • Being discussed with Pharmacy.

      • We initially were proposing 2 new fields, now there might be a need for multiple cumulative dosages at specific timeline (one for a day or week, vs. lifetime)

      • The attached proposal is updated accordingly to ask for new segment that includes cumulative dose limit, time limit and threshold limit

      • That way the segment could repeat.

      • One question came up whether the threshold concept is needed. Can it be handled in V3? Folks are checking that out this week.

      • We need to finish out conversation with Pharmacy should have final to review next week.

    • 678 - http://wiki.hl7.org/index.php?title=OO_CR050-678_Segment_Group_End

      • 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!

      • Now we want a segment header and segment trailer to place between the optional and repeat brackets

      • Austin: What happens when the groups are not optional?

        • Hans: If you have a group with potential confusion, you should include it.

      • Austin: You can no longer introduce a group with optional first segments.

        • That is correct, but in this case it is unavoidable as there is no other way to make it clear while maintaining backwards compatbility.

      • Austin motions to accept the proposal as modified.

        • This will fix the problem in the message where we need it.

        • Are there other use cases, where this might apply?

        • We need to go through each of the messages in Chapter 4 to look, if any of them would have issues with this approach.

      • Ken: Is this really necessary – feels funny to me.

      • Alternative is to scrap message and go to different mechanism to handle prior result messaging.

        • V2.x does not solve context very well – in other places we do that positionally, which we agree is normally bad. In this case the position is not helping.

        • If you use XML encoding in v2, you don’t have that problem. But we cannot say use only XML for this, because the standard is actually the pipe delimited format.

        • If we can change this programmatically, why change the standard?

      • Jonathan seconds the motion.

        • against: 0, abstain 3, in favor: 12

      • Hans will update proposal with specific messages that have to include these segments and forward the update to InM.

    • 683 - http://wiki.hl7.org/index.php?title=OO_CR053-683_Acknowlegement_Clarification

      • This proposal is picked up by InM with full agreement.

    • Open FLUPs

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



  • Replacement Orders

    • 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 12.1.5.6 "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]?

      • Is there a better way to do this in the standard?

        • options described above

      • Shouldn’t a best practice for this be specified?

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


Future:


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка