V2 OVR segment

V2 OVR segment

Statement of use case

From Hans Buitendijk

We are running into a need to send a name-value pair repeating without having to proposed a new segment. Has there been any discussion in the past to create a name-value pair data type to allow this?

The topic we're trying to address is the ability to indicate within a message that certain segment (groups) are to be treated in snapshot mode while others in update mode. Currently various segments have action codes, but not all. So to have a more general approach it would be helpful to have in the MSH a name-value pair that can repeat to indicate whether the segment (group) is to be managed in snapshot or update mode (where the default is snapshot if nothing is sent).

So some example may be: • Insurance - Snapshot • Authorization - Update • Next of Kin - Snapshot So a data type, e.g., NVP for NameValuePair, could be made up of Name CWE components + Value CWE components.

Clearly, creating a separate segment, e.g., Process Mode, with Segment (Group) Name (CNE) and Process Mode (CNE or ID) could work, but then we may have to over time create more segments for similar needs, rather than adding a repeating field with data type NVP.

Thoughts on what direction you think would be a reasonable V2.x approach?

From Tony Julian

Would not the OVR segment provide the usage needed? While the definition says “Definition: This segment allows a sender to override specific receiving application's business rules to allow for processing of a message that would normally be rejected or ignored.” Tony Julian 20:43, 4 October 2010 (UTC)

Existing Chapter 2 2.14.11 OVR

2.14.11 OVR – override segment Definition: This segment allows a sender to override specific receiving application's business rules to allow for processing of a message that would normally be rejected or ignored. In many instances, business rules will be set as guidelines relative to patient care. In some instances it is in the patient's better interest to circumvent these guidelines. In other cases, business rules may exist to support normal process flow, but which may be bypassed or ignored under certain special circumstances. This segment is linked to the proposed ERR segment changes in that the first attempt to process a transaction that violates a business rule may result in an error that must be overridden. The ERR provides a mechanism to identify errors that may be overridden, as well as the allowed override codes. Use case #1: A patient has received a prescription with a duration of 30 days and receives the full amount at their pharmacy. While at home the patient accidentally spills the container and spoils a significant proportion of the prescription. The patient returns to their pharmacy and explains the situation to the pharmacy technician. The technician consults with their supervising pharmacist. Knowing the patient, the pharmacist decides to override the business rule stating that the dispensed amount for a prescription may not exceed the prescribed amount. In recording the decision, the pharmacy technician specifies that the Override Type is a "Compassionate Refill" and that the Override Code, or reason for the override, is "Spoilage". The technician also provides Override Comments to provide an explanation of the situation for future reference. While recording the decision, the technician's user ID is automatically stored in an Override Recorded By field. The pharmacist's ID is stored in the Override Responsible Provider field. Use case #2:A hospital wishes to submit an invoice to an insurer who is providing secondary coverage. The invoice is being submitted over a week after the service was performed, which is outside the insurer's normal accept time window. The insurer would normally reject the invoice. However, the submitter includes an Override Type of "late submission" as well as an Override Code indicating that the invoice is late due to delays with the primary payor. The secondary insurer examines the override reason and accepts the invoice. Usage Note: The override segment should be included in messages adjacent to the segment(s) containing the information that would trigger the business rule(s) that needs to be overridden. The segment should be optional (you shouldn't always need to override business rules), and should be allowed to repeat in circumstances where there may be more than one business rule overridden at the same time. Committees may wish to provide suggested values for override types or codes for use with the OVR segment in different messages. The following is an example of how the OVR segment might be used in a dispense message (RDS_O13): MSH PID PV1 {ORC RXE {RXR} RXD {RXR} <RXC> <NTE> <FT1> <OVR>}

Proposal to add the following to the Usage Note:

The override segment is permitted in any message, following the segment where it applies. When the override segment follows the MSH, it applies to the whole message. When the override is included in a segment group, the override applies to the segment group. Example of how the OVR segment might be used to apply to the entire message. MSH [{OVR}] - applies to the entire message [{SFT}]

Example of how the OVR segment might be used to apply to the observation segment group MSH [{ SFT }] [UAC] {

 [ --- PATIENT begin
    PID
    [PD1]
    [{PRT}]Participation (for Patient)
    [{NTE}]
    [{NK1}]
    [{-- PATIENT OBSERVATION begin
      OBX Observation (for Patient ID)
      [{PRT}] Participation (Observation Participation)
    }]-- PATIENT OBSERVATION end
    [--- VISIT begin
      PV1
      [PV2]
      [{PRT}] Participation (for Patient Visit)
    ]--- VISIT end
  ]--- PATIENT end
  {--- ORDER_OBSERVATION begin
     [ORC]
     OBR Observations Request
     {[NTE]}
     [{PRT}] Participation (for Observation)
  [-- TIMING_QTY begin
        TQ1
        [{TQ2}]
  ]--- TIMING_QTY end
     [CTD]
  [-- OBSERVATION begin
       OBX Observation related to OBR
       [{PRT}] Participation (Observation Participation)
       {[NTE]}
      [{OVR}] Override for Observation Group        
     }]   --- OBSERVATION end
     [{FT1}]
     {[CTI]} Clinical Trial Identification
     [{--- SPECIMEN begin
       SPM Specimen
       [{--- SPECIMEN OBSERVATION begin
         OBX Observation (for Patient ID)
         [{PRT}] Participation (Observation Participation)
       }]--- SPECIMEN OBSERVATION end
     }]--- SPECIMEN end
  }   --- ORDER_OBSERVATION end

} --- PATIENT_RESULT end

[{

20101005 Notes

The Work Group agrees with the concept - but requires that the segment be documented in the message structures, as well as the Work Group/editor documenting the implementation usage. The Work Group may also wish to group items such as allergies when using this segment. InM suggests that the OVR fall before the segment/segment group where it applies. Most processors of Version 2 messages process serially - therefore it would be better to know the updating mode being used before processing the segment.

Because of the naming, suggestion was made that a new segment be added. This would be more specific, and more exact. Tony will communicate our recommendation with Hans. Tony Julian 15:54, 5 October 2010 (UTC)