Scope: What include and exclude in 3
May 2001 Minutes
Orders/Observations Worksession
Table of Contents
Table of Contents 1
Attendees 3
Monday, May 7, 2001 5
Version 2.x - Blood Bank Messages 5
Version 2.x – Joint with LAPOCT 5
V2.x – Timing/Quantity/Repeat Pattern 5
Version 2.x – Other Proposals 5
Tuesday, May 08, 2001 5
V3 5
Joint SD/II/OO 7
Joint Vocab 7
Lab RMIMs 8
Wednesday, May 09, 2001 9
V3 9
Joint LAPOCT/OO – Specimen CMET 9
Thursday, May 10, 2001 10
Common Order/Intent/Event State Change Messages 10
Joint Rx 11
Friday, May 11, 2001 12
Publication Update 12
Image Integration 12
V2.x 12
Attachment A: V2.x Proposals 13
14 - Establish an Inventory Master message 13
16 - Define a Reference Range (RFR) data type 17
17 - Define a Delta (DLT) data type 18
21 - Specimen Source Data Type 19
23 - Create a new segment - IIS - "Imaging Information Segment" 21
39 - Add values to HL7 Table 0371- Additive 26
40 - Define HL7 Table NNNN - Specimen Collection Method 27
41 - Define HL7 Table NNNN Body Parts to replace HL7 Table 0163 Body Site 28
42 - Define HL7 Table NNNN Body Parts Modifier 29
50 - Prescription Refill Request (ZPR) 30
57 - OM2-6 Change data type to RFR 34
58 - OM2-7 Change data type to RFR 35
59 - OM2-8 Change data type to RFR 36
60 - OM2-9 Change data type to DLT 37
70 - OM2-7 Critical Range Change component model 38
75 - Combine Tables 0286 and 0443 and change table type to HL7 39
85 - OBX-2 length correction 40
87 - Section reference correction 41
89 - Editorial correction 42
93 - Section 4.5.3.32 technical correction 43
94 - Section 4.5.3.34 technical correction 44
95 - ORC – Security/Sensitivity 45
96 - RXO – Order Type 47
97 - ORC – Action Authorization Mode 49
99 - RDI – Drug Information Segment (new segment) 51
100 - RXD – Dispense Type 53
101 - RXE – Dispensing Interval 55
109 - Correct data type component model for RXD-12 Total Daily Dose 56
110 - Correct PRD-7 and CTD-7 references to PRA-6 57
111 - Add constraint language to Table 0080. 58
113 - Revise repetition structure for RXC-NTE in Pharmacy Messages 59
114 - Replace the TQ data type with two new segments, the TQ1 and TQ2 64
117 - Reformat Service/Test/Observation Master Trigger Events at Heading 3 level 89
118 - Blood Bank Messages 91
120 - Add language to chapters 7 and 9 clarifying when the MDM message should be used rather than the ORU 121
121 - Add MDM message example 123
122 - Clarify OML trigger events and message originators 125
123 - Authoritative Use Statement: CIC - New ORU Trigger Proposal 126
126 - Apply recently approved NR Numeric Range data type to relevant OM2.6 components 129
128 - Apply RI Repeat Interval data type to TQ Timing/Quantity data type component 2 130
129 - Add correction for OM2-7 and OM2-8 inconsistencies to V2.4 and V2.3.1 errata lists 134
130 - Reorganize Waveform documentation beginning with section 7.14 of chapter 7 and correct data type omissions 135
131 - Add correction to TQ data type component 10 to v 2.4 and v 2.3.1 errata lists 139
133 - Create new HL7 Table nnnn- Specimen Type to replace existing HL7 Table 0070- Specimen Source 140
134 - Add values to HL7 Table 0376- Special handling considerations 148
137 - Add corrected component model to CD data type and to segment fields OM2-6 and OM2-9 to v 2.3.1 errata list 150
Attachment B: SDA Discussion Document 152
Attachment C: RMIMs 162
Attendees
|Attendee |Company/E-Mail |Mon AM |Mon PM |Tue AM |Tue PM |Wed AM |Wed PM |Thu AM |Thu PM |Fri |
|Krishna Anedath |Krishna.anedath@ | | | |( | | | | | |
|Michael Aryev |Michael.aryev@ |( | | | | | | | | |
|Jos Baptist |Jbaptist@wxs.ne | | | |( | | | | | |
|Calvin Beebe |Cbeebe@mayo.edu | | | |( | | | | | |
|Fred Behlen |f-behlen@uchicago.edu | | | |( | | | | |( |
|Hans Buitendijk |Hans.buitendijk@ |( |( |( |( |( |( |( |( |( |
|Tina Buckeye |Tina@ |( | |( |( |( |( | | | |
|Jim Case |Jtcase@ucdavis.edu |( | | |( |( |( |( |( |( |
|Howard Clark |How_clark@ | | | |( | | | | | |
|Carmella Couderc |Carmella.couderc@ | | | |( | | | | | |
|Miklos Csore |Miklos@ |( | |( | | | | | | |
|Bob Dolin |Robert.h.dolin@ | | | |( | | | | | |
|Jeff DuBois |Jadubois@ |( | | | | | | | | |
|Tammy Dugan |Tdugan@ |( | | | | |( | | | |
|Dav A. Eide |Eide.d@ |( |( |( |( |( |( |( |( | |
|Becky Fan |Cobfan@ |( | |( | | | | | | |
|John Fehrenbach |John@ | | | |( | | | | | |
|Charles Fisher |Cfd02@health.state.ny.us | | |( | | | | | | |
|Edgar Glück |Edgar.gluck@kith.no | | | | |( |( | | | |
|Andrew Goodchild |Andrew@dstc.edu.au | | | |( | | | | | |
|Louis R. Gordon |Louis_gordon@ |( | | | | | | | | |
|Charles Hawker |Hawkercd@ |( | | | | |( | | | |
|Stan Huff |Coshuff@ | | | |( | | | | | |
|Dean Ibaraki |Dean.ibaraki@ | | |( | | | | |( | |
|Rose Jenkins |Rosemarie.jenkins@ |( |( |( |( |( |( |( | |( |
|Dan Jernigan |Dbj0@ | | |( | | | | | | |
|Gaby Jewell |Gjewell@ |( | |( | | | | | | |
|Andrzej J. Knafel |Andrzej.knafel@ |( | | | | |( | | | |
|Helmut König |Helmut.koenig@shs-online.de | | | |( | | | | |( |
|Austin Kreisler |Austin.kreisler@itb. |( |( |( |( |( |( |( |( |( |
|Patti Larson |Plarson@ |( | |( | | | | | | |
|K.P. Lee |Kp.lee@ | | | |( | | | | | |
|Andrei Leontiev |Andrei_leontiev@ | | | |( | | | | | |
|Tom Marley |t.marley@salford.ac.uk | | |( | | | |( |( | |
|Ken McCaslin |Kenneth.h.mccaslin@ |( | | | |( |( |( | | |
|Lloyd McKenzie |Lmckenzie@la. |( |( | | | | |( |( |( |
|Gary Meyer |Gary.meyer@ | | | |( |( | |( | | |
|Claudette Murch |Claudette.murch@med. |( | |( | | | | | | |
|Suzanne Nagami |Suzanne.e.nagami@ |( | |( | | | | |( | |
|Manish Narang |Mnarang@ocdus. |( | | | | |( | | | |
|Dale Nelson |Dale.nelson@ | | | |( | | | | | |
|Karen Nocera |Kyn@ | | | | | | |( | | |
|Herman Oosterwijk |Herman@ | | | |( | | | | | |
|Alan Rector |Rector@man.ac.uk | | | | | | | |( | |
|Scott Robertson |Scott.m.robertson@ |( |( | |( |( | |( |( | |
|Gunther Schadow |Schadow@regenstrief.iupui.edu | | | | |( |( |( | |( |
|Karen Sieber |Ksieber@ |( | |( | |( |( |( |( |( |
|David Snavely |Dav_snavely@ | | | | | | | | | |
|Allan Soerensen |Allan.soerensen@radiometer.dk |( | | | | |( | | | |
|Harry Solomon |Harry.solomon@med. | | | |( | | | | | |
|Helen Stevens |Helen.stevens@ |( |( | | | | | | |( |
|Sadamu Takasaka |S-takasaka@cp.jp. |( | | | | |( | | | |
|Timo Tarhonen |Timo.tarhonen@tto.fi | | | | | | | | |( |
|Wayne Tracy |Wrtracy@wrt. |( | | | | | | |( | |
|Mark Tucker |Mtucker@ | | |( | | | | | | |
|Bob Uleski |Bobul@ |( | | | | | | | | |
|Jason Williams |Jwilliams@fast- | | | |( | | | | | |
|Daphne Young |Daphne.young@itb. |( |( |( |( |( | |( |( |( |
|Mei Zhang |Zhangm@ | | | | | | | | |( |
|Xiaohan zhou |Xiaohan.zhou@ | | | | | | | | |( |
Communication with declared O&O participants can be done through ord@lists.. You can sign up on this list through HL7’s home page .
Monday, May 7, 2001
Version 2.x - Blood Bank Messages
We met with the Blood Bank SIG to review progress made on the proposals for new blood bank messages. See notes in Attachment A, V2.x Proposals under 118.
Version 2.x – Joint with LAPOCT
We reviewed with the LAPOCT SIG the proposed authoritative statement to enable NCCLS/CIC to further their work in the use of HL7 messages prior to V2.x being balloted. See notes in Attachment A, V2.x Proposals under 123 for the details on the proposal and discussion.
V2.x – Timing/Quantity/Repeat Pattern
We reviewed the progress made around the TQ and Repeat Pattern proposals. See notes in Attachment A, V2.x Proposals under XXX for the details on the proposal and discussion.
Version 2.x – Other Proposals
We spent the remainder of Monday on reviewing/finalizing various and sundry V2.x proposals that had been reviewed/prepared during the weekly V2.x conference calls. See attachment A for a summary of the disposition of these V2.x proposals for the details on the proposals and discussion.
Tuesday, May 08, 2001
V3
On Tuesday we started the review of the work done since Indianapolis and identify what needs to be done by July in preparation for the first V3 ballot.
By July 1 we need:
❑ Domains We are focusing on Lab (including micro/specimen) and Pharmacy message
❑ Application Roles Need to define which subset we’ll focus on for the first ballot.
❑ Storyboards Need a prepare storyboards for the scenarios supported in the first ballot.
❑ Trigger Events Need to define which subset we’ll focus on for the first ballot.
❑ RMIMs Need to finalize the RMIMs that support the interactions
❑ HMD’s Need to derive the HMDs
❑ Message Types Need to define the message types we need to support.
❑ Interactions Need to define the interactions we’ll focus on for the first ballot.
It is estimated that we have appr. 50% done at the start of this meeting. The purpose of this meeting is to make as much as possible progress to completing the remaining 50%
❑ Domains
We agreed to initially focus on Lab (plus Micro/specimen) and Pharmacy. Others, such as Blood Bank, LAPOCT, Dietary will follow.
❑ Application Roles
Application roles must be very specific. They are still based on placer/filler concepts. There are suggestors, requestors, and notifiers. Need to differentiate between loosely-coupled systems and closely-coupled systems.
1. For Lab Orders there are the following roles:
❑ Suggestors, Requestors, Notifiers (3)
❑ Closely-coupled, loosely-coupled (2)
❑ New, revise new, activate, revise active, supercede active, complete, supercede complete, undo complete (9) (New and revise new operate in the authoring space)
❑ Initiator, Acceptor/Tracker (2) (this is where the placer/filler concepts ended up)
An application can sign up for either combination of these roles (81). We do not need to cover all for the first ballot, but need to cover them at some point. We agreed to focus on valid combinations of those highlighted in yellow, significantly reducing the roles to be considered for the first ballot.
2. For Lab Intents there are the following roles:
❑ Suggestors, Requestors, Notifiers (3)
❑ Closely-coupled, loosely-coupled (2)
❑ New, revise new, activate, revise active, supercede active, complete, supercede complete, undo complete (9)
❑ Initiator, Acceptor/Tracker (2)
An application can sign up for either combination of these roles (81). We do not need to cover all for the first ballot, but need to cover them at some point. We agreed to focus on valid combinations of those highlighted in yellow, significantly reducing the roles to be considered for the first ballot.
3. For Lab Event there are the following roles:
❑ Requestors?, Notifiers (2?) Still some debate on requestor. Need further input from LAPOCT to determine whether requestor is needed, and if so, how.
❑ Closely-coupled, loosely-coupled (2)
❑ New, revise new, activate, preliminary, revise active, supercede active, complete, supercede complete, undo complete (9)
❑ Initiator, Acceptor/Tracker (2)
An application can sign up for either combination of these roles (54). We do not need to cover all for the first ballot, but need to cover them at some point. We agreed to focus on valid combinations of those highlighted in yellow, significantly reducing the roles to be considered for the first ballot.
Lloyd McKenzie is putting similar list together for Pharmacy.
We agreed to focus on the yellow highlighted roles first, with an initial focus on Lab Order, then Lab Event, then, if time permits, Lab Intent.
❑ Trigger Events
Trigger Events are generally tied to the state transitions we want to communicate. Includes suggest, notification (including accept), request, and reject. They are divided in loosely and closely coupled.
1. Lab Order
❑ New, revise new, activate, revise active, supercede active, complete, supercede completed, undo completed (9)
❑ Suggest, request, notify, reject (4)
❑ Loosely-coupled, closely-coupled (2)
This gives about 54 trigger events.
2. Lab Intent
❑ New, revise new, activate, revise active, supercede active, complete, supercede completed, undo completed (9)
❑ Suggest, request, notify, reject (4)
❑ Loosely-coupled, closely-coupled (2)
This gives about 54 trigger events.
3. Lab Event
❑ New, revise new, activate, preliminary, revise active, supercede active, complete, supercede completed, undo completed (10)
❑ Request, notify, reject (4)
❑ Loosely-coupled, closely-coupled (3)
This gives about 81 trigger events.
We agreed to only focus on the valid combinations of the trigger events highlighted in yellow.
In Indianapolis there was agreement that a revise active only applies to changing an end-date. All other changes are considered supercede active. Implication is that order identification changes. This must be clearly document to allow for careful review as the discussion around what constitutes a requirement for a new order vs. changes to an existing order are impacted. In Minneapolis we agreed to review this with the Medication Information SIG. See the Thursday section for outcome of this discussion.
❑ RMIMs
We have RMIMs for Lab Order, Lab Intent, Lab Event as well as Pharmacy Orders (being finalized by the Medication Information SIG).
❑ HMDs
HMDs are generated by the Rose Tree Tool. Lloyd is working on a Visio to Rose Tree conversion tool.
❑ Message Types
Far fewer then trigger types. Content driven mostly will be loosely vs. closely-coupled systems.
❑ Interactions
Links work products together: Initiating Trigger Event, Sending Application Role, Receiving Application Role, Receiver Responsibility, Message Type, Story Board.
Directly related to the number of trigger events.
Common Orders deal with messages such as cancel, hold, etc. that are common across domains. We will address those that are part of the highlighted selections.
We need story boards ASAP, and as a result solicited the following scenarios with corresponding volunteers:
❑ Lab Order – First Example – Ken McCaslin, Edgar Gluck
Initiate a Request to Activate an Order in a Closely Coupled environment. Accept a Request to Activate an Order in a Closely Coupled environment. Initiate the Notification to Activate an Event (Observation) in a Closely Coupled environment.
❑ Lab Order – Second Example – Suzanne Nagami/Tina Buckeye
Initiate a Request to Activate an Order in a Loosely Coupled environment. Accept a Request to Activate an Order in a Loosely Coupled environment. Initiate the Notification to Activate an Event (Observation) in a Closely Coupled environment.
❑ Lab Order – Dan Jernigan
Initiate the Notification of Completed Events (Observations) in a Loosely/Closely Coupled environment.
❑ Lab Event – Karen Sieber
Initiate the Notification to Revise a Completed Event (Result) in a Loosely/Closely Coupled environment.
❑ Lab Order – Craig Robinson
Initiate the Request to Activate an Order for Micro in a Closely Coupled environment. The Lab Initiates a Request to Activate an Order for a Micro at a Reference Lab in a Loosely Coupled environment. The Reference Lab Initiates a Notification of a Completed Observation to the Lab in a Loosely Coupled environment. The Lab Initiates a Notification of a Completed Observation in a Closely Coupled environment.
Joint SD/II/OO
Bob Dolan introduced the following notions (see Attachment B for the document used):
❑ Entries should be an act (clones) or HMDs.
❑ Document Header and Document Construct are Act Context.
❑ Some questions about use of separate Event for the fulfillment and the document containing the “result”.
❑ What determines whether to use the Act structure vs. Act Context?
❑ Act Context is a wrapper for Acts.
❑ Cannot turn paragraph, list, etc. into data types.
❑ Motion: Create a vocabulary domain “ContextLevel” using the values shown above, to be used for the Act_context.level_cd attribute. Ammend – remove level_cd and use this vocab domain for class_cd of the subtypes of Act_context.
Discussion: Need further analysis of document vs. message and use cases for each one. Should act_relationship move to act_context or vice versa.
The motion with amendment was accepted (OO, II, SD joint meeting) 15 approve, 0 against, 11 abstain
Joint Vocab
The objective of joint session was to identify where we have missing vocabulary necessary for the first ballot.
Observation Order
❑ Mood Code – We will ask Carmela Couder to re-send a document to contains suggestions for improving the definitions.
❑ Code – External code sets.
❑ Method code – Needed. Ken McCaslin will follow-up.
❑ Status code – Can be obtained from State Transition Diagrams.
❑ Confidentiality Code – Need review. Hans Buitendijk will follow-up.
❑ Priority Code – Defined in USAM. Carmela Couderc will follow-up.
AR_component
❑ Defined in USAM, not necessarily added to Vocabulary. Ed Hammond will follow-up with Gunther Schadow.
P_responsible_parties
❑ Mode_cd – Needs definition. Ed Hammond will follow-up.
Cntrl_msg_interaction
❑ Language_cd – Ed Hammond will follow-up.
AR_override
❑ Type_cd – Austin Kreisler will check with Lloyd McKenzie.
P_entering_location
❑ Type_cd – Austin Kreisler will check with Lloyd McKenzie
AR_targets
❑ Type_cd – Austin Kreisler will check with Lloyd McKenzie.
Observation Event
❑ Interpretation_cd – Gunther Schadow will check with USAM
❑ Target_site_cd – Ed Hammond will check with Vocab.
Austin Kreisler/Jim Case need to follow-up whether handling code should be in Transport_CMET.
When vocabulary for these items are available, please send to Stan Huff plus copy to ord@lists. by July 1, 2001. USAM may contain them. Please contact Hans Buitendijk if you need the appropriate spreadsheets.
We did not discuss Pharmacy and Specimen.
Lab RMIMs
We proceeded to review the Lab Order RMIM. Attachment C contains the RMIMs that we arrived at upon the conclusion of this week.
❑ Need more information for loosely coupled systems in the areas of Observation_Order_Master and Obs_Intent_of_Event, Location_CMET, Used_Device_CMET, Implicated_Act
❑ We agreed that if systems are loosely coupled in one area, they are loosely coupled for the entire message. This may be challenged over time, but will be kept in place for the first ballot.
❑ Observation_Order_Master with Requestor, Activate, Initiator
When closely coupled, we don’t need this class.
When loosely coupled, we need:
1. Class_cd
2. Mood_cd
3. Cd
4. Id
5. Txt
6. Method_cd
7. Effective_time (definition in the RIM is not geared towards definitions)
8. Confidentiality_cd
9. Max_repeat_nmr
10. Priority_cd
11. Interruptable_ind
12. Target_site_cd
13. Act_relationship to enable components of the definition. May need the same list as AR_component.
❑ Need follow-up with Bob Dolin and Sandy to review definitions to reflect all moods.
Wednesday, May 09, 2001
V3
We continued with the RMIM review.
❑ Obs_Intent_or_Event not needed with Requestor, Activate, Loosely/Closely, Initiator
❑ Location_CMET
1. Unclear what RL_Location proposed value of PRSN is
2. Closely – codes, hierarchy only
3. Loosely – codes, hierarchy, code description, address at the top of the pyramid.
❑ Device_CMET
1. Questions on Device_CMET proposed structure
2. Version 2 did not have much and not a lot of request for additional capabilities.
3. Closely – need ID
4. Loosely – need ID, desc, telecom, scoping orgz name/telecom/address
❑ Implicated_Act
1. We agreed to drop Implicated_Act and Ar_Related_Info. Sense is that creating a CMET that can handle the concept and support clinical info or two CMETs (or one with a choice) is most desirable to pursue.
We arrived at the following matrix of interactions that we must match to the appropriate RMIMs. (Those listed with strikethrough are not valid and will not be pursued at all.)
|Initiate |Request |Activate |ORD |Closely |RMIM |
|- |- | |INT |- Loosely | |
|Accept/Track |Notification | |EVT | | |
|Initiate |Request |Activate |Order |Closely |Page 164 |
| | | | | |Order – close |
|Initiate |Request |Activate |Order |Loosely |Page 165 |
| | | | | |Order – loose |
|Accept |Request |Activate |Order |Closely |Page 170 |
| | | | | |Intent – close |
|Accept |Request |Activate |Order |Loosely |Page 167 |
| | | | | |Intent – loose |
|Initiate |Notification |Activate |Order |Closely |Page 164 |
| | | | | |Order – close |
|Initiate |Notification |Activate |Order |Loosely |Page 165 |
| | | | | |Order – loose |
|Initiate |Request |Complete |Order |Closely/Loosely | |
|Initiate |Notification |Complete |Order |Closely |Page 170 |
| | | | | |Status – close |
|Initiate |Notification |Complete |Order |Loosely |Future |
Joint LAPOCT/OO – Specimen CMET
Objective was to resolve the specimen CMET construct to ensure it addresses LAPOCT needs and works for the first ballot.
❑ Not sure how to deal with R_CarrierAtLocation and R_CarrierInTray. Woody Beeler, Lloyd McKenzie, Andrzej Knafel, Austin Kreisler, and Gunther Schadow will follow-up.
❑ Challenging situation with R_ParentChildLocation.
❑ R_Specimen.class_cd should encompass Aliquot, Supernatant, Sediment, Extract, Precipitate, Destillate. Aliquot is used when the substance did not change. Jim Case will follow-up with Vocab.
❑ Further discussion challenged the appropriateness of this decision. A renewed vote showed that Aliquot through destillate in R_specimen.class_cd: 3 in Favor, 10 abstain; and in R_specimen.cd: 4 in Favor, 1 against, 9 abstain. Manish/Gunther will follow-up with Woody to arrive at the best location. Woody felt the cd was the better place, so that’s what we are going for.
❑ Specimen.cd should encompass whole blood (separated vs. whole), plasma (plateled rich, plateled poor), serum. Do we need to expand using the specimen source group.
❑ Combined Carrier and Tray into Carrier_Tray. Need a better name.
❑ Put Carrier_Tray in a Choice with Container.
Thursday, May 10, 2001
Common Order/Intent/Event State Change Messages
The following permutations were discussed related to general order state change messages. We agreed that if somebody is interested in creating a set of messages for general clinical observations as part of ballot 1, then they should be responsible for the work.
|Initiate |Request |Activate |ORD |Closely |RMIM |
|- |- |Suspend |INT |- Loosely | |
|Accept/Track |Notification |Resume |EVT | | |
| | |Abort | | | |
| | |Undo | | | |
|Initiate |Request |Suspend |Order |Closely/Loosely |Page 170/171 |
| | |Resume |Intent | |Status – close |
| | |Abort |Event | |Status – loose |
|Initiate |Notification |Suspend |Order |Closely/Loosely |Page 170/171 |
| | |Resume |Intent | |Status – close |
| | |Abort |Event | |Status – loose |
|Accept |Request |Suspend |Order |Closely/Loosely |Page 172 |
| | |Resume |Intent | |Accept/Reject – close |
| | |Abort |Event | |Accept/Reject – loose |
|Reject |Request |Suspend |Order |Closely/Loosely |Page 172 |
| | |Resume |Intent | |Accept/Reject – close |
| | |Abort |Event | |Accept/Reject – loose |
|Accept/Reject |Notification |Suspend |Order |Closely/Loosely | |
| | |Resume |Intent | | |
| | |Abort |Event | | |
|Accept/Reject |Request |Activate |Intent |Closely/Loosely | |
| | | |Event | | |
|Reject |Request |Activate |Order |Closely/Loosely |Page 172 |
| | | | | |Accept/Reject – close |
| | | | | |Accept/Reject – loose |
|Accept/Reject |Notification |Activate |Order |Closely/Loosely | |
| | | |Intent | | |
| | | |Event | | |
|Accept |Request |Revise Active |Order |Closely |Page 167 |
| | | | | |Intent – close |
|Accept |Request |Revise Active |Order |Loosely |Page 167 |
| | | | | |Intent – loose |
|Accept |Request |Supercede Active |Order |Closely |Page 166 |
| | | | | |Intent – close |
|Accept |Request |Supercede Active |Order |Loosely |Page 167 |
| | | | | |Intent – loose |
|Accept |Request |Supercede Complete |Order |Closely |Page 166 |
| | | | | |Intent – close |
|Accept |Request |Supercede Complete |Order |Loosely |Page 167 |
| | | | | |Intent – loose |
|Initiate |Notification |Supercede Active |Intent |Closely |Page 166 |
| | | | | |Intent – close |
|Initiate |Notification |Supercede Active |Intent |Loosely |Page 167 |
| | | | | |Intent – loose |
|Initiate |Notification |Supercede Complete |Intent |Closely |Page 166 |
| | | | | |Intent – close |
|Initiate |Notification |Supercede Complete |Intent |Loosely |Page 167 |
| | | | | |Intent – loose |
|Initiate |Notification |Revise Active |Intent |Closely |Page 166 |
| | | | | |Intent – close |
|Initiate |Notification |Revise Active |Intent |Loosely |Page 167 |
| | | | | |Intent – loose |
|Initiate |Notification |Complete |Intent |Closely |Page 170 |
| | | | | |Status – close |
|Initiate |Notification |Complete |Intent |Loosely |Page 171 |
| | | | | |Status - loose |
❑ The first two lines use the same RMIMs: one for closely and one for loosely coupled.
❑ We agreed that confidentiality_cd is not necessary in the state change messages when closely coupled.
❑ We agreed that the control_msg_interaction pattern is the same for all messages, only changes between loosely and closely coupled systems.
❑ We agreed that the sts_cd is not necessary since the message definition already conveys what is being requested/notified.
❑ We agreed that even with loosely coupled systems the receiving system of a state change message received the original activate message. If they didn’t, then it will not be meaningful anyway, but will contain enough information to follow-up.
❑ We agreed we cannot do an undo to an order.
❑ We agreed that the RMIM for Accept/Reject where there is no “revision” data is all the same for ORD/INT.
❑ We agreed that we only need one RMIM that covers state change messages for ORD, INT, EVT.
Joint Rx
❑ We discussed the potential scope of revisions. We agreed that, if you need to change the ID, then it’s a supercede active. 10 in Favor, 0 Against, 2 Abstain. All other changes are considered a revise, unless both parties locally agree that does not work.
❑ We discussed a sequence of interactions as follows that can take place when revising or superceding an order/intent.
Placer to Filler Initiate Request to Activate Order
Filler responds Accept Request to Activate Order
Placer to Filler Initiate Request to Revise Active Order
Filler may respond a) Accept Request to Revise Active Order
Or b) Reject Request to Revise Active Order
Or c) Initiate Notification to Supercede Active Intent
Or d) Initiate Request to Supercede Active Order
Placer may respond Accept/Reject Request to Supercede Active Order
We agreed that these are valid sequences. 12 in Favor, 0 Against, 1 abstain.
❑ We agreed to add confidentiality_cd to control msg… : 8 in Favor, 1 Against, 3 Abstain.
❑ We agreed to contact Secure SIG to follow-up on where to put confidentiality code and how to incorporate other security considerations. Example issue area is initiate request suspend/resume state changes. Should we send a confidentiality in those messages as well.
❑ Is annotator a separate type or should it be a related act with author? We agreed to a related act with author. 10 in Favor, 0 Against, 3 Abstain.
❑ Role may be used for Performer and Call Back Contact.
❑ We need to synchronizing CMETs with Marvin.
❑ Lloyd will check with M&M that Identifiable Patient CMET requires the patient’s location and that Detailed Patient CMET requires the patient’s and person’s location. What is the best way to express this?
❑ Do we need loosely/closely coupled encounter_ref CMET? Open Issue.
❑ We agreed that the Lab RMIM should mimic Rx RMIM for clinical support info: 11 in Favor, 0 Against, 3 Abstain.
Friday, May 11, 2001
Publication Update
Helen provided a brief overview of publication coding system.
Image Integration
❑ IIS will go into V2.x conference call cycle. See #23 in the V2.x proposal review for further detail and discussion.
❑ Ron Parker is new facilitator of II for MnM.
❑ Patient orientation is not data that need to be kept outside the image, not in the RIM. Don’t know whether there is need for another attribute.
❑ Reviewing one of the use cases, e.g., Claims Attachment.
❑ Primary question being addressed now is how are we handling encapsulated DICOM data.
❑ Focus is what data needs to be known to the encapsulated, what needs to be externalized.
❑ Need to have joint with Structured Documents. Close to mapping structured reports into RIM.
❑ Fred confirms that objective is to enable rendering of DICOM reporting message correctly and completely in HL7 V3 format where only the image itself is DICOM. This would virtually eliminate redundancy between encapsulated image and the rest of the message, e.g., patient demographic, non-image results, orders, etc.
❑ Use case where DICOM report will incorporate lab tests for automated documentation.
V2.x
❑ Proposals in progress in Medication Information after July.
❑ Expected Refill Date
❑ We agreed that any V2.x proposals that come in after this meeting will be on a futures list. If there is time, they may be addressed prior to the next V2.x ballot, but no guarantee.
❑ All V2.x must tie to V3 RIM and preferably use the same methodology. The individual board members will vote negatively when this is not the case.
Attachment A: V2.x Proposals
The following are the proposals that were reviewed during interim conference calls that were ready for committee vote for inclusion into the next V2.x ballot. These were discussed on Monday and Friday.
14 - Establish an Inventory Master message
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.5.1.1
Priority: 20
Description:
Justification: 4/4/01 – introduction and discussion. Group generally accepts but needs more time to review. Action Item: Daphne has some potentially related master file messages that she will forward to Scott.
Time slot 20 Minute discussion in Minneapolis
Minneapolis Discussion
Against: 0, Abstain: 1, In Favor: 12
Proposal Language
Add entry to HL7 Table 0175 – Master file identifier code
8.5.1.1 MFI-1 Master file identifier (CE) 00658
Components: ^ ^ ^ ^ ^
Definition: This field is a CE data type that identifies a standard HL7 master file. This table may be extended by local agreement during implementation to cover site-specific master files (z-master files). HL7 recommends use of the HL7 assigned table number as the master file identifier code if one is not specified in Table 0175. For example, a master file of Marital Status codes would be identified by HL70002 as the Master File Identifier in MFI-1. Refer to HL7 table 0175 - Master file identifier code for valid values.
HL7 Table 0175 - Master file identifier code
|Value |Description |
|CDM |Charge description master file |
|CMA |Clinical study with phases and scheduled master file |
|CMB |Clinical study without phases but with scheduled master file |
|LOC |Location master file |
|OMA |Numerical observation master file |
|OMB |Categorical observation master file |
|OMC |Observation batteries master file |
|OMD |Calculated observations master file |
|PRA |Practitioner master file |
|STF |Staff master file |
|CLN |Clinic master file |
|OME | Other basic observation/service attributes |
|INV |Inventory master file |
Add section and message as follows
Inventory ITEM MASTER FILES
Inventory item master file message (MFN/MFK)
This section is concerned with describing a master file message that should be used to communicate information that relates to the inventory of items that can be used to perform an ordered service. While an order specifies a service that is represented in a Service Item Master, this message is concerned with communicating attributes of those items (for example lot number and expiration date) that are represented in the Service Item Master. These attributes are more granular than can be represented in the Service Item Master as there may be multiple items in inventory that meet the characteristics of the Service Item but have different specific characteristics, e.g., multiple lots of a vaccine.
Each MFE/IIM structure describes a specific set of for a Service Item. Multiple instances of MFE/IIM could be used to describe the same Service Item lot at multiple locations, or a location with multiple lots of the same Service Item.
|MFN^Mnn^MFN_Mnn |Master File Notification for Inventory Item |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| IIM} |Inventory Item Master |8 |
|MFK^Mnn^MFK_M01 |Master File Acknowledgment for Inventory Item |Chapter |
|MSH |Message Header |2 |
|MSA |Acknowledgment |2 |
|[ERR] |Error |2 |
|MFI |Master File Identification |8 |
| { [MFA] } |Master File Ack |8 |
IIM - Inventory item master segment-
The Inventory Item Master segment (IIIM) contains information about the stock of product that can be used to fulfill an ordered test/service. All of the fields in this segment describe the test/service and other basic attributes pertaining to the master service item.
HL7 Attribute Table - IIM – Inventory Item Master
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |250 |CE |R |N | |????? |Primary Key Value – IIM |
|2 |250 |CE |R |N | |????? |Service Item Code |
|3 |250 |ST |O |N | |????? |Inventory Lot Number |
|4 |26 |TS |O |N | |????? |Inventory Expiration Date |
|5 |250 |CWE |O |N | |????? |Inventory Manufacturer Name |
|6 |250 |CWE |O |N | |????? |Inventory Location |
|7 |26 |TS |O |N | |????? |Inventory Received Date |
|8 |12 |NM |O |N | |????? |Inventory Received Quantity |
|9 |250 |CE |O |N | |????? |Inventory Received Quantity Unit |
|10 |12 |MO |O |N | |????? |Inventory Received Item Cost |
|11 |26 |TS |O |N | |????? |Inventory Date |
|12 |12 |NM |O |N | |????? |Inventory On Hand Quantity |
| |250 |CE |O |N | |????? |Inventory On Hand Quantity Unit |
IIM field definitions
IIM-1 Primary key value (CE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field contains the code assigned by the institution for the purpose of uniquely identifying an inventoried item. The key field of the entry. Must match MFE-4 - Primary key value-MFE.
Proposal Comment: This field is included to emulate the format of other master file segments. By including the primary key in the IIM segment in addition to the MFE segment allows for this segment to be used in other message constructs. We are not proposing the inclusion of IIM in other messages at this time, this is in anticipation of potential future need.
IIM-2 Service item code (CE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field contains the identifier of the service item. It relates the inventory item of this message to an entry in the Service Master.
IIM-3 Inventory lot number (ST) ?????
Definition: This field contains the lot number of the service item in inventory.
Note: The lot number is the number printed on the label attached to the item or container holding the substance. If the substance is a vaccine, for example, and a diluent is required, a lot number may appear on the vial containing the diluent; however, any such identifier associated with a diluent is not the identifier of interest. The substance lot number should be reported, not that of the diluent.
IIM-4 Inventory expiration date (TS) ?????
Definition: This field contains the expiration date of the service item in inventory.
Note: Expiration date does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.
IIM-5 Inventory manufacturer name (CWE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field contains the manufacturer of the service item in inventory.
IIM-6 Inventory Location (CWE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field contains the location of the inventory. As an inplementation consideration, this location can have a range of specificity. The location can be very general, e.g., a facility where the inventory is warehoused, or very specific, e.g., a shelf location.
IIM-7 Inventory Received Date (TS) ?????
Definition: This field contains the most recent date that the product in question was received into inventory.
IIM-8 Inventory Received Quantity (NM) ?????
Definition: This field contains the quantity of this inventory item that was received on the date specified in IIM-5 Received Date
IIM-9 Inventory Received Quantity Unit (CE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field specifies the unit for IIM-7 Inventory Received Quantity.
Proposal Comment: An alternative approach for IIM-8 Inventory Received Quantity and IIM-9 Inventory Received Quantity Unit would be a single attribute, IIM-n Inventory Received Amount, with a datatype of CQ.
IIM-10 Inventory Received Item Cost (MO) ?????
Components: ^
Definition: This field contains the per-unit cost of the inventory item at the time of receipt.
IIM-11 Inventory Date (TS) ?????
Definition: This field specifies the most recent date that an inventory count for the inventory item was performed.
IIM-12 Inventory On Hand Quantity (NM) ?????
Definition: This field contains the quantity of this inventory item that was available for issue/use as of the date specified in IIM-10 Inventory Date. No adjustment has been made for subsequent use.
IIM-13 Inventory On Hand Quantity Unit (CE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field specifies the unit for IIM-11 Inventory On Hand Quantity.
Proposal Comment: An alternative approach for IIM-12 Inventory On Hand Quantity and IIM-13 Inventory On Hand Quantity Unit would be a single attribute, IIM-n Inventory On Hand Amount, with a datatype of CQ.
16 - Define a Reference Range (RFR) data type
Submitted By: Joann Larson – Kaiser Permanente
Section: 2.9
Priority: 20
Description:
Justification: CQ asks OO to consider new segment instead. OO: CQ is not favorable to this proposal. This is a quick method to resolve these CM, CQ wants a more global fix, possibly a new segment. Discussion follows, case for new segment not strong. TABLED for further investigation, case for new segment, bridging issues to version 3. CQ: not heard. 1/3/00 – reviewed and endorsed as written as part of CM re-definition project. May be candidate for separate segment, as separate issue. 3/30 - CQ endorsed as a data type. 4/18 - Review in OO to acknowledge CQ actions. Need new proposal to apply data type to specific attributes
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
2.9 Data Types
2.9.N Reference range (RFR)
Components: ^ ^ ^ ^ ^ ^
Definition: Specifies the range of data being referenced and any constraining conditions applying to the value.
2.9.N.1 Numeric range (NR)
Definition: Specifies the interval between the lowest and the highest values in a series of data.
2.9.N.2 Administrative sex (IS)
Definition: Specifies which gender for which the reference range is valid.
2.9.N.3 Age range (NR)
Definition: Specifies the age range for which the reference range is valid.
2.9.N.4 Gestational age range (NR)
Definition: Specifies the gestational age range for which the reference range is valid.
2.9.N.5 Species (TX)
Definition: Specifies the species for which the reference range is valid.
2.9.N.6 Race/subspecies (ST)
Definition: Specifies the race or subspecies for which the reference range is valid.
2.9.N.7 Conditions (TX)
Definition: Specifies any arbitrary condition for which the reference range is valid. This may include such conditions as phase of menstrual cycle or dose of a particular drug.
17 - Define a Delta (DLT) data type
Submitted By: Joann Larson – Kaiser Permanente
Section: 2.9
Priority: 28
Description: The OM2-numeric observation segment defined in chapter 8, section 8.8.4, has a number of fields with an undefined data type. This was uncovered by Frank Oemig during the version 2.4 membership ballotting process. A temporary solution that retained the CM data type but assigned data types to the components was agreed upon with the understanding that this situation could be corrected with a new data type in the next release. A Delta (DLT) data type having the following components would meet requirements for 1 of these fields.
Justification: CQ asks OO to consider new segment instead. OO: CQ has same issue as RFR. Backward compatibility issue with NR as first component (different delimiters). TABLED for further consideration. CQ: not heard. 1/3/00 – reviewed and endorsed as written as part of CM re-definition project. Separate segment issues is a separate consideration. 3/30 - CQ endorsed as data type. 4/18 - Review in OO to acknowledge CQ actions. Need new proposal to apply data type to specific attributes.
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
2.9 Data Types
2.9.N Delta (DLT)
components < Normal Range (NR)> ^ < numeric threshold (NM)> ^ < change computation (ST)> ^ < length of time-days (NM)>
2.9.N.1 Normal Range (NR)
Definition: Specifies the normal interval of the reference data
2.9.N.2 Numeric threshold (NM)
Definition: The numeric threshold of the change that is detected.
For example the threshold may be set to 10.
2.9.N.3 Change computation (ST)
Definition: Specifies if the change is computed as a percent change or as an absolute change. Valid values are:
|% |Percent change |
|a |Absolute change |
2.9.N.4 Length of time-days (NM)
Definition: The length of time that the value is retained for computing delta checks.
21 - Specimen Source Data Type
Submitted By: Austin Kreisler – McKessonHBOC ITB
Section: 8
Priority: 31
Description: The CM data types defined for ORC-15 and SAC-6 (along with all CM's) cannot be handled by the XML ITS for versioin 2.x. This proposal is to create a new data type, the SPS, which can be handled by the XML ITS
Justification: CQ asks OO to consider new segment instead. OO: Same CQ issue. Correction to specimen collection method. Voted to support pending further specimen source work. Vote 15/0/0 (Favor/Against/Abstain). CQ Issue: additive type may need to remain TX if used as repeatable, CWE would require precoordination. Voted on with question on TX vs CWE. Additional issue: micro questions body site relative to micro with multiple sites within a sample specimen. (site modifier as repeating). Vote 11/0/1 (Favor/Against/Abstain). 1/31/01 – initial definition of CM, use of repetitions is noted, thus need for TX. Upgrading of CE to CWE may remain an issue. Forward results to Specimen Source group for further consideration. 3/30 - CQ endorsed as data type. 4/18 - Review in OO to acknowledge CQ actions. Need new proposal to apply data type to specific attributes.
Minneapolis Discussion
This is an addition to the ongoing specimen source discussion.
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
2.8.?? SPS – specimen source
Components: ^ ^ ^ ^ ^ ^
This data type identifies the site where the specimen should be obtained or where the service should be performed.
Specimen source name or code (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
The first component contains the specimen source name or code (as a CWE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) Refer to HL7 Table 0070 - Specimen source codes for valid entries.
Additive (TX vs CWE)
This component identifies an additive introduced to the specimen before or at the time of collection. Refer to HL7 Table 0371 – Additive for valid values. The table’s values are taken from NCCLS AUTO4. The value set can be extended with user specific values.
Specimen collection method (TX)
Free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment (i.e., OBX segment).
Body site (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component specifies the body site from which the specimen was obtained. A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
HL7 Table 0163 - Body site
SNOMED etc.
Site modifier (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component modifies body site. For example, the site could be antecubital fossa, and the site modifier “right.” Refer to HL7 table nnnn Body Site Modifier for allowed values.
Collection method modifier code (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
The sixth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.
Specimen role (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component indicates the role of the sample. Refer to User-defined Table 0369 – Specimen role for suggested values. Each of these values is normally identifiable by the systems and its components and can influence processing and data management related to the specimen.
23 - Create a new segment - IIS - "Imaging Information Segment"
Submitted By: Al Figler – Figler Consulting
Section: 4.5
Priority: 11
Description: Current Orders Segments are missing information needed to order/report radiology images.
Justification: 1/31/01 – noted that this was to be fast tracked. 2/7/01 – check with author/Hans/Helen (1) fast track (2) discussion in this group. 2/21/01 – introduced. Discussion of IIS-1 similarity to lab accession concept. Action Item: [A Figler] distribute updated proposal. Action Item: [A Figler] collect/distribute use cases illustrating radiology accession concept. 3/7/01 – updated proposal reviewed. Data type changes suggested for IIS-1 thru IIS-4. Consideration of new message/trigger. Action Item: Al will revise and confer with imaging/DICOM group. 4/4/01 – Al reports that the imaging group is reviewing a revised proposal.
Time slot 30 Minute discussion in Minneapolis
Minneapolis Discussion
Motion to support direction of SIG and request SIG prepare final proposal for vote in September 2001 for inclusion in V2.5.
Against: 0, Abstain: 0, In Favor: 10
Proposal Language
Imaging Order Message & Imaging Information Segment (IIS) Definition
Chapter 4 New Order Message and Trigger.
|OMI^O##^OMI_O## |General Clinical Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit- Additional Info |3 |
| ] | | |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| OBR |Observation |4 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [CTD] |Contact Data |11 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| {IIS} |Imaging Information Segment |4 |
|} | | |
| | | |
| | | |
OMI Message Definition:
This message is used in communication between the information systems involved in the fulfillment of the request, such as Radiology Information System (RIS) and Picture Archiving and Communication System (PACS). For the purpose of the following discussion these systems will be identified as Imaging Department Information Systems (IDIS). Information contained in the IIS segment allows multiple IDIS to share the context of Imaging Studies (collections of images acquired, processed, stored, and interpreted) in Image Management tasks.
The order for the imaging service is communicated between the Order Placer and the Order Filler. The Order Filler may break the order down into one or more internal imaging service requests, each identified by a different accession number. In the imaging department environment, the Order Filler also identifies the set of procedures (studies) and sub-procedures (procedure steps) that have to be performed in the process fulfilling the order. Each sub-procedure is performed using a single device (station). The Order Filler identifies the type of device and either a specific device or group of devices (for example, by geographic location) one of which is to be used in performing the procedure step. Thus, the system performs an aspect of workflow management in the department.
Another information system in the department may be managing storage and distribution of the images within the department as well as providing them to the enterprise. This system will have to share context with the system managing the workflow. This includes identifiers, content of the order, and details of procedures and procedure steps that have to be performed to fulfill that particular order.
It is expected that the OMI message will typically be used in communication between IDIS as depicted in the figure below.
[pic]
IIS Segment Definition:
The IIS segment contains information about tasks that need to be performed in order to fulfill the request for imaging service. The information includes location, type and instance identification of equipment (acquisition modality) and stages (procedure steps).
Note: many of the references, field names and definitions are in sync with dicom (or something like that!)
HL7 Attribute Table – IIS – Imaging Information Segment
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |22 |EI |R | | | |Accession Number |
|2 |22 |EI |R | | | |Requested Procedure ID |
|3 |64 |EI |R | | | |Study Instance UID |
|4 |22 |EI |R | | | |Scheduled Procedure Step ID |
|5 |16 |CE |O | | | |Modality |
|6 |261 |CE |O |Y | | |Protocol Code |
|7 |261 |CE |O | |??? | |Scheduled Station Name |
|8 |261 |IS |O |Y |??? | |Scheduled Procedure Step Location |
|9 |261 |IS |O | |??? | |Scheduled AE Title |
IIS-1 Accession Number (EI)
Components: ^ ^ ^
Definition: A Scheduler (RIS) generated number that identifies the Filler Order for an Imaging Procedure (Study). Reference DICOM Attribute (0008,0050).
An IDIS that performs functions of the workflow management for a department may accept single Placer Order that gives rise to multiple Filler Orders-Imaging Service requests and identifies each of these with an Accession Number. For example, an IDIS may receive an order for an X-ray examination of the patient daily at 8 am for the next three days. For the purposes of fulfilling the Placer Order, it will identify each of the daily exams as a separate Imaging Service Request with a unique Accession Number.
Each of the Imaging Service Requests may contain one or more Requested Procedures that it will identify with the Requested Procedure ID. The Requested Procedure is the most granular unit of work that may lead to the creation of the procedure report. Each procedure report contributes to the results for the order. To support communication with the instances of equipment in a department (acquisition modalities), IDIS will also generate the Study Instance UID, a globally unique identifier for each Requested Procedure. Note that unlike the Study Instance UID, the Requested Procedure ID must only be unique within the scope of the encompassing Imaging Request.
Each of the Requested Procedures may be further broken down by the IDIS into the Scheduled Procedure Steps based on the timing and equipment requirements and identified with the Scheduled Procedure Step ID. A single Procedure Step may only be performed on a single type and instance of the equipment. Thus, while the Requested Procedure may identify multi-modality examination (such as ones common in Nuclear Medicine), a single Procedure Step shall correspond to the operations performed on a single modality.
The example of the hierarchy of Accession Number, Requested Procedure and Scheduled Procedure Step is depicted in a figure below. SIG to edit picture to include specific field references in the picture.
SIG to add some examples. Recognize confusion over term “accession number” and make sure that the definition is as explicit as possible.
[pic]
It constitutes the context that will be shared between all IDIS within a department in a course of order fulfillment.
IIS-2 Requested Procedure ID (EI)
Components: ^ ^ ^
Definition: Instance Identifier for the Requested Procedure in the Imaging Service Request. SIG to expand definition (non-circular) Reference DICOM Attribute (0040,1001)
IIS-3 Study Instance UID (EI)
Components: ^ ^ ^
Definition: Unique identifier for the Study. SIG to expand definition (non-circular) Reference DICOM Attribute (0020,000D)
IIS-4 Scheduled Procedure Step ID (EI)
Components: ^ ^ ^
Definition: Identifier that identifies a particular sub-procedure (Scheduled Procedure Step) within a requested procedure. The DICOM Value Representation (VR) for Scheduled Procedure Step ID is Short String (SH). Only the first component of is used to populate the HL7 EI data type. Reference DICOM Attribute (0040,0007).
IIS-5 Modality (CE)
Definition: Type of equipment used to create the images for this Study. Refer to Table ??? for Defined Terms. Reference DICOM Attribute (0008,0060).
Populate with entries from the table from Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions, section C.7.3.1.1.1. (This table is included at the end of this submission for reference purposes.)
IIS-6 Protocol Code (CE)
Components: ^ ^ ^ ^ ^
Definition: One or more coded entries identifying the protocol according to which the Scheduled Procedure Step shall to be performed. Protocol Code(s) may identify particular equipment settings as well as operator’s manipulations. Reference DICOM Attribute (0040,0008). SIG to list valid vocabularies/tables or indicate that they are local. SIG to adjust length to no account for repeating.
IIS-7 Scheduled Station Name (CE?)
Definition: This field contains the ID number and name of the modality resource being requested for performance of particular Scheduled Procedure Step. If the Scheduled Procedure Step is to be preformed by an unspecified member of a pool of resources, this element is empty and IIS-8, Scheduled Procedure Step Location us used to identify the customer-defined resource pool specified. Reference DICOM Attribute (0040,0010). SIG to check length.
IIS-8 Scheduled Procedure Step Location (CE)
Definition: This field is used to specify a customer defined resource pool from which the modality resource is chosen. Reference DICOM Attribute (0040,0011). SIG to add to definition, especially to explain resource pool and give examples.
IIS-9 Scheduled Station AE Title (CE)
Definition: This field contains the Application Entity Title of the modality resource being requested for performance of particular Scheduled Procedure Step. If the Scheduled Procedure Step is to be performed by an unspecified member of a pool of resources, this element is empty and IIS-8, Scheduled Procedure Step Location us used to identify the customer-defined resource pool specified. Reference DICOM Attribute (0040,0010). SIG to add examples from table in textual format (preferably something that won’t change).
Editor note: Following table for reference only (not part of proposal)
Reference: DICOM Modality List
|Value |Description |
|AU |Audio |
|BI |Biomagnetic Imaging |
|CD |Color Flow Doppler |
|CR |Computed Radiography |
|CT |Computed Tomography |
|DD |Duplex Doppler |
|DG |Diaphanography |
|DX |Digital X-Ray |
|ECG |Electrocardiography |
|ES |Endoscopy |
|GM |General Microscopy |
|HC |Hard Copy |
|HD |Hemodynamic Waveform |
|IO |Intra-oral Radiography |
|LS |Laser Surface Scan |
|MA |Magnetic Resonance Angiography |
|MG |Mammography |
|MR |Magnetic Resonance |
|MS |Magnetic Resonance Spectroscopy |
|NM |Nuclear Medicine |
|PR |Presentation State |
|PT |Positron Emission Tomography (PET) |
|PX |Panoramic X-Ray |
|RF |Radio Fluoroscopy |
|RG |Radiographic Imaging (conventional film/screen) |
|RTDOSE |Radiotherapy Dose |
|RTIMAGE |Radiotherapy Image |
|RTPLAN |Radiotherapy Plan |
|RTRECORD |RT Treatment Record |
|RTSTRUCT |Radiotherapy Structure Set |
|SM |Slide Microscopy |
|SR |SR Document |
|ST |Single-Photon Emission Computed Tomography (SPECT |
|TG |Thermography |
|US |Ultrasound |
|XA |X-Ray Angiography |
|XC |External-camera Photography |
|OT |Other |
Above table is from Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions, section C.7.3.1.1.1. Copyright 2000 by the National Electrical Manufacturers Association
39 - Add values to HL7 Table 0371- Additive
Submitted By: Joann Larson – Kaiser Permanente
Section: 13.4.3.27
Priority: 21
Description: Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis. Additions to Table 0371 - Additive, as defined in chapter 13, section 13.4.3.27 - SAC-27 Additive (CE) are currently under investigation by the OO Specimen Source task force. Usefulness of an additional column for comments is also under consideration.
Justification: 1/31/01 – forward results to Specimen Source group for further consideration. 4/18 – Scheduled for status and discussion at WGM
Minneapolis Discussion
Motion: Redirect issues # 39, 40, 41, 42, 134 too Specimen Source sub-committee to continue development of proposal for October meeting as a high priority. O/O General conference call will also assist with this proposal as needed. Use version 3 direction as the basis for engineering the solution wherever possible. Scott to coordinate, but reliant on commitment from LAPOCT SIG, Pharmacy SIG, Blood Bank SIG, Micro FG and Government SIG co-chairs.
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
40 - Define HL7 Table NNNN - Specimen Collection Method
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.4.1.15.3
Priority: 22
Description: Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis. Definition of a new HL7 Table NNNN - Specimen Collection Method is currently under investigation by the OO Specimen Source task force.
Justification: 1/31/01 – forward results to Specimen Source group for further consideration. 4/18 – Scheduled for status and discussion at WGM
Minneapolis Discussion
See resolution on #39.
Proposal Language
41 - Define HL7 Table NNNN Body Parts to replace HL7 Table 0163 Body Site
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.4.1.15.4
Priority: 23
Description: Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis. Definition of a new HL7 Table NNNN - Specimen Collection Method is currently under investigation by the OO Specimen Source task force.
Justification: 1/31/01 – forward results to Specimen Source group for further consideration. 4/18 – Scheduled for status and discussion at WGM
Minneapolis Discussion
See resolution on #39.
Proposal Language
42 - Define HL7 Table NNNN Body Parts Modifier
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.4.1.15.5
Priority: 24
Description: Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis. Definition of a new HL7 Table NNNN - Body Parts Modifier is currently under investigation by the OO Specimen Source task force.
Justification: 1/31/01 – forward results to Specimen Source group for further consideration. 4/18 – Scheduled for status and discussion at WGM
Minneapolis Discussion
See resolution on #39.
Proposal Language
50 - Prescription Refill Request (ZPR)
Submitted By: Scott Robertson
Section: 4.12
Priority: 19
Description: Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and is submitting the proposal, without endorsement, for further consideration.
Justification: 2/7/01 – Continued discussion of ZRO-4 as possible duplication of ORC-4. Action Item: Scott R to revise narrative for ZRO-4 to clarify distinction to ORC-4. 4/4/01 – reviewed revised definition for ZRO-4. Now specifically notes difference from ORC-4, most noteably that ZRO-4 groups may include more than one patient. Action Item: forward new ZRO-4 definition to Gunther for comment. Outcome: endorsed by group.
Time slot 10 Minute discussion in Minneapolis
Minneapolis Discussion
Motion to submit to sub-committee for review with Lloyd McKenzie.
Proposal Language
Adopt a new message and segment as outlined below replacing the Z name, trigger event and segment with a permanent message and segment name. We have arbitrarily assigned the “ZPR” message type to 4.12.0, the “ZRO” segment to section 4.13.0 and the example to 4.14.0
Pharmacy/Treatment Trigger Events & Messages
ZPR - Prescription Refill Request and Response Message (Z09)
This message communicates a request for prescriptions to be refilled originating from the patient or the patient's agent. This message would be generated by a system in which the patient or patient's agent directly enters the request, such a telephone-base voice response system or a web-based refill request system.
In this message, general request information is contained in the ZRO segment. This includes a identifier for the request (similar to a purchase order number) and information relating to the person placing the request, delivery and payment information. Associated with the order are one or more patients (PID) each with one or more prescriptions (ORC) to be refilled. There is no assumed relationship between the person placing the request and the patient(s) identified in the PID segments.
Without accounting for the information in the ZRO segment, the request for refills could be communicated with a set of OMP messages, one for each patient. The ZPR message consolidates these messages together and provides a means to associate general request information (e.g., requested by and payment information).
ZPR^Z09^ZPR_Z09 Prescription Refill Request Message
MSH Message Header
ZRO Refill Order Placer
[NTE] Notes and Comments (for ZRO)
{
PID Patient Identification
{ORC} Common Order
}
ZRR^Z10^ZRR_Z10 Prescription Refill Request Response Message
MSH Message Header
MSA
[ERR]
ZRO Refill Order Placer
{
PID Patient Identification
{ORC} Common Order
}
Pharmacy/Treatment Segments
ZRO - Refill Order Placer Segment
The Refill Order Placer segment contains the information related to the person placing a request for prescription(s) to be refilled. Other order information such as pickup location, shipping and payment are also present in this segment
Figure N-N. ZRO attributes
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |250 |CX |R |N | |Nnn |Placer Identifier List |
|2 |250 |XPN |R |N | |Nnn |Placer Name |
|3 |250 |XTN |O |Y | |Nnn |Placer Phone Number & E-mail |
|4 |22 |EI |O |N | |Nnn |Refill Request Number |
|5 |250 |CE |O |N | |Nnn |Pickup Location |
|6 |250 |XPN |C |N | |Nnn |Ship to Person |
|67 |250 |XAD |C |N | |Nnn |Placer Shipping Address |
|78 |250 |XPN |C |N | |Nnn |Credit Card Holder Name |
|89 |250 |CX |C |N | |Nnn |Credit Card Identifier |
|910 |1 |ID |O |N |0136 |Nnn |Credit Card Persistence |
|1011 |50 |ST |C |Y | |Nnn |Voucher Identifier |
|12 |750 |ST |O |N | | |Placer Comment |
ZRO field definitions
Placer identifier list (CX)
Components: ^ ^ ^ ^ ^ ^ ^
Subcomponents of assigning authority: & &
Subcomponents of assigning facility: & &
Definition: This field contains the list of identifiers (one or more) used by the facility to uniquely identify a order (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.). Refer to HL7 table 0061 - Check digit scheme for valid values. With HL7 v2.3.1, the arbitrary term of “internal ID” has been removed from the name of this field for clarity.
Placer name (XPN)
Components: & ^ ^ ^ ^ ^ ^ ^
Definition: This field contains the legal name of the order placer. All other names for the patient should be sent in PID-9-patient alias. Therefore, the name type code in this field should be “L - Legal.” Refer to HL7 table 0200 - Name type for valid values. Repetition of this field is allowed for representing the same name in different character sets. Please refer to the PN data type.
Placer phone number & E-mail (XTN)
Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ ^ ^ ^ ^ ^ ^ ^
Definition: This field contains the order placer’s personal phone numbers including an optional e-mail address. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the first sequence. Refer to HL7 tables 0201 - Telecommunication use code and 0202 - Telecommunication equipment type for valid values.
Group order Refill request number (EI)
Components: ^ ^ ^
Definition: This field uniquely identifies the refill request as a whole and is analogous to a purchase order number in a catalog sales operation. This would typically be populated by the filler system upon acceptance for the request.
Pickup location (CE)
Components: ^ ^ ^ ^ ^
Definition: This field identifies the pharmacy where the prescription is to be picked up (not applicable when the prescription is mailed to the patient).
Ship To Person (XPN)
Components: & ^ ^ ^ ^ ^ ^ ^
Definition: This field contains the name of the person to whom the prescription(s) are being shipped.
Required if the prescription is to be shipped to the patient rather than picked up.
Placer shipping address (XAD)
Components: ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^
Definition: This field contains the mailing address of the order placer. Address type codes are defined by HL7; see HL7 table 0190 - Address type. Multiple addresses for the same person may be sent in the following sequence: The primary mailing address must be sent first in the sequence (for backward compatibility); if the mailing address is not sent, then a repeat delimiter must be sent in the first sequence. Required if the prescription is to be shipped to the patient rather than picked up.
Credit card holder name (XPN)
Components: & ^ ^ ^ ^ ^ ^ ^
Definition: This field contains the name on the credit card being used in this transaction. Required if the prescription is to be paid for with a credit card.
Credit card identifier (CX)
Components: ^ ^ ^ < assigning authority (HD)> ^ ^ < assigning facility (HD) ^ ^
Subcomponents of assigning authority: & &
Subcomponents of assigning facility: & &
Definition: This field contains the credit card number, effective date and expiration date for the credit card being used for this transaction. Constraint: The identifier type code, Table 0203, values used within this segment must be among those that represent a credit card (e.g. Master Card, Visa). Required if the prescription is to be paid for with a credit card.
Credit card persistence (ID)
Definition: This field indicates whether or not the credit card being used in this transaction should be the default for future transactions initiated by the order placer for this transaction.
Voucher Identifier (EI)
Components: ^ ^ ^
Definition: This field contains any voucher number(s) the placer wishes to use to pay for these refills. Vouchers may be used to pay in part or in full for one or more prescriptions. They may be used in conjunction with a credit card. Required if vouchers are used to pay for some or all of the prescription(s).
Placer Comments (ST)
Definition: This field may contain a comment from the refill request placer.
Pharmacy/Treatment Message Examples
ZRO - Prescription Refill Request Example Messages
Example:
Mae West uses the automated pharmacy refill order request system to request refills for two prescriptions for herself and one for W. C. Fields.
MSH|^~\`|KPONLINE|NW|RX.PIMS||19980731164531-0700||ZPR^Z09^ZPR_Z09|519376482|P|2.4
ZRO|256987584123^^^NW.MPI^MR|WEST^MAE^B|^PRN^^^^310^5551212~^WPN^^^^310^5551313~^NET^Internet^mae.west@|||WEST^MAE^B|268 SANTA MONICA BLVD^^BEVERLY HILLS^CA^90210|WEST^MAE^B|4417374099083201^^^VUSA^VS^^^200205|Y|54381~63282
PID|||193728465097^^^NW.MPI^MR||FIELDS^WILLIAM^C||19000101|M
ORC|RF||52453816||||||19980726|||^LISTER^LISA^^^^MD||||
PID|||583250978416^^^NW.MPI^MR ||WEST^MAE^B||19000101|M
ORC|RF||58246718||||||19980726|||^WELBY^MARCUS^^^^MD||||
ORC|RF||52453673||||||19971002|||^WELBY^MARCUS^^^^MD||||
Pharmacy system responds to the requestor and indicates when the prescription will be sent or will be ready:
MSH|^~\`|RX.PIMS|NW|KPONLINE||19980731164615-0700||ZRR^Z10^ZRR_Z10|519376511|P|2.4
MSA|AA|519376482
ZRO|256987584123^^^NW.MPI^MR|WEST^MAE^B|^PRN^^^^310^5551212~^WPN^^^^310^5551313~^NET^Internet^mae.west@|19568473215||WEST^MAE^B|268 SANTA MONICA BLVD^^BEVERLY HILLS^CA^90210|WEST^MAE^B|4417374099083201^^^VUSA^VS^^^200205|Y|54381~63282
PID|||193728465097^^^NW.MPI^MR||FIELDS^WILLIAM^C||19000101|M
ORC|OK||52453816||||||19980726|||^LISTER^LISA^^^^MD||||||||||||||199808010800-0700
PID|||583250978416^^^NW.MPI^MR ||WEST^MAE^B||19000101|M
ORC|OK||58246718||||||19980726|||^WELBY^MARCUS^^^^MD||||||||||||||199808010800-0700
ORC|OK||52453673||||||19971002|||^WELBY^MARCUS^^^^MD||||||||||||||199808010800-0700
57 - OM2-6 Change data type to RFR
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.8.4.6
Priority: 22
Description: Continuation of a v2.4 ballot response originally submitted by Frank Oemig to the Spring 2000 Working Group meeting in Cleveland. The OO General Subcommittee reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension as delineated in the Proposed Solution below.
Justification: Orlando OO: Tabled pending data type resolution. 3/9/01 - CQ Call: RFR data type endorsed.
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
8.8.4.6 OM2-6 Reference (normal) range for ordinal and continuous observations (CM) (RFR) 00631
Components: ^ ^ ^ ^ ^ ^
Definition: This field contains the reference (normal) ranges for “numeric” observations/tests with a nature code of A or C (see OM1-18 - Nature of service/test/observation). It can identify different reference (normal) ranges for different categories of patients according to age, sex, race, and other conditions.
The general format is:
^^^^^^~
^^^^^^~
·
·
·
^^^^^^
The components are defined in the following sections.
58 - OM2-7 Change data type to RFR
Submitted By: Scott – Robertson – Kaiser Permanente
Section: 8.8.4.7
Priority: 23
Description: Continuation of a v2.4 ballot response originally submitted by Frank Oemig to the Spring 2000 Working Group meeting in Cleveland. The OO General Subcommittee reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension, with noted issue, as delineated in the Proposed Solution below.
Justification: Orlando OO: Tabled pending data type resolution. 3/9/01 - CQ Call: RFR data type endorsed. 4/6/01 - CQ Call: Is the resolution of the narrative/component model conflict issue considered a technical correction? To do so would be consistent with the resolution of an earlier issue about ambiguous abstract message syntax.
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
8.8.4.7 OM2-7 Critical range for ordinal and continuous observations (CM) (RFR) 00632
Components:
Components ^ ^ ^ ^ ^ ^
Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18 - Nature of service/test/observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6 - Reference (normal) range-ordinal & continuous observation).
Issue: the subcommittee notes a backward compatibility issue (a prior implementation would expect |10^20| but would receive |10&20|). However, the subcommittee takes the position that the RFR data type is the most appropriate data type for OM2-7.
59 - OM2-8 Change data type to RFR
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.8.4.8
Priority: 26
Description: Continuation of a v2.4 ballot response originally submitted by Frank Oemig to the Spring 2000 Working Group meeting in Cleveland. The OO General Subcommittee reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension, with noted issue, as delineated in the Proposed Solution below.
Justification: Orlando OO: Tabled pending data type resolution 3/9/01 - CQ Call: RFR data type endorsed. 4/6/01 - CQ Call: Is the resolution of the narrative/component model conflict issue considered a technical correction? To do so would be consistent with the resolution of an earlier issue about ambiguous abstract message syntax.
Minneapolis Discussion
Against: 0, Abstain: 1, In Favor: 13
Proposal Language
8.8.4.8 OM2-8 Absolute range for ordinal and continuous observations (CM) (RFR) 00633
Components: ^ ^ ^
Components: ^ ^ ^ ^ ^ ^
Definition: This field applies only to single tests/observations with a nature code of A or C (see OM1-18 - Nature of service/test/observation). It defines the range of possible results. Results outside this range are not possible. The field should be recorded in the same format as the normal and critical ranges.
60 - OM2-9 Change data type to DLT
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.8.4.9
Priority: 29
Description: Continuation of a v2.4 ballot response originally submitted by Frank Oemig to the Spring 2000 Working Group meeting in Cleveland. The OO General Subcommittee reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension, with noted issue, as delineated in the Proposed Solution below.
Justrification: Orlando OO: Tabled pending data type resolution. 3/9/01 - CQ Call: DLT data type endorsed
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
8.8.4.9 OM2-9 Delta check criteria (CM) (DLT) 00634
Components: ^ ^ ^
components < Normal Range (NR)> ^ < numeric threshold (NM)> ^ < change computation (ST)> ^ < length of time-days (NM)>
Definition: This field applies to numeric tests/observations with a nature code of A or C (see OM1-18 - Nature of service/test/observation). The field describes the information that controls delta check warnings and includes four components.
1) The range to which the following applies: .
All the ranges are defined in terms of the customary reporting units given in OM2-2-units of measure. If no value range is given, the check applies to all values.
2) The numeric threshold of the change that is detected, e.g., 10.
3) Whether the change is computed as a percent change or an absolute change. This component can have two possible values:
% Indicates a percent change
a Absolute change
4) The length of time that the service retains a value for computing delta checks. This is recorded in number of days.
More than one delta check rule can apply. 13&16^10^%^100~16.1&20^2^a^100 implies that the delta check will trigger on a 10% change when the value of the observation is between 13 and 16. The check will trigger on an absolute change of 2 when the value is between 16.1 and 20. In both cases, the system will keep the last result for 100 days. In this example, beyond 100 days, the computer will not compute a delta check because it will not have a comparison value.
70 - OM2-7 Critical Range Change component model
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.8.4.7
Priority: 24
Description: Continuation of a proposal originally submitted by Japan to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Justification: OO: Tabled pending data type resolution. 3/9/01 - CQ Call: RFR data type endorsed. 3/16/01 - CQ Call: Mark S noted revision should include data types for components. This proposal should be coordinated with CM proposal for v2.5 (use new CM rather than defining as CM). Action Item: revise per discussion. 4/46 - [Scott R] suggest to withdraw in favor of proposal 58
Minneapolis Discussion:
Motion to ask Japanese to withdraw in light of resolution 58.
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
8.7.4.7 Proposes to change
Components:
Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18-nature of service/test/observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6-reference (normal) range-ordinal & continuous obs)
To
Components: ^ ^ ^ ^ ^ ^
Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18-nature of service/test/observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6-reference (normal) range-ordinal & continuous obs)
Comments
It is changed to the same components as OM2-6.
75 - Combine Tables 0286 and 0443 and change table type to HL7
Submitted By: Scott Robertson – Kaiser Permanente
Section: 12.4.3.3
Priority: 32
Description: Continuation of a v2.4 ballot review issue. This proposal was requested by the Orders TC to resolve the issue. Kaiser Permanente submits this proposal in response to the issue and Orders TC request. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below. Table 0443 - Provider role, as defined in section 12.4.3.3, seems to overlap with User-defined table 0286-Provider Role as used in PRD-1 as defined in section 11.6.3.1. This was pointed out in the KP response to the v 2.4 membership ballot. The resolution was to note the overlap in v 2.4 and to correct the problem in the next release.
Justification: OO: vote 7/0/4 (Favor/Against/Abstain) - PAFM: PtCare: vote 4/0/0 requested addition of column to table for harmonization to V3. Scott Robertson agree to develop this proposal for consideration by other TCs in May 2001. 1/31/01 – SR will work up new proposal. 2/26/01 – PAFM (Frieda) noted possible backward compatibility issue. Possibly present to ARB and/or CQ 3/9/01 CQ Call: concept to add v3 notations to v2.x table. extensive discussion. Need to confer with Frank & Karen regarding table structure. Alternative to add as comment column. Suggest new proposal to define separate attributes for role and participation in v2.x. Refer back to OO and PtCare. Options: 1 new table; 2 new tables. Adding v3 reference to table(s) may not be compatible with document(?).
Minneapolis Discussion
No action by committee. Noted that this proposal was not accepted by PAFM and CQ. The proposal is reverting to author for review and reconsideration.
Proposal Language
85 - OBX-2 length correction
Submitted By: Nick Radov - Axolotl Corporation
Section: 7.4.2
Priority: 11
Description: Two parts of the standard are in conflict.
Justification: Field OBX-2 has a maximum length of 2, but table 125 lists several 3 character values. Therefor the length of OBX-2 should be changed to 3.
Minneapolis Discussion
Against: 0, Abstain: 1, In Favor: 11
Proposal Language
87 - Section reference correction
Submitted By: Richard Harding - Queensland Health
Section: 4.1.29
Priority: 12
Description: Minor typo in cross-reference
Justification: Reference in 7.4.1.29 to "(see Segment ORC field notes in Section 4.3.1.1.1, "Table notes for order control codes of ORC." should refer to 4.5.1.1.1(i). There should also be a close bracket in this sentence. 2/21/01 – Reviewed and endorsed by group
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous.
Proposal Language
89 - Editorial correction
Submitted By: Richard Harding – Queensland Health
Section: 7.4.1.0
Priority: 13
Description: Minor typo. The first sentence of 7.4.1.0 is incomprehensible and should be identical to 4.5.3.0 .
Justification: Change first sentence of 7.4.1.0 to read "the daggered items in this segment are created by the filler, not the placer". Change the words "known to" in first sentence of 4.5.3.0 to "created by".
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
93 - Section 4.5.3.32 technical correction
Submitted By: Karen Van Hentenryck – HL7
Section: 4.5.3.32
Priority: 34
Description: technical corrections
Justification: Subcomponents of name (CN) are incorrectly listed in OBR-33. 5/2/01 OO: related to CM project. Noted that subcomponent structure include HD (sub-sub-components)
Minneapolis Discussion
Sub-committee Action item to submit proposal to fix problem properly in V2.x.
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
OBR-32 Principal result interpreter (CM) 00264
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & &
Subcomponents of facility: & &
Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content.
OBR-33 Assistant result interpreter (CM) 00265
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & &
Friendly amendment to add something to the description to say that these data types are known to have sub-sub-components which is not compatible and that a fix will be included in a future release.
94 - Section 4.5.3.34 technical correction
Submitted By: Karen Van Hentenryck – HL7
Section: 4.5.3.34
Priority: 33
Description: technical correction
Justification: subcomponentns of name (CN) are incorrect in OBR-34 and OBR-35. 5/2/01 OO: related to CM project. Noted that subcomponent structure include HD (sub-sub-components)
Minneapolis Discussion
Sub-committee Action item to submit proposal to fix problem properly in V2.x.
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
OBR-34 Technician (CM) 00266
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & & Subcomponents of facility: & &
Definition: This field identifies the performing technician.
OBR-35 Transcriptionist (CM) 00267
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & &
Subcomponents of facility: & &
Friendly amendment to add something to the description to say that these data types are known to have sub-sub-components which is not compatible and that a fix will be included in a future release.
95 - ORC – Security/Sensitivity
Submitted By: HL7 Canada – Affiliate Member
Section: 4.5.1
Priority: 29
Description: As with the PRB (Problem Detail Segment), there is a need to communicate the security or sensitivity level of an order. This is due to the fact that a patient may have the right to designate an order as being confidential, via privacy legislation, or otherwise. For instance, drug orders can imply medical conditions that the patient may wish, and have the right, to keep private. This information can be used to prevent order records from being retrieved when practitioners review patient order history, or to indicate that communications relating to a particular order should be handled with increased sensitivity.
Justification: The security/sensitivity level of an order needs to be communicated
Minneapolis Discussion
Motion: Friendly amendment as shown in proposal document.
Action: Lloyd to add values to the table in separate proposal after they have been V3 harmonized.
Action: Llloyd to add comments/definitions values.
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
Add a Security/Sensitivity element to the Common Order Segment:
HL7 Attribute Table – ORC – Common Order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |2 |ID |R |N |0119 |00215 |Order Control |
|2 |22 |EI |C | | |00216 |Placer Order Number |
|3 |22 |EI |C | | |00217 |Filler Order Number |
|4 |22 |EI |O | | |00218 |Placer Group Number |
|5 |2 |ID |O |N |0038 |00219 |Order Status |
|6 |1 |ID |O | |0121 |00220 |Response Flag |
|7 |200 |TQ |O |Y | |00221 |Quantity/Timing |
|8 |200 |CM |O | | |00222 |Parent |
|9 |26 |TS |O | | |00223 |Date/Time of Transaction |
|10 |250 |XCN |O |Y | |00224 |Entered By |
|11 |250 |XCN |O |Y | |00225 |Verified By |
|12 |250 |XCN |O |Y | |00226 |Ordering Provider |
|13 |80 |PL |O | | |00227 |Enterer’s Location |
|14 |250 |XTN |O |Y/2 | |00228 |Call Back Phone Number |
|15 |26 |TS |O | | |00229 |Order Effective Date/Time |
|16 |250 |CE |O | | |00230 |Order Control Code Reason |
|17 |250 |CE |O | | |00231 |Entering Organization |
|18 |250 |CE |O | | |00232 |Entering Device |
|19 |250 |XCN |O |Y | |00233 |Action By |
|20 |250 |CE |O | |0339 |01310 |Advanced Beneficiary Notice Code |
|21 |250 |XON |O |Y | |01311 |Ordering Facility Name |
|22 |250 |XAD |O |Y | |01312 |Ordering Facility Address |
|23 |250 |XTN |O |Y | |01313 |Ordering Facility Phone Number |
|24 |250 |XAD |O |Y | |01314 |Ordering Provider Address |
|25 |250 |CWE |O |N | |01473 |Order Status Modifier |
| |250 |CE |O |N | | |Confidentiality |
ORC - Confidentiality (CE) 00823
Components: ^ ^ ^ ^ ^
Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Suggested values from security_ind in Version 3 are:
HL7 Table XXX – Confidentiality*
|Value |Description |Comments |
|B |Business | |
|C |Celebrity | |
|D |Clinician | |
|ETH |Substance Abuse Related | |
|HIV |HIV Related | |
|I |Individual | |
|L |Low | |
|N |Normal | |
|PSY |Psychiatry Related | |
|R |Restricted | |
|S |Sensitive | |
|SDV |Sex and Domestic Violence Related | |
|T |Taboo | |
* Maps to Version 3 domain
96 - RXO – Order Type
❑ Submitted By: HL7 Canada – Affiliate Member
❑ Section: 4.14.1
❑ Priority: 21
❑ Description: The Prescription Type indicates where a patient order should be filled, and thereby, the business rules and process by which that order will be executed. There are differing rules and procedures by which pharmacists are bound in alternate institutional settings (inpatient, community pharmacy, and outpatient). Therefore, the routing of the order via the Prescription Type will ensure it is processed under the rules and conventions for which it was intended.
❑ Justification: A field is required to indicate whether or not a pharmacy order is an inpatient order, a community pharmacy order, or an outpatient order.
Minneapolis Discussion
Relative to relationship between this proposal and proposal 84, the two appear to be different dimension.
Friendly amendment: application of this concept appears to be broader than just pharmacy. Move this attribute to ORC segment. Follow-up to revise name as appropriate. Current concepts include “Ambulatory Setting”. Definition modified to clarify default meaning dependent on system interpretation.
Motion to accept proposal with friendly amendments as noted in proposal
Against: 0, Abstain: 0, In Favor 14
Proposal language
A) Add Element to ORC
HL7 Attribute Table – ORC – Common Order Segment
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
| |250 |CE |O |N | | |Order Type |
ORC - Order Type (CE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates whether the order is an inpatient order or intended to be filled in a community pharmacy. If this field is not valued, the system default is assumed. Suggested values might be:
HL7 Table XXX - Prescription Type (sync with field name)
|Value |Description |
| | |
|M |Inpatient Order |
|O |Outpatient Order |
| | |
B) Extension of V2.x Proposal 84 – Kaiser Permanente
The problem statement in Proposal 84 closely matches the intent behind this proposal:
Pharmacy order entry and processing are generally separated into three broad categories; Medication, Piggyback / Solutions as Medications and Large Volume IV Orders. These three categories may determine the processing that sending and receiving systems will perform. Pharmacy orders have broad functional differences based on the order types described herein. Packaging, dispensing, retrieving, ordering, administering and charging can be vastly different between these order types.
The processing rules required for pharmacy orders can differ based upon the nature of the order (Medication, Piggyback / Solutions as Medications and Large Volume IV Orders) as well as the nature of the facility where the order is intended to be filled (Community Order, Inpatient Order, Outpatient Order). If it can be assumed that the three values outlined in Proposal 84 imply a Med order, the addition of a fourth value (C – Community/Outpatient) can be used to meet the needs of this proposal.
97 - ORC – Action Authorization Mode
Submitted By: HL7 Canada – Affiliate Member
Section: 4.5.1
Priority: 29
Description: With the introduction of electronic order processing, along with the growing use of the telephone/fax machine to communicate authorizations, order authorizations are no longer solely paper-based. Arising with these new forms of authorizations is the need to record how the recorder will receive said authorization. This information can be used in a variety of audit control processes (for instance a pharmacist can verify a phone conversation to alter an order by reviewing the action authorization mode in the order’s electronic form).
Justification: A field is needed to indicate what kind of communication was used to authorize an Action or an Order
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 13
Proposal Language
HL7 Attribute Table – ORC – Common Order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |2 |ID |R |N |0119 |00215 |Order Control |
|2 |22 |EI |C | | |00216 |Placer Order Number |
|3 |22 |EI |C | | |00217 |Filler Order Number |
|4 |22 |EI |O | | |00218 |Placer Group Number |
|5 |2 |ID |O |N |0038 |00219 |Order Status |
|6 |1 |ID |O | |0121 |00220 |Response Flag |
|7 |200 |TQ |O |Y | |00221 |Quantity/Timing |
|8 |200 |CM |O | | |00222 |Parent |
|9 |26 |TS |O | | |00223 |Date/Time of Transaction |
|10 |250 |XCN |O |Y | |00224 |Entered By |
|11 |250 |XCN |O |Y | |00225 |Verified By |
|12 |250 |XCN |O |Y | |00226 |Ordering Provider |
|13 |80 |PL |O | | |00227 |Enterer’s Location |
|14 |250 |XTN |O |Y/2 | |00228 |Call Back Phone Number |
|15 |26 |TS |O | | |00229 |Order Effective Date/Time |
|16 |250 |CE |O | | |00230 |Order Control Code Reason |
|17 |250 |CE |O | | |00231 |Entering Organization |
|18 |250 |CE |O | | |00232 |Entering Device |
|19 |250 |XCN |O |Y | |00233 |Action By |
|20 |250 |CE |O | |0339 |01310 |Advanced Beneficiary Notice Code |
|21 |250 |XON |O |Y | |01311 |Ordering Facility Name |
|22 |250 |XAD |O |Y | |01312 |Ordering Facility Address |
|23 |250 |XTN |O |Y | |01313 |Ordering Facility Phone Number |
|24 |250 |XAD |O |Y | |01314 |Ordering Provider Address |
|25 |250 |CWE |O |N | |01473 |Order Status Modifier |
| |250 |CE |O |N | | |Action Authorization Mode |
ORC Action Authorization Mode (CE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. E.g. paper Rx, electronic Rx, fax, phone call. Suggested values might be taken from the Participation.mode_cd as to be defined in Version 3:
HL7 Table XXX - Action Authorization Mode*
|Value |Description |
| |Electronic |
| |E-mail |
| |Fax |
| |In Person |
| |Mail |
| |Paper |
| |Phone |
| |Reflexive (Automated system) |
| |Video-conference |
| |Voice |
* Will be mapped to the values published in Version 3.
99 - RDI – Drug Information Segment (new segment)
Submitted By: HL7 Canada – Affiliate Member
Section: 4.14
Priority: 24
Description: Currently, HL7 only provides an infrastructure to transmit information about drugs in relation to a prescribing, dispensing, etc. event. However, there is a need for health care providers to review a drug’s monograph, or to search drug information databases. Drug Monograph information can be reviewed by health care providers out of general interest, or in relation patient service events.
Justification: A segment is required to transmit information about a particular generic, generic formulation, or manufactured drug. It will be used to show suggested drugs, and possibly for master drug file use.
Minneapolis Discussion
Tabled for future consideration when it can be placed in context of specific messages. Also to allow for input by other interested parties on additional attributes
Proposal Language
HL7 Attribute Table – RDI – Drug Information
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|A |250 |CE |O | | | |Manufactured Name |
|B |250 |CE |O | | | |Formulation |
|C |250 |CE |O | | | |Generic or Excipient |
|D |250 |CE |O | | | |Form |
|E | | |O | | | |Strength Units |
|F |80 |XON |O | | | |Manufacturer |
|G |16000 |FT |O | | | |Monograph |
|H |20 |NM |O | | | |Ingredient Count |
RDI-1 Manufactured Name (CE)
Components: ^ ^ ^ ^ ^
Definition: This field will provide the code and name of the manufactured drug product.
RDI-2 Formulation (CE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates code and name of the formulation (specific combination of different generic ingredients).
RDI-3 Generic or Excipient (CE)
Components: ^ ^ ^ ^ ^
Definition: This field carries the generic code and name for the generic form of the drug, or the name of an excipient ingredient.
RDI-4 Form (CE)
Components: ^ ^ ^ ^ ^
Definition: This field identifies the form the drug takes.
RDI-5 Strength Units ()
Components: ^
Subcomponents of units: & & & & &
Definition: This field indicates the strength the specified drug is manufactured in.
RDI-6 Manufacturer (ST)
Definition: The name of the drug manufacturer.
RDI-7 Monograph (FT)
Definition: This field contains the complete text of the drug monograph. Multiple repetitions of the field are used if necessary.
RDI-8 Ingredient Count (NM)
Definition: This field identifies how many individual active ingredients make up the Generic/Formulation/Manufactured drug product.
100 - RXD – Dispense Type
Submitted By: HL7 Canada – Affiliate Member
Section: 4.14.5
Priority: 22
Description: There are many ways in which a drug can be dispensed to a patient. For instance, a patient might receive a trial quantity, a manufacturer sample, or a “regular” new full fill, among many other types of dispenses. Given that the nature of the dispense may have an impact on the overall care of the patient, the Dispense Type needs to be communicated to provide a complete profile of the patient’s care. This information can be used in compliance checking, or other monitoring activities. This field is most relevant to outpatient or community dispensing systems.
Justification: An element is required to communicate the type of dispensing event that occurred.
Minneapolis Discussion
Against: 0, Abstain: 1, In Favor 13
Proposal Language
Add an element to the Pharmacy/Treatment Dispense segment:
HL7 Attribute Table – RXD – Pharmacy/Treatment Dispense
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |4 |NM |R | | |00334 |Dispense Sub-ID Counter |
|2 |250 |CE |R | |0292 |00335 |Dispense/Give Code |
|3 |26 |TS |R | | |00336 |Date/Time Dispensed |
|4 |20 |NM |R | | |00337 |Actual Dispense Amount |
|5 |250 |CE |C | | |00338 |Actual Dispense Units |
|6 |250 |CE |O | | |00339 |Actual Dosage Form |
|7 |20 |ST |R | | |00325 |Prescription Number |
|8 |20 |NM |C | | |00326 |Number of Refills Remaining |
|9 |200 |ST |O |Y | |00340 |Dispense Notes |
|10 |200 |XCN |O |Y | |00341 |Dispensing Provider |
|11 |1 |ID |O | |0167 |00322 |Substitution Status |
|12 |10 |CQ |O | | |00329 |Total Daily Dose |
|13 |200 |CM |C | | |01303 |Dispense-to Location |
|14 |1 |ID |O | |0136 |00307 |Needs Human Review |
|15 |250 |CE |O |Y | |00330 |Pharmacy/Treatment Supplier’s Special Dispensing |
| | | | | | | |Instructions |
|16 |20 |NM |O | | |01132 |Actual Strength |
|17 |250 |CE |O | | |01133 |Actual Strength Unit |
|18 |20 |ST |O |Y | |01129 |Substance Lot Number |
|19 |26 |TS |O |Y | |01130 |Substance Expiration Date |
|20 |250 |CE |O |Y |0227 |01131 |Substance Manufacturer Name |
|21 |250 |CE |O |Y | |01123 |Indication |
|22 |20 |NM |O | | |01220 |Dispense Package Size |
|23 |250 |CE |O | | |01221 |Dispense Package Size Unit |
|24 |2 |ID |O | |0321 |01222 |Dispense Package Method |
|25 |250 |CE |O |Y | |01476 |Supplementary Code |
|26 |250 |CE |O | | |01477 |Initiating Location |
|27 |250 |CE |O | | |01478 |Packaging/Assembly Location |
| |250 |CE |O | | | |Dispense Type |
RXD - Dispense Type (CE)
Components: ^ ^ ^ ^ ^
Definition: This is the type of dispensing event that occurred. Valid codes might include:
User Table XXX - Dispense Type
|Value |Description |
|B |Trial Quantity Balance |
|C |Compassionate Fill |
|N |New/Renew - Full Fill |
|P |New/Renew - Part Fill |
|Q |Refill - Part Fill |
|R |Refill - Full Fill |
|S |Manufacturer Sample |
|T |Trial Quantity |
|Z |Non-Prescription Fill |
101 - RXE – Dispensing Interval
Submitted By: HL7 Canada – Affiliate Member
Section: 4.14.4
Priority: 23
Description: The Dispensing Interval is required in order to minimize the chance of patient’s accumulating too much of a given medication given special conditions such as the nature of the drug (for example, pain killers), the patient’s previous compliance history, or similar factors. This field will be most useful in a community dispense situation.
Justification: The ability to specify a minimum period of time between dispensing events is needed.
Minneapolis Discussion
Friendly amendment: should be in RXO rather than RXE
Should this be a component or represented within TQ? NO, this addresses an implied act while TQ addresses the order. It would be appropriate to describe with TQ if the implied acts
Against: 0, Abstain: 4, In Favor 10
Proposal Language
HL7 Attribute Table – RXO – Pharmacy/Treatment Encoded Order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
| |20 |NM |O | | | |Dispensing Interval |
RXO - Dispensing Interval (NM)
Definition: This field specifies the minimum number of days that must occur between dispensing events.
109 - Correct data type component model for RXD-12 Total Daily Dose
Submitted By: Scott Robertson – Kaiser Permanente
Section: 4.14.5.12
Priority: 16
Description: The component model for RXD-12 describes a TQ data type, while the data type for RXD-12 is CQ. Based upon the description, CQ appears to be the correct data type and the component model should be corrected.
Justification: 5/2/01 OO: should be applied as v2.3.1 errata. And subsequently pulled forward as v2.4 errata and v2.5 editorial change
Minneapolis Discussion
Against: 0,Abstain: 1, In Favor: 11
Proposal Language
110 - Correct PRD-7 and CTD-7 references to PRA-6
Submitted By: Scott Robertson – Kaiser Permanente
Section: 11.6.3.7, 11.6.4.7
Priority: 14
Description: The definitions of PRD-7 and CTD-7 refer to PRA-6. However, the reference points to the location of PRA-6 in v2.3.1 (Section 8.6.3.6). With v2.4, PRA-6 was moved to Chapter 15 (Section 15.4.5.6).
Justification: 5/2/01 OO: should be applied as v2.4 errata. And subsequently pulled forward as v2.5 editorial change
Minneapolis Discussion
Against: 0,Abstain: 1,In Favor: 11
Proposal Language
Correct PRA-6 references in PRD-7 and CTD-7 to point to section 15.4.5.6.
11.6.3.7 PRD-7 Provider identifiers (CM) 01162
Components: ^ ^
Definition: This repeating field contains the provider’s unique identifiers such as UPIN, Medicare and Medicaid numbers. Refer to PRA-6-Practitioner ID numbers in Chapter 8 15 (Section 8.6.3.6 15.4.5.6, “Practitioner ID numbers”) for suggested values.
11.6.4.7 CTD-7 Contact identifiers (CM) 01171
Components: ^ ^
Definition: This repeating field contains the contact’s unique identifiers such as UPIN, Medicare and Medicaid numbers. Refer to PRA-6-Practitioner ID numbers in Chapter 8 15 (Section 8.6.3.6 15.4.5.6, “Practitioner ID numbers”) for suggested values.
111 - Add constraint language to Table 0080.
Submitted By: Scott Robertson – Kaiser Permanente
Section: 7.4.2.10
Priority: 15
Description: “Species, Breed and Strain" were proposed and added to Table 0080 at the Orlando Working Group meeting in January 2001. At that time, the Orders TC requested that constraint language be developed to specify that these new values are only used in the correct context of PID-35, PID-36, and PID-37. This proposal is submitted to address the constraint language request.
Justification:
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 11
Proposal Language
As suggested by Bruce Wood. Add constraint language after the table in 7.4.2.10. Revise descriptions for consistency to other values.
Green highlights were approved in Orlando.
7.4.2.10 OBX-10 Nature of abnormal test (ID) 00578
Definition: This field contains the nature of the abnormal test. Refer to HL7 Table 0080 - Nature of abnormal testing for valid values. As many of the codes as apply may be included, separated by repeat delimiters. For example, normal values based on age, sex, and race would be codes as A~S~R.
HL7 Table 0080 - Nature of abnormal testing
|Value |Description |
|A |An age-based population |
|N |None - generic normal range |
|R |A race-based population |
|S |A sex-based population |
|SP |A Species-based population |
|B |A Breed-based population |
|ST |A Strain-based population |
The values of SP – Species, B – Breed, and ST – Strain should not be used unless PID-35 Species Code, PID-36 Breed Code, and/or PID-36 Strain are also valued appropriately.
113 - Revise repetition structure for RXC-NTE in Pharmacy Messages
Submitted By: Scott Robertson – Kaiser Permanente
Section: 4.13.3, 4.13.4
Priority: 31
Description: The message structure in 4.13.5 OMP Pharmacy/Treatment Order Message (and other messages) appears to indicate that zero to many RXC segments may be followed by zero to many NTE segments. The message syntax does not support RXC-NTE-RXC-NTE sequences, which are necessary if there are specific associations between RXC and NTE segments. As such associations between RXC and NTE segment may be necessary, the message syntax should be modified to indicate this relationship.
Justification:
Minneapolis Discussion
An amendment was provided and accepted.
Against: 0, Abstain: 3, In Favor: 9
Proposal Language
The repetition close brace following the RXC segment should be moved to a point after the optionality close bracket following the NTE. ( change from [ { RXC } [ { NTE} ] ] to [ { RXC [ { NTE} ] } ] ) The RXC-NTE construct in question in found in association with an RXO segment in the message syntax of sections 4.13.3 (OMP), 4.13.4 (ORP), 4.13.5 (RDE), 4.13.7 (RDS), 4.13.9 (RGV) and 4.13.11 (RAS).
OMP - pharmacy/treatment order message (event O09)
…
|OMP^O09^OMP_O09 |Pharmacy/treatment Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| RXO |Pharmacy/Treatment Order |4 |
| [{NTE}] |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for each RXC) |2 |
| } | | |
| ] | | |
| [ | | |
| { | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| } | | |
| ] | | |
| [{FT1}] |Financial Transaction |6 |
| [BLG] |Billing Segment |6 |
|} | | |
ORP - pharmacy/treatment order acknowledgment (event O10)
|ORP^O10^ORP_O10 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| ] | | |
| { | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy/Treatment Order |4 |
| [{NTE}] |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for each RXC) |2 |
| } | | |
| [ | | |
| ] | | |
| } | | |
|] | | |
RDE - pharmacy/treatment encoded order message (event O11)
…
|RDE^O11^RDE_O11 |Pharmacy/Treatment Encoded Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
| [{IN1 |Insurance | |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy/Treatment Prescription Order |4 |
| [{NTE}] |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for each RXC) |2 |
| } | | |
| ] | | |
| ] | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component (for RXE) |4 |
| [{ | | |
| OBX |Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| }] | | |
| {[CTI]} |Clinical Trial Identification |7 |
|} | | |
RDS - pharmacy/treatment dispense message (event O13)
…
|RDS^O13^RDS_O13 |Pharmacy/Treatment Dispense Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for PID) |2 |
| [{AL1}] |Allergy Information |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit - Additional Info |3 |
| ] | | |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy /Treatment Order |4 |
| [ | | |
| {NTE} |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| } | | |
| ] | | |
| ] | | |
| ] | | |
| [ | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| ] | | |
| RXD |Pharmacy/Treatment Dispense |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| [{ | | |
| OBX |Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| }] | | |
| [{FT1}] |Financial Transaction segment |6 |
|} | | |
RGV - pharmacy/treatment give message (event O15)
…
|RGV^O15^RGV_O15 |Pharmacy/Treatment Give |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [{NTE}] |Notes and Comments (for PID) |2 |
| [{AL1}] |Allergy Information |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy /Treatment Order |4 |
| [ | | |
| {NTE} |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| } | | |
| ] | | |
| ] | | |
| ] | | |
| [ | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| ] | | |
| { | | |
| RXG |Pharmacy/Treatment Give |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| { | | |
| [OBX] |Observation/Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| } | | |
| } | | |
|} | | |
RAS - pharmacy/treatment administration message (event O17)
…
|RAS^O17^RAS_O17 |Pharmacy/Treatment Administration |Chapter |
| | | |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for PID) |2 |
| [{AL1}] |Allergy Information |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy /Treatment Order |4 |
| [ | | |
| {NTE} |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| ] | | |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| [ | | |
| { | | |
| RXC |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| } | | |
| ] | | |
| ] | | |
| [ | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| ] | | |
| {{RXA} |Pharmacy/Treatment Administration |4 |
| RXR |Pharmacy/Treatment Route |4 |
| {[OBX |Observation/Result |7 |
| {[NTE]} |Notes and Comments (for OBX) |2 |
| ]}} | | |
| {[CTI]} |Clinical Trial Identification |7 |
|} | | |
114 - Replace the TQ data type with two new segments, the TQ1 and TQ2
Submitted By: Austin Kreisler – McKessonHBOC ITB
Section: TBD
Priority: 11
Description: The TQ data type has a number of “features” that break the HL7 message encoding rules as given in chapter 2. To correct these problems, and retain the TQ as a data type would require several changes to the message encoding rules, and adding component and sub-component repeat delimiters. A much simpler approach is to migrate this data type to a pair of new segments.
Justification: replaces proposal 22
Minneapolis Discussion
Motion: O/O TC is in support of the direction of the proposal. Requests that focus group to continue activities to resolve identified outstanding issues with goal of having proposal ready for final vote in September 2001 for inclusion in HL7 2.5.
Against: 0, Abstain: 1, In Favor: 9
Proposal Language
Issues:
See below (highlighted in yellow).
• RPT Data Type Proposal is a work in progress. This proposal is dependent upon the RPT data type being adopted.
• Do we still want to add new values to the Priority Code Table (See TQ1-9).
• Need to assign a data type for TQ2-10 (Special service request relationship).
• Need to incorporate examples of usage.
Suggested Solution:
General Segments
TQ1 – Timing/Quantity Segment
The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority, and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of an service request over time.
Use cases showing when TQ1 may need to repeat:
❑ Cardiac enzymes STAT and then q 4 hours
❑ Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat
❑ Gentamicin 100mg Now and 80mg q12h second dose ( First 80mg dose) given exactly 12 hours after the 100mg dose. (Might be 2 service requests)
❑ Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be 2 service requests)
❑ Imodium 4mg (2 caps) po initially, then 2mg (1cap) after each unformed stool to a maximum of 16 mg per day. (Might be 2 service requests)
❑ Zithromax 500mg (2tabs) PO on the first day then 250mg (1tab) po qd for 5 days. (Might be 2 service requests)
❑ Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks.
❑ Colchicine 1mg (2 tabs) po now then 1 tablet q1 to 2 hours until pain relief or undesirable side effects (Diarrhea, GI upset) (Might be 2 service requests)
❑ doxycylcine 100mg po bid on the first day then 100mg po qd.
❑ scopolamine, xxx mg, 1 hour before surgery. Relative time = -1^hour, priority = P (preop). or alternately repeat pattern = P1H^Preop, 1 Hour before Surgery^99LocalCode, Relative time would be empty and priority would be P (preop).
HL7 Attribute Table - TQ1
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |4 |SI |O |N | | |Set ID - TQ1 |
|2 |20 |CQ |O |N | | |Quantity |
|3 |540 |RPT |O |Y | | |Repeat Pattern |
|4 |20 |TM |O |Y | | |Explicit Time |
|5 |20 |CQ |O |Y | | |Relative Time and units |
|6 |20 |CQ |O |N | | |Duration |
|7 |26 |TS |O |N | | |Start date/time |
|8 |26 |TS |O |N | | |End date/time |
|9 |250 |CWE |R |Y | | |Priority |
|10 |250 |ST |O |N | | |Condition text |
|11 |250 |TX |O |N | | |Text instruction |
|12 |10 |ID |C |N | | |Conjunction |
|13 |20 |CQ |O |N | | |Occurrence duration |
|14 |10 |NM |O |N | | |Total occurrence's |
TQ1 field definitions
Set ID - TQ1
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
Quantity (CQ)
Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1.
If multiple identical services are to be requested, it is strongly recommended that multiple service requests be placed, giving each service request it’s own unique placer/filler number.
Repeat pattern (RPT) (See RPT data type proposal)
Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems.
This field may be repeated to build up more complex repeat patterns. When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, TQ1-12 determines if the next TQ1 segment is to be performed sequentially or in parallel.
Note: The following table defines possible ranges of coded values for this field. The table is not intended to imply that these codes are to be parsed to derive the meaning of the code.
User-defined Table 0335 - Repeat pattern Associate field with the data type, not field.
|Value |Description |Comment |
|QS |every seconds | |
|QM |every minutes | |
|QH |every hours | |
|QD |every days | |
|QW |every weeks | |
|QL |every months (Lunar cycle) | |
|QJ |repeats on a particular day of the week, from the French | |
| |jour (day). If is missing, the repeat rate is | |
| |assumed to be 1. Day numbers are counted from 1=Monday | |
| |to 7=Sunday. So Q2J2 means every second Tuesday; Q1J6 | |
| |means every Saturday. | |
|BID |twice a day at institution-specified times (e.g., |Note: None of the above three specifications are|
| |9AM-4PM) |equivalent to their QH counterpart. QID|
| | |is not Q6H. The former is unequally spaced; the |
| | |latter is equally spaced. |
|TID |three times a day at institution-specified times (e.g., | |
| |9AM-4PM-9PM) | |
|QID |four times a day at institution-specified times (e.g., | |
| |9AM-11AM-4PM-9PM) | |
|XID |“X” times per day at institution-specified times, where X| |
| |is a numeral 5 or greater. E.g., 5ID=five times per day;| |
| |8ID=8 times per day | |
| | |
|QAM |in the morning at institution-specified time | |
|QSHIFT |during each of three eight-hour shifts at | |
| |institution-specified times | |
|QOD |every other day (same as Q2D) | |
|QHS |every day before the hour of sleep | |
|QPM |in the evening at institution-specified time | |
|C |service is provided continuously between start time and | |
| |stop time | |
|U |for future use, where is an interval specification| |
| |as defined by the UNIX cron specification. | |
|PRN |given as needed | |
|PRNxxx |where xxx is some frequency code (e.g., PRNQ6H); given as| |
| |needed over the frequency period. | |
|Once |one time only. This is also the default when this field | |
| |is null. | |
|Meal Related Timings |C (“cum”) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|A |Ante (before) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|P |Post (after) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|I |Inter (e.g., between this meal and the next, between |Deprecated in v 2.5; retained for backward |
| |dinner and sleep |compatibility only. |
|M |Cibus Matutinus (breakfast) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|D |Cibus Diurnus (lunch) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|V |Cibus Vespertinus (dinner) |Deprecated in v 2.5; retained for backward |
| | |compatibility only. |
|AC |before meal (from lat. ante cibus) | |
|PC |after meal (from lat. post cibus) | |
|IC |between meals (from lat. inter cibus) | |
|ACM |before breakfast (from lat. ante cibus matutinus) | |
|ACD |before lunch (from lat. ante cibus diurnus) | |
|ACV |before dinner (from lat. ante cibus vespertinus) | |
|PCM |after breakfast (from lat. post cibus matutinus) | |
|PCD |after lunch (from lat. post cibus diurnus) | |
|PCV |after dinner (from lat. post cibus vespertinus) | |
|ICM |between breakfast and lunch | |
|ICD |between lunch and dinner | |
|ICV |between dinner and the hour of sleep | |
Explicit time (TM)
Definition: This field explicitly lists the actual times referenced by the code in TQ1-3. This field will be used to clarify the TQ1-3 in cases where the actual administration times vary within an institution. If the time of the service request spans more than a single day, this field is only practical if the same times of administration occur for each day of the service request. If the actual start time of the service request (as given by TQ1-7 ) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing service request may be updated with a new quantity/timing segment showing the changed explicit times.
Usage Note: This field is not valued if a Repeat Pattern is not present.
Relative time and units (CQ)
Components: ^
Note: In future versions, CQ fields should be avoided because the same data can usually be sent as two separate fields, one with the value and one with the units as a CE data type.
Definition: This field is used to define the interval between schedules for service request or bottle records. If this field contains a value, it overrides any value in the explicit time interval field. The units component of the CQ data type is constrained to units of time.
Examples:
Q6H||60^M
Q6H||6^H
QD||1^D
Duration (CQ)
Definition: This field contains the duration for which the service is requested.
The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.
Start date/time (TS)
Definition: This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be empty.
The filling service will often record a value in this field after receipt of the service request, however, and compute an end time on the basis of the start date/time for the filling service’s internal use.
End date/time (TS)
Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.
Priority (CWE):
Definition: This field describes the urgency of the request. If this field is blank, the default is R. The following values are suggested. The following User defined table may be used for this field.
User Defined Table ??? - Priority
|Value | | |
|S |Stat |With highest priority |
|A |ASAP |Fill after S orders |
|R |Routine |Default |
|P |Preop | |
|C |Callback | |
|T |Timing |A request implying that it is critical to come as close as possible to the|
| |critical |requested time, e.g., for a trough antimicrobial level. |
|TS | |Timing critical within seconds. |
|TM | |Timing critical within minutes. |
|TH | |Timing critical within hours. |
|TD | |Timing critical within days. |
|TW | |Timing critical within weeks. |
|TL | |Timing critical within months. |
|PRN |As needed | |
Additional Priority Values under investigation
|Value |Description |
| |Today |
| |Timed |
| |Draw Routine, Run Stat |
| |Draw Timed, Run Stat |
| |Stat - OR |
| |Stat - Recovery Room |
| |Stat - Emergency Room |
| |Stat - ICU |
| |Expedite |
| |Timed Study |
| |AM Draw |
| |Routine, In-Patient |
| |Routine, Out-Patient |
| |Stat, Medical Emergency |
| |Stat, NOT Medical Emergency |
Condition text (ST)
Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, PRN pain, or to keep blood pressure below 110.
The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.
For complex codified conditions see the TQ2 segment below.
Text Instruction (ST)
Definition: This field is a full text version of the instruction (optional).
Conjunction (ID):
Definition: This field indicates that a second TQ1 segment is to follow. This field can take values from HL7 table 0472.
HL7 Defined Table 0472
|Value |Description |
|S |Synchronous - Do the next specification after this one (unless otherwise constrained by the following |
| |fields: TQ1-7-start date/time and TQ1-8-end date/time). An “S” specification implies that the second |
| |timing sequence follows the first, e.g., when an service request is written to measure blood pressure Q15|
| |minutes for the 1st hour, then every 2 hours for the next day. |
|A |Asynchronous - Do the next specification in parallel with this one (unless otherwise constrained by the |
| |following fields: TQ1-7-start date/time and TQ1-8-end date/time). The conjunction of “A” specifies two |
| |parallel instructions, as are sometimes used in medication, e.g., prednisone given at 1 tab on Monday, |
| |Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday. |
|C |Actuation Time - It will be followed by a completion time for the service. This code allows one to |
| |distinguish between the time and priority at which a service should be actuated (e.g., blood should be |
| |drawn) and the time and priority at which a service should be completed (e.g., results should be |
| |reported). |
For continuous or periodic services, the point at which the service is actually stopped is determined by the field TQ1-8 end date/time and TQ1-6 duration, whichever indicates an earlier stopping time. Ordinarily, only one of these fields would be present.
Condition Rule: If the TQ1 segment is repeated in the message, this field must be populated with the appropriate Conjunction code indicating the sequencing of the following TQ1 segment.
Occurrence duration (CQ)
Definition: This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a non-negative integer when populated. The units component is constrained to be units of time.
Example: Whirlpool twenty minutes three times per day for three days. Twenty minutes is the occurrence duration.
Total occurrences (NM)
Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.
TQ2 – Timing/Quantity Relationship
The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with, and other service requests. The TQ2 segment will link the current service request with one or more other service requests.
There are many situations, such as the creation of an service request for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle.
There are other situations where part of the service request’s instructions contains a results condition of some type, such as “PRN pain.” There is currently a free text “condition” field of TQ1-10 (Condition text) which allows any condition to be specified. However, to support a fully encoded version of service request sequencing, or results condition, the TQ2, Timing/Quantity Relationship segment has been defined.
HL7 Attribute Table - TQ2
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |4 |SI |O |N | | |Set ID - TQ2 |
|2 |1 |ID |O |N |??? | |Sequence/Results Flag |
|3 |22 |EI |C |Y | | |Related Placer number |
|4 |22 |EI |C |Y | | |Related Filler number |
|5 |22 |EI |C |Y | | |Related Placer group number |
|6 |2 |ID |C |N |??? | |Sequence condition code |
|7 |1 |ID |C |N |??? | |Cyclic Entry/Exit Indicator |
|8 |20 |CQ |O |N | | |Sequence condition time interval |
|9 |10 |NM |O |N | | |Cyclic group maximum number of repeats |
|10 |1 |??? |C |N | | |Special service request relationship |
TQ2 Usage notes
a) Cyclic placer service request groups
To implement a cyclic group of four IV service requests using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs:
• TQ2 of the second child service request specifies that it follows the first child service request.
• TQ2 of the third child service request specifies that it follows the second child service request.
• TQ2 of the fourth child service request specifies that it follows the third service request.
To repeat the group of four child service requests in a cyclic manner, the following occurs:
• TQ2 of the first child service request specifies that it is to be executed once without any dependence on the completion of other service requests. Its second execution follows the completion of the fourth service request. See example in Section 4.15.2, “RXO segment field examples.
This scheme allows the following to be tracked:
• The status of the whole group of service requests to be reported back at the level of the parent service request.
• The status for each individual IV service request by following the status of the corresponding child service request.
Separate Service requests example:
• The same group of service requests can be sent as a group of four service requests (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the service request status of the group as a whole without transmitting the status of each of the four separate service requests.
b) Inheritance of service request status
Cancellation/discontinuation/hold service request control events:
• This logic implies the normal execution of the referenced predecessor service request. Thus a cancel (or discontinuation or hold) of a predecessor service request implies the cancellation (or discontinuation or hold) of all subsequent service requests in the chain.
• If the referenced service request has been canceled (or discontinued or held), the current service request inherits that same status.
• In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given service request (which can then be executed according to the specification in the TQ2 segment).
TQ2 field definitions
Set ID – TQ2 (SI)
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on.
Sequence/Results Flag (ID)
Definition: This flag defines the sequencing relationship between the current service request, and the related service request(s) specified in this TQ2 segment. See HL7 table ??? for values. If not value is present, the S - Sequential is the default value.
HL7 defined table ???
|Value |Description |
|S |Sequential |
|C |Cyclical - The C will be used for indicating a repeating cycle of service |
| |requests; for example, individual intravenous solutions used in a cyclical |
| |sequence (a.k.a. “Alternating IVs”). This value would be compatible with |
| |linking separate service requests or with having all cyclical service |
| |request components in a single service request. Likewise, the value would be|
| |compatible with either Parent-Child messages or a single service request |
| |message to communicate the service requests’ sequencing. |
|R |Reserved for future use |
Related Placer number (EI)
Definition: The placer numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Placer number " from the current service request. For orders, the Placer Order Number from ORC-2 is the appropriate "Placer number". Repeats of this field indicates the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Related Filler number (EI)
Definition: The filler numbers of the service request(s) to which this TQ2 segment links the current service request. This field should be populated with the appropriate "Filler number " from the current service request. For orders, the Filler Order Number from ORC-3 is the appropriate "Filler number". Repeats of this field indicates the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Related Placer group number (EI)
Definition: The placer group numbers of the service request(s) to which this TQ2 segment links the current service request. . This field should be populated with the appropriate "Placer group number " from the current service request. For orders, the Placer Group Number from ORC-4 is the appropriate "Placer group number". Repeats of this field indicates that the current service request is related to multiple groups of service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
Sequence Condition Code(ID)
Definition: Defines the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4, or TQ2-5) and the current service request from ORC-2,3 or 4. See HL7 defined table ??? for allowed values.
Conditional Rule: Either this field or TQ2-??? must be present.
HL7 defined table ????
|Value |Description |
|EE |End related service request(s), end current service request. |
|ES |End related service request(s), start current service request. |
|SS |Start related service request(s), start current service request. |
|SE |Start related service request(s), end current service request. |
Cyclic Entry/Exit Indicator (ID)
Definition: Indicates if this service request is the first, last, service request in a cyclic series of service requests. If null or not present, this field indicates that the current service request is neither the first or last service request in a cyclic series of service requests.
Usage note: Should not be populated when TQ2-2 () is not equal to a 'C' (cyclic service request).
HL7 defined table ????
|Value |Description |
|* |The first service request in a cyclic group |
|# |The last service request in a cyclic group. |
Example of TQ2 - 6, 7, & 8 Usage:
|...|ES|*|+10^min|... |Translates to: execute this service request the first time without evaluating the |
| |condition specified in the TQ2 segment; but repeat only its execution when the specified |
| |external service request’s start or finish date/time has met this condition. This |
| |specification generates a repetition of the service request for each iteration of the |
| |cycle. |
Note: This requires that the requesting application be able to specify the placer/filler/placer group number of the last service request in the cycle in the first service request’s quantity/timing specification.
Sequence condition time interval (CQ)
Definition: Defines the interval of time between the start/end of the related service request(s) and the start/end of the current service request. The unit's component is constrained to units of time. If this field is not populated, then there should be no interruption between start/ending the current service request, and the related service request(s).
Cyclic group maximum number of repeats (NM)
Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.
Special service request relationship (ID/IS/CE/CWE?)
Definition: This defines an additional or alternate relationship between this service request and other service requests. It's primary intended use for Pharmacy administration service requests, but it may be useful for other domains. See HL7 Table ?? for allowed values.
Conditional Rule: Either this field or TQ2-6 must be present.
HL7 defined table ???
|Value |Description |
|N |Nurse prerogative - RN Prerogative order. I've seen it ordered so that the nurse can |
| |chose between 3 or 4 different items, depending on which the patient can tolerate at |
| |the moment. Another example would be:Milk of Magnesia PO 30 ml qhs (at |
| |bedtime)/Dulcolax Supp R @ hs prn /Colace 100 mg capsule PO bid |
| |The nurse may be giving the Colace twice daily as a stool softener, but may also give |
| |the Dulcolax Supp along with it if Colace is not producing any "results". For example |
| |give order 1 and order 2 or order 3. This can be extended to more than three orders. |
| |The old TQ did not handle this many to many scenario. |
|C |Compound - A compound is an extempo order which may be made up of multiple drugs. For |
| |example, many hospitals have a standard item called "Magic Mouthwash". The item is |
| |ordered that way by the physician. The extempo items will contain multiple products, |
| |such as Maalox, Benadryl, Xylocaine, etc. They will all be mixed together and will be |
| |dispensed in a single container. |
|T |Tapering - A tapering order is one in which the same drug is used, but it has a |
| |declining dosage over a number of days. |
| |For example, Decadron 0.5 mg is often ordered this way. The order would look like |
| |this: |
| |Decadron 0.5 mg qid (four times a day) for 2 days, then |
| |Decadron 0.5 mg tid (three times a day) for 2 days, then |
| |Decadron 0.5 mg bid (twice a day) for 2 days, then |
| |Decadron 0.5 mg qd (daily) for 2 days, then stop. |
|E |Exclusive - An exclusive order is an order where only one of the multiple items should |
| |be administered at any one dosage time. The nurse may chose between the alternatives, |
| |but should only give ONE of them. An example would be: Phenergan 25 mg PO, IM or R q6h|
| |prn (orally, intramuscularly, or rectally every 6 hours as needed). |
|S |Simultaneous - A simultaneous order is 2 or more drugs which are ordered to be given at|
| |the same time. A common example of this would be Demerol and Phenergan (Phenergan is |
| |given with the Demerol to control the nausea that Demerol can cause). The order could |
| |be:Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed). |
General segments
ORC - common order segment
ORC-7 Quantity/timing (TQ) 00221
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.4.4 and 4.4.5 respectively.
OBR - observation request segment
OBR-27 – Quantity/timing:
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.4.4 and 4.4.5 respectively.
Usage of the TQ1/TQ2
TQ1 and TQ2 would form a repeating segment group within a message. The group would be in the form:
[{ TQ1 [{ TQ2 }] }]
Chapter 4 Messages
|OMG^O19^OMG_O19 |General Clinical Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit- Additional Info |3 |
| ] | | |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
| { | | |
| ORC |Common Order |4 |
| [{ |Start Timing/Quantity Group | |
| TQ1 |Timing/Quantity |4 |
| [{TQ2}] |Timing/Quantity Order Sequence |4 |
| }] |End Timing/Quantity Group | |
| OBR |Observation |4 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [CTD] |Contact Data |11 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| {[ | | |
| [PID |Patient Identification – previous result |3 |
| [PD1]] |Additional Demographics – previous result |3 |
| [PV1 |Patient Visit – previous result |3 |
| [PV2]] |Patient Visit Add. Info – previous result |3 |
| [AL1] |Allergy Information - previous result |3 |
| { | | |
| [ORC] |Common Order - previous result |4 |
| OBR |Order Detail - previous result |4 |
| [{ |Start Timing/Quantity Group | |
| TQ1 |Timing/Quantity |4 |
| [{TQ2}] |Timing/Quantity Order Sequence |4 |
| }] |End Timing/Quantity Group | |
| {[NTE]} |Notes and Comments - previous result |2 |
| [CTD] |Contact Data - previous result |10 |
| { | | |
| OBX |Observation/Result - previous result |7 |
| [{NTE}] |Notes and Comments - previous result |2 |
| } | | |
| } | | |
| }] | | |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| } | | |
OSR^Q06 Order Status Response Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
QRD Query Definition 2
[QRF] Query Filter 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[Order Detail Segment] OBR, etc. 4
[{NTE}] Notes and Comments (for Detail) 2
[{CTI}] Clinical Trial Identification 7
}
]
[DSC] Continuation Pointer 2
ORG^O20^ORG_O20 General Clinical Order Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[OBR] Observation 4
[{NTE}] Notes and Comments (for Detail) 2
[{CTI}] Clinical Trial Identification 7
}
]
OML^O21^OML_O21 Laboratory Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[PV1 Patient Visit 3
[PV2]] Patient Visit- Additional Info 3
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
[
SAC Specimen Container Details 13
[{OBX}] Additional Specimen Characteristics 7
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
OBR Observation Request 4
[{
SAC Specimen Container Details 13
[{OBX}] Additional Specimen Characteristics 7
}]
[TCD] Test Code Details 13
[{NTE}] Notes and Comments (for Detail) 2
[{DG1}] Diagnosis 6
[{
OBX Observation/Result 7
[TCD] Test Code Detail 13
[{NTE}] Notes and Comments (for Results) 2
}]
[{
[PID Patient Identification – previous result 3
[PD1]] Additional Demographics – previous result 3
[PV1 Patient Visit – previous result 3
[PV2]] Patient Visit Add. Info – previous result 3
[{AL1}] Allergy Information - previous result 3
{
[ORC] Common Order - previous result 4
OBR Order Detail - previous result 4
[{ TQ1 [{ TQ2 }] }]
{[NTE]} Notes and Comments - previous result 2
{
OBX Observation/Result - previous result 7
[{NTE}] Notes and Comments - previous result 2
}
}
}]
]
[{FT1}] Financial Transaction 6
[{CTI}] Clinical Trial Identification 7
[BLG] Billing Segment 4
}
]
ORL^O22^ORL_O22 General Laboratory Order Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
{
[SAC Specimen Container Details 13
[{OBX}] Additional Specimen Characteristics 7
]
[{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[OBR Observation Request 4
[{SAC}] Specimen Container Details 13
]
}]
}
]
]
OMD^O03^OMD_O03 Dietary Order Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[
PV1 Patient Visit 3
[PV2] Patient Visit - Additional Info 3
]
[{
IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
ORC Common Order Segment 4
[{ TQ1 [{ TQ2 }] }]
[
{ODS} Dietary Orders, Suppl., Prefer. 4
[{NTE}] Notes and Comments (for ODS) 2
[{
OBX Results 7
[{NTE}] Notes and Comments (for OBX) 2
}]
]
}
{
[
ORC Common Order Segment 4
[{ TQ1 [{ TQ2 }] }]
{ODT} Diet Tray Instructions 4
[{NTE}] Notes and Comments (for ODT) 2
]
}
ORD^O04^ORD_O04 Dietary Order Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for MSA) 2
[
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[{ODS}] Dietary Orders, Supplements, and Preferences 4
[{NTE}] Notes and Comments (for ODS) 2
}
[{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[{ODT}] Diet Tray Instructions 4
[{NTE}] Notes and Comments (for ODT) 2
]}
]
OMS^O05^OMS_O05 Stock Requisition Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
RQD Requisition Detail 4
[RQ1] Requisition Detail-1 4
[{NTE}] Notes and Comments (for RQD) 2
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
[BLG] Billing Segment 4
}
OMN^O07^OMN_O07 Nonstock Requisition Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
RQD Requisition Detail 4
[RQ1] Requisition Detail-1 4
[{NTE}] Notes and Comments (for RQD) 2
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
[BLG] Billing Segment 4
}
ORN^O08^ORN_O08 General Order Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
RQD Requisition Detail 4
[RQ1] Requisition Detail-1 4
[{NTE}] Notes and Comments (for RQD) 2
}
]
OMP^O09^OMP_O09 Pharmacy/treatment Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
RXO Pharmacy/Treatment Order 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[
{RXC} Pharmacy/Treatment Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
[
{
OBX Observation/Result 7
[{NTE}] Notes and Comments (for OBX) 2
}
]
[{FT1}] Financial Transaction 6
[BLG] Billing Segment 6
}
ORP^O10^ORP_O10 Description Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Response Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[
RXO Pharmacy/Treatment Order 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
}
]
RDE^O11^RDE_O11 Pharmacy/Treatment Encoded Order Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{IN1 Insurance
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[GT1] Guarantor 6
[{AL1}] Allergy Information 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXO Pharmacy/Treatment Prescription Order 4
[{NTE}] Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[
{RXC} Pharmacy/Treatment Component (for RXO) 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
RXE Pharmacy/Treatment Encoded Order 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component (for RXE) 4
[{
OBX Results 7
[{NTE}] Notes and Comments (for OBX) 2
}]
{[CTI]} Clinical Trial Identification 7
}
RRE^O12^RRE_O12 Pharmacy/Treatment Encoded Order Acknowledgment
Message
Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXE Pharmacy/Treatment Encoded Order 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
}
]
RDS^O13^RDS_O13 Pharmacy/Treatment Dispense Message Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy Information 2
[
PV1 Patient Visit 3
[PV2] Patient Visit - Additional Info 3
]
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXO Pharmacy /Treatment Order 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[
{RXC} Pharmacy/Treatment Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy/Treatment Encoded Order 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
RXD Pharmacy/Treatment Dispense 4
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
[{
OBX Results 7
[{NTE}] Notes and Comments (for OBX) 2
}]
[{FT1}] Financial Transaction segment 6
}
RRD^O14^RRD_O14 Pharmacy/Treatment Dispense Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXD Pharmacy/Treatment Dispense 4
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
}
]
RGV^O15^RGV_O15 Pharmacy/Treatment Give Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy Information 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXO Pharmacy /Treatment Order 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[
{RXC} Pharmacy/Treatment Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy/Treatment Encoded Order 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
{
RXG Pharmacy/Treatment Give 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
{
[OBX] Observation/Results 7
[{NTE}] Notes and Comments (for OBX) 2
}
}
}
RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgment Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for PID) 2
{
ORC Common Order 4
[
RXG Pharmacy/Treatment Give 4
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
}
]
RAS^O17^RAS_O17 Pharmacy/Treatment Administration Chapter
MSH Message Header 2
[{NTE}] Notes and Comments (for Header) 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for PID) 2
[{AL1}] Allergy Information 2
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
]
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
RXO Pharmacy /Treatment Order 4
[
{NTE} Notes and Comments (for RXO) 2
{RXR} Pharmacy/Treatment Route 4
[
{RXC} Pharmacy/Treatment Component 4
[{NTE}] Notes and Comments (for RXC) 2
]
]
]
[
RXE Pharmacy/Treatment Encoded Order 4
[{ TQ1 [{ TQ2 }] }]
{RXR} Pharmacy/Treatment Route 4
[{RXC}] Pharmacy/Treatment Component 4
]
{{RXA} Pharmacy/Treatment Administration 4
RXR Pharmacy/Treatment Route 4
{[OBX Observation/Result 7
{[NTE]} Notes and Comments (for OBX) 2
]}}
{[CTI]} Clinical Trial Identification 7
}
RRA^O18^RRA_O18 Pharmacy/Treatment Administration Acknowledgment
Message
Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
[ERR] Error 2
[{NTE}] Notes and Comments (for Header) 2
[
[PID Patient Identification 3
[{NTE}]] Notes and Comments (for PID) 2
{
ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
[
{RXA} Pharmacy/Treatment Administration 4
RXR Pharmacy/Treatment Route 4
]
}
]
VXR^V03 Vaccination Response Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
QRD Query Definition 2
[QRF] Query Filter 2
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NK1}] Next of Kin/Associated Parties 3
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{GT1}] Guarantor 6
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[{
[ORC] Common Order 4
[{ TQ1 [{ TQ2 }] }]
RXA Pharmacy Administration 4
[RXR] Pharmacy Route 4
[{OBX Observation/Result 7
[{NTE}] Notes (Regarding Immunization) 2
}]
}]
VXU^V04 Unsolicited Vaccination Update Chapter
MSH Message Header Segment 2
PID Patient Identification Segment 3
[PD1] Additional Demographics 3
[{NK1}] Next of Kin/Associated Parties 3
[PV1 Patient Visit 3
[PV2]] Patient Visit - Additional Info 3
[{GT1}] Guarantor 6
[{IN1 Insurance 6
[IN2] Insurance Additional Info 6
[IN3] Insurance Add’l Info - Cert. 6
}]
[{
[ORC] Common Order Segment 4
[{ TQ1 [{ TQ2 }] }]
RXA Pharmacy Administration Segment 4
[RXR] Pharmacy Route 4
{[ OBX Observation/Result 7
[{NTE}] Notes (Regarding Immunization) 2
]}
}]
Chapter 7 Messages
ORU^R01 Unsolicited Observation Message Chapter
MSH Message Header 2
{
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NK1}] Next of Kin/Associated Parties 3
[{NTE}] Notes and Comments 2
[
PV1 Patient Visit 3
[PV2] Patient Visit - Additional Info 3
]
]
{
[ORC] Order common 4
OBR Observations Report ID 7
{[NTE]} Notes and comments 2
[{ TQ1 [{ TQ2 }] }]
[CTD] Contact Data 11
{
[OBX] Observation/Result 7
{[NTE]} Notes and comments 2
}
[{FT1}] Financial Transaction 6
{[CTI]} Clinical Trial Identification 7
}
}
[DSC] Continuation Pointer 2
OUL^R21^OUL_R21 Unsolicited Laboratory Observation Message Chapter
MSH Message Header 2
[NTE] Notes and Comments 2
[
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and Comments (for Patient ID) 2
]
[
PV1 Patient Visit 3
[PV2]] Patient Visit – Additional Information 3
]
{
[
SAC Specimen Container Details 13
[SID] Substance Identifier 13
[{OBX}] Additional Specimen Characteristics 7
]
[ORC] Common Order 4
OBR Observation 7
[{NTE}] Notes and Comments (for Detail) 2
[{ TQ1 [{ TQ2 }] }]
{
[OBX] Observation Result 7
[TCD] Test Code Detail 13
{[SID]} Substance Identifier 13
[{NTE}] Notes and Comments 2
}
[{CTI}] Clinical Trial Identification 7
}
[DSC] Continuation Pointer 2
CSU^C09-C12^CSU_C09 Unsolicited Study Data Message Chapter
MSH Message Header 2
MSA Message Acknowledgment 2
QRD Query Definition 2
[QRF] Query Filter 2
{
[
PID Patient ID 3
[{NTE}] Notes and Comments 3
]
{
[ORC] Order common
OBR Observation request 7
{[NTE]} Notes and comments 2
[CTD] Contact Data 11
{
[OBX] Observation/Result 7
{[NTE]} Notes and comments 2
}
{[CTI]} Clinical Trial Identification 7
}
}
[ERR] Error 2
[QAK] Query Acknowledgement 5
[DSC] Continuation Pointer 2
CSU^C09-C12^CSU_C09 Unsolicited Study Data Message Chapter
MSH Message Header 2
{ PID repeat group open
PID Patient Identification 3
[PD1] Additional Demographics 3
[{NTE}] Notes and comments 2
[ PV1 optional group open
PV1 Patient Visit 3
[PV2] Patient Visit - Additional Info 3
] PV1 optional group close
CSR Clinical Study Registration 7
{ CSP repeat group open
[CSP] Clinical Study Phase 7
{ CSS repeat group open
[CSS] Clinical Study Data Schedule 7
{ ORC repeat group open
[ORC] Common Order 4
OBR Observation Battery 7
[{ TQ1 [{ TQ2 }] }]
{OBX} Observation Results 7
} ORC repeat group close
{ ORC repeat group open
[ORC Common Order 4
[{ TQ1 [{ TQ2 }] }]
]
{ RXA repeat group open
RXA Pharmacy Administration 4
RXR Pharmacy Route 4
} RXA repeat group close
} ORC repeat group close
} CSS repeat group close
} CSP repeat group close
} PID repeat group close
Repeat Pattern Issues
• Do we want to include GTS examples or just point to the version 3.0 GTS examples.
• De we want to include parts of the UCUM document in this proposal?
Proposed Solution
The repeat pattern data type should be used where it is necessary to define the frequency at which an event is to take place. This data type provides a way to define repeat pattern codes "on the fly". The repeat pattern code is equivalent to the TQ data type, component 2, sub-component 1 (repeat pattern). The additional components define the meaning of the repeat pattern code. Components 2 - 10 are used to define relatively simple repeat patterns. Component 11 is provided to define complex repeat patterns. This data type forms a bridge between the 2.x Repeat Pattern concept from Quantity/Timing, and the Version 3.0 GTS General Timing Specification. Component 1 is the 2.x concept of repeat pattern. Components 2-7 are derived from the version 3.0 data type PIVL. Components 8-10 are derived from the version 3.0 EIVL data type. If a repeat pattern cannot be defined using components 2-10, then component 11, General Timing Specification is provided. This allows the full literal form of the version 3.0 GTS to be specified.
When using the RPT, if an application doesn't recognize the code in component 1, then it may attempt to determine the appropriate frequency using the remaining components. If the application does recognize the code in component 1, the application is not required to determine the frequency from the remaining components.
|# |Name |Data Type |Len |Opt |HL7 Table |Description |
|1 |Repeat Pattern Code|CWE |250 |R |0335 |A code representing the repeat pattern defined by the |
| | | | | | |other components of this data type. |
|2 |Calendar Alignment |ID |2 |O |xxx |Specifies an alignment of the repetition to a calendar |
| | | | | | |(e.g., to distinguish every 30 days from “the 5th of |
| | | | | | |every month”.) Values are drawn from HL7 table xxx, |
| | | | | | |Calendar Periods for Alignment. |
|3 |Phase Range Begin |NM |10 |O | |Used for Calendar aligned repeat patterns to determine |
| |Value | | | | |the amount of time from the beginning of particular |
| | | | | | |RPT-2 (Calendar Alignment) to the beginning of the |
| | | | | | |phase. If Calendar Alignment is DW (days of week), |
| | | | | | |then this would be the offset from the beginning of the|
| | | | | | |week. |
| | | | | | |If Phase Range Begin Value is populated, but Phase |
| | | | | | |Range End Value is not populated, then this component |
| | | | | | |defines when the period (RPT-5, 6) begins. |
| | | | | | |If both Phase Range Begin Value and Phase Range End |
| | | | | | |Value are populated, then this component defines the |
| | | | | | |earliest point in time at which the period (RPT-5, 6) |
| | | | | | |will begin. |
| | | | | | |The units of measure for this component are derived |
| | | | | | |from the Calendar Alignment value in RPT-2. See Table |
| | | | | | |xxx for the units of measure associated with a |
| | | | | | |particular calendar alignment. |
|4 |Phase Range End |NM |10 |O | |Used for Calendar aligned repeat patterns to determine |
| |Value | | | | |the amount of time from the beginning of particular |
| | | | | | |RPT-2 (Calendar Alignment) to the end of the phase. |
| | | | | | |If Phase Range End Value is populated, but Phase Range |
| | | | | | |Begin Value is not populated, then this component |
| | | | | | |defines when the timing period (RPT-5, 6) begins. |
| | | | | | |If both Phase Range Begin Value and Phase Range End |
| | | | | | |Value are populated, then this component defines the |
| | | | | | |latest point in time at which the period (RPT-5, 6) |
| | | | | | |will begin. |
| | | | | | |The units of measure for this component are derived |
| | | | | | |from the Calendar Alignment value in RPT-2. See Table |
| | | | | | |xxx for the units of measure associated with a |
| | | | | | |particular calendar alignment. |
|5 |Period Quantity |NM |10 |O | |A time duration specifying the frequency at which the |
| | | | | | |periodic interval repeats. RPT-6 (Period Units) defines|
| | | | | | |the units of time for this component. |
|6 |Period Units |IS |10 |C | |Defines the units used for RPT-5 (Period Quantity). |
| | | | | | |Constrained to units of time. The codes for unit of |
| | | | | | |measure are specified in the Unified Code for Units of |
| | | | | | |Measure (UCUM) []. |
| | | | | | |Condition Rule: This component is required if RPT-5 |
| | | | | | |(Period Quantity) is populated. |
|7 |Institution |ID |1 |O |136 |Indicates whether the exact timing is up to the party |
| |Specified Time | | | | |executing the schedule (e.g., to distinguish “every 8 |
| | | | | | |hours” from “3 times a day”.) Y - exact timing up to |
| | | | | | |party executing schedule. N - exact timing as |
| | | | | | |specified. |
|8 |Event |ID |6 |O |yyy |A code for a common (periodical) activity of daily |
| | | | | | |living. Values are drawn from HL7 Table yyy, Event |
| | | | | | |Codes for Event-Related Periods. |
|9 |Event Offset |NM |10 |O | |An interval that marks the offsets for the beginning, |
| |Quantity | | | | |width and end of the event-related periodic interval |
| | | | | | |measured from the time each such event actually |
| | | | | | |occurred. A positive numeric value indicates the amount|
| | | | | | |of time after the event in RPT-8. A negative numeric |
| | | | | | |value indicates the amount of time prior to the event |
| | | | | | |in RPT-8. RPT-10 (Event Offset Units) defines the units|
| | | | | | |of time for this component. |
| | | | | | |Usage Note: This component should not be valued unless |
| | | | | | |there is a value in RPT-8 (Event). |
|10 |Event Offset Units |IS |10 |C | |Defines the units used for RPT-9 (Event Offset |
| | | | | | |Quantity). Constrained to units of time. The codes for |
| | | | | | |unit of measure are specified in the Unified Code for |
| | | | | | |Units of Measure (UCUM) |
| | | | | | |[]. |
| | | | | | |Condition Rule: This component is required if RPT-9 |
| | | | | | |(Event Offset Quantity) is populated. |
|11 |General Timing |GTS |200 |O | |The General Timing Specification as defined by the |
| |Specification | | | | |Version 3 Data Types document. |
Table xxx: Calendar Periods for Alignment
|Name |Code |Units of time |
|month of the year |MY |mo |
|week of the year |WY |wk |
|day of the month |DM |d |
|day of the year |DY |d |
|day of the week (begins with Monday) |DW |d |
|hour of the day |HD |h |
|minute of the hour |NH |min |
|second of the minute |SN |s |
Note: The Units of Time in table xxx are taken from the Unified Code for Units of Measure (UCUM) [].
Table yyy: Event Codes for Event-Related Periods
|Code |Definition |
|HS |the hour of sleep (e.g., H18-22) |
|AC |before meal (from lat. ante cibus) |
|PC |after meal (from lat. post cibus) |
|IC |between meals (from lat. inter cibus) |
|ACM |before breakfast (from lat. ante cibus matutinus) |
|ACD |before lunch (from lat. ante cibus diurnus) |
|ACV |before dinner (from lat. ante cibus vespertinus) |
|PCM |after breakfast (from lat. post cibus matutinus) |
|PCD |after lunch (from lat. post cibus diurnus) |
|PCV |after dinner (from lat. post cibus vespertinus) |
|ICM |between breakfast and lunch |
|ICD |between lunch and dinner |
|ICV |between dinner and the hour of sleep |
GTS - general timing specification
The General Timing Specification data type is used to communicate complex inter-related information Timing information. The value of such a field follows the formatting rules for a ST field. The string data will be structured according to the rules set forth in the "Version 3 Data Types Part II Unabridged Specification" for the General Timing Specification (GTS) data type.
Examples of RPT data type usage:
|Q1H&Every 1 Hour&HL7xxx^^^^1^h|
|Q2J2&Every second Tuesday&HL7xxx^DW^2^^2^wk|
|BID&Twice a day at institution specified times&HL7xxx^^^^12^h^Y|
|QAM&Every morning at the institution specified time&HL7xxx^HD^00^11^1^d^Y|
|QHS&Every day before the hours of sleep&HL7xxx^^^^1^d^^AHS|
|ACM&Before Breakfast&HL7xxx^^^^^^^ACM|
117 - Reformat Service/Test/Observation Master Trigger Events at Heading 3 level
Submitted By: Scott Robertson – Kaiser Permanente
Section: 8.8.2
Priority: 25
Description: The Master File Notification (MFN) message syntax as defined in chapter 8, section 8.8.2, has 5 trigger events resulting in 5 different message syntaxes. These are hard to locate because they are not formatted at the 8.8.N level. They are simply presented as tables.
Justification: correct version replaces proposal 78
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: unanimous
Proposal Language
8.8.2 MFN/MFK - master file - test/observation
The usage of the OMx segments in the Master Files MFN and MFR messages is described in Sections 8.4.1, "MFN/MFK - master files notification," and 8.4.3, "MFQ/MFR - master files query," above. Basically the segment groupings described below (OM1 and other segment(s)) follow the MFI and MFE segments in those messages (replacing the [...] section).
Note: MFN^M03 is retained for backward compatibility only. It is recommended that the specific master file messages which follow (MFN^M08, MFN^M09, MFN^M10, MFN^M11, and MFN^M12) be used as they apply to new implementations.
|MFN^M03^MFN_M03 |Master File - Test/Observation |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| ... |[other segment(s)] | |
| } | | |
where other segment(s) can be any of the combinations as described below for event codes M08, M09, M10, M11, and M12.
8.8.3 MFN/MFK - test/observation (numeric) master file
|MFN^M08^MFN_M08 |Test/Observation (Numeric) Master File |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM2] |Numeric Observation Segment |8 |
| [OM3] |Categorical Service/Test/Observation Segment |8 |
| [OM4] |Observations that Require Specimens |8 |
| } | | |
Note: MFI-1 - Master file identifier = OMA for numeric observations.
Note: A service/test/observation definition may have both an OM2 (numeric) and OM3 (categorical) segment included in case the value may be either numeric and/or categorical.
8.8.4 MFN/MFK - test/observation (categorical) master file
|MFN^M09^MFN_M09 |Test/Observation (Categorical) Master File |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM3 |Categorical Service/Test/Observation Segment |8 |
| [{OM4}] |Observations that Require Specimens |8 |
| ] | | |
| } | | |
Note: MFI-1 - Master file identifier = OMB for categorical observations.
8.8.5 MFN/MFK - test/observation batteries master file
|MFN^M10^MFN_M10 |Test/Observation Batteries Master File |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM5 |Observation Batteries |8 |
| [{OM4}] |Observations that Require Specimens |8 |
| ] | | |
| } | | |
Note: MFI-1 - Master file identifier = OMC for observation batteries.
8.8.6 MFN/MFK - test/calculated observations master file
|MFN^M11^MFN_M11 |Test/Calculated Observations Master File |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM6 |Observations Calculated from Other Observations |8 |
| OM2] |Numeric Observation Segment |8 |
| } | | |
Note: MFI-1 - Master file identifier = OMD for calculated observations.
8.8.7 MFN/MFK - additional basic observation/service attributes
|MFN^M12^MFN_M12 |Additional Basic Observation/Service Attributes |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM7] |Other Basic Observation/Service Attributes |8 |
| } | | |
Note: MFI-1 - Master file identifier = OME for additional basic observation/service attributes.
NOTE - The addition of the above sections (8.8.3 through 8.8.7) will cause renumbering of existing sections 8.8.3 through 8.8.9.
HL7 and user-defined tables - numeric sort
|Type |Table |Name |Value |Description |
|HL7 | |Event type | | |
| |0003 | |M12 |MFN/MFK - Additional basic observation/service attributes |
118 - Blood Bank Messages
Submitted By: Patti Larson – Health Care Consulting
Section: 4.4
Priority:
Description: The current HL7 standard does not adequately address the following transfusion service related interface issues:
1. blood bank specimen information
2. ordering blood products intended for transfusion to a patient, particularly for a patient with special transfusion requirements.
3. communicating the status of blood products that are made ready for transfusion to a patient by the transfusion service, or have been dispensed or transfused to a patient
Justification: This current blood bank proposal proposal addresses these issues in the following manner: 1) The transmission of specimen information is of great importance to the BB SIG. However, a proposed solution is not included in this current proposal as the BB SIG is investigating the use of the Specimen Source segment, providing the required attributes can be added to that segment. This specimen information should be included in any new messages in this proposal since the availability and status of a blood bank specimen can change at any time. The BB SIG will seek the approval of the Specimen Source committee for the additional specimen attributes. 2) Proposed new Blood Product Order message: OMB a) Proposed new trigger event b) New detail segment containing specific blood-product related attributes: BPO 3) Proposed new Blood Product Dispense status message: BPS a) Proposed new trigger event for the message b) New detail segment containing specific blood-product related attributes: BPX 4) Proposed new blood product transfusion message: BTS a) Proposed new trigger event for the message b) New detail segment containing specific blood-product related attributes: BTX
Time slot 90 Minute discussion in Minneapolis
Minneapolis Discussion
Patti Larson, co-chair Blood Bank SIG, provided an overview of the Blood Bank proposal for new messages, trigger events, and segments for V2.x. Based on the discussion, the following suggestions for enhancements were made:
• Need clarification on use of Notes after BPO. Add use case.
• Description of BP3 contains a different name then the table. The name in the definition
• The BPX name changed to BPU to avoid confusion with OBX structure.
• We agreed to create new table for Blood Product Observation Status. Since only a small list is required, using Observation Status would open the doors and we cannot restrict easily to subset. (V3 should allow drawing from the same superset).
• Prefix of BP for Blood Product is not mandatory. SIG will review whether it is necessary in all cases.
• We agreed to change BP Donation ID data type from ST to EI. Unique identification takes place based on Donation ID and Component.
• We need to expand conditions to describe in which messages the fields are optional/required to narrow down interpretation.
• We suggested to add commercial vs. blood component segment indicator. It is thought to be encapsulated by the universal service identifier.
• Field BPU.12 should be marked as optional since there is never a required situation.
• Field BPU.13 should be marked conditional as there are certain messages where this field must be valued.
• There are concerns with address fields when dealing with Home Health. Need to be addressed.
• Field BPU.19 should be XCN instead of CE.
• We suggested to change the name of BPU.20 to something better.
• Field BPU.21 should be marked as repeat in the attribute table. Description needs to be reviewed for use of hierarchical representation. Normally a repeat does not have significance.
• Generally, look for changing CE to CWE. See Lloyd’s document for guidance.
• BTU.2 may have some cut’n’paste issues. Should be EI.
• There are some questions about BTU.8, Quantity. Not clear when it is something other then 1.
• BTU.18 and BTU.20 are not needed since presence of BTU.19 and BTU.21 respectively would signify this. Also, BTU.19 and BTU.21 could be repeating. Blood Bank will likely change BTU.21 to focus on symptoms, not the reason that is assigned by the Blood Bank department.
• Look into IAM instead of AL1 since it allows for coding.
Motion on acceptance of general direction, recognizing that further adjustments are necessary.
Against: 0, Abstain: 0, In Favor: unanimous
Blood Bank SIG will provide an updated version for the next meeting with the intent to be final for the V2.x ballot. As necessary, review will continue as part of the weekly V2.x conference calls.
Proposal Language
See next pages for the proposal that was reviewed.
Health Level Seven (HL7)
Blood Bank Special Interest Group (BB SIG)
Proposal for Changes:
Blood Product Order Message
Blood Product Dispense Status Message
Blood Product Transfusion Message
Table of Contents
4.1 Document Objective 95
4.2 Message Identification 97
4.3 Blood Bank trigger events and messages 99
4.3.1 Usage notes for blood bank messages 99
4.3.2 OMB – blood product order message (event O26) 99
4.3.3 ORB – blood product order acknowledgment (event O27) 99
4.3.4 BPD – blood product dispense status message (event O28) 99
4.3.5 BRP – blood product dispense status acknowledgment (event O29) 100
4.3.6 BTS – blood product transfusion message (event O30) 100
4.3.7 BRT – blood product transfusion acknowledgment (event O31) 101
4.4 Blood Bank Segments 101
4.4.1 ORC - common order segment 101
4.4.2 BPO – blood product order segment 102
4.4.3 BPX – blood product dispense status segment 105
4.4.4 BTX – blood product transfusion segment 115
Document Objective
This working document is intended to serve as an organized means of communicating all the information gathered through the Blood Bank Special Interest Group (BB SIG). Information presented in this document has originated from BB SIG meeting discussions, conference calls, individual contributions, and previously existing HL7 documents.
Note: The proper name for the laboratory area, which performs pre-transfusion testing for a patient to determine product compatibility, is a transfusion service. The more commonly used name is blood bank blood. However, in the blood bank industry, blood bank usually refers to the blood center where blood donations are made. Throughout this document an attempt has been made to utilize the more appropriate name of transfusion service for the patient-related messaging.
Problem:
The current HL7 standard does not adequately address the following transfusion service related interface issues:
1. The specimen used for testing in a blood bank / transfusion service differs from a routine lab- oratory specimen, as it has an extended expiration date and may be used for multiple orders for the duration of the life of that specimen. This information needs to be communicated between the clinical staff and the transfusion service. Also, labeling of blood specimens must follow very stringent labeling requirements. Mis-labeled, mis-identified and expired specimens cannot be used for testing and this information must also be communicated between the hospital staff and the transfusion service.
2. There is no standard means of ordering blood products intended for transfusion to a patient, particularly for a patient with special transfusion requirements.
3. There is currently no standard means of communicating the status of blood products that are made ready for transfusion to a patient by the transfusion service, or have been dispensed or transfused to a patient.
4. In order for the transfusion service of transfusion service medical staff to perform a prospective review of appropriateness of a blood product order or subsequent transfusion, it is necessary to view the patient's current hematology results of specific tests. This is readily performed when the transfusion service computer system is a module within an LIS. However, stand-alone transfusion service computer systems do not have immediate access to such information and dependent upon receiving this information from the clinician when the order is placed. There is currently no standard means of transmitting this information.
5. Transfusion service testing frequently involves performing tests that are relevant to more than one individual, such as a mother and infant or a potential organ donor and intended recipient. There is currently no way to link the results of testing to the related individual.
This current proposal addresses these issues in the following manner:
1) The transmission of specimen information is of great importance to the BB SIG. However, a proposed solution is not included in this current proposal as the BB SIG is investigating the use of the Specimen Source segment, providing the required attributes can be added to that segment. This specimen information should be included in any new messages in this proposal since the availability and status of a blood bank specimen can change at any time. The BB SIG will seek the approval of the Specimen Source committee for the additional specimen attributes.
2) Proposed new Blood Product Order message: OMB
a) Proposed new trigger event for the message (to be officially assigned by O/O): 26
b) New detail segment containing specific blood-product related attributes: BPO
c) New Acknowledgment message for the blood product order: ORB
d) New trigger event for the acknowledgement (to be officially assigned by O/O): 27
e) Relevant clinical information is included in the OBX segment as needed.
3) Proposed new Blood Product Dispense status message: BPS
a) Proposed new trigger event for the message (to be officially assigned by O/O): 28
b) New detail segment containing specific blood-product related attributes: BPX
c) New Acknowledgment message for the blood product order: BRP
d) New trigger event for the acknowledgement (to be officially assigned by O/O): 29
4) Proposed new blood product transfusion message: BTS
a) Proposed new trigger event for the message (to be officially assigned by O/O): 30
b) New detail segment containing specific blood-product related attributes: BTX
c) New Acknowledgment message for the blood product order: BRT
d) New trigger event for the acknowledgement (to be officially assigned by O/O): 31
The remaining sections of the proposal include the detail descriptions of the messages, segments and message usage.
Patient Related Messages
Message Identification
The following diagram depicts the message flow of the proposed new blood product messages.
Blood Product Order Message from Placer
(Trigger Event O26)
OMB
Acknowledgement from Filler
(Trigger Event O27)
ORB
Modification to order from placer or filler
(Trigger Event O26)
OMB OMB
Acknowledgement from filler or placer
(Trigger Event O27)
ORB ORB
Blood Product Dispense Status Message - Blood Product Ready to Dispense (RD) from filler
(Trigger Event O28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Blood Product Dispense Message - Blood Product Dispensed (DI)
(Trigger Event 28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Stop/Cancel Transfusion
(Trigger Event O32)
BTS
Acknowledgement by filler
(Trigger Event O33)
BRT
Complete Transfusion by placer
(Trigger Event O30)
BTS
Acknowledgement by filler
(Trigger Event O31)
BRT
Blood Bank trigger events and messages
Usage notes for blood bank messages
OMB – blood product order message (event O26)
Blood product order messages present the need for additional information that is not included in standard HL7 order messages. Order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction), and the amount of the blood product to be administered. Additionally, specific relevant clinical information can be included to allow the prospective review of the appropriateness of the blood product order
Blood product orders can use the OMB message with the BPO segment for the detail segment and the acknowledgment message, ORB as described below.
|OMB^O26^OMB_O26 |Blood Product Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for BPO) |2 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| }] | | |
| [{FT1}] |Financial Transaction |6 |
| [BLG] |Billing Segment |6 |
| ] | | |
|} | | |
ORB – blood product order acknowledgment (event O27)
|ORB^O27^ORB_O27 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| }] | | |
| ] | | |
|] | | |
BPD – blood product dispense status message (event O28)
In the pre-transfusion processing of blood products, it is necessary for the transfusion service to communicate information that is not included in the current HL7 order/observation model. Examples of pre-transfusion processing include performing a crossmatch test to ensure compatibility with the patient, or irradiation of the blood product due to a special transfusion requirement for the patient. The blood product dispense status messages need to contain additional information regarding the blood products requested such as the Donation ID number, product code, blood type, expiration date/time and current status of the blood product.
In the processing of commercial blood products, such as Rh Immune Globulin, Factor Concentrate, or Albumin Products, it is necessary for the transfusion service to communicate information that is not included in the current HL7 order/observation model. The status messages need to contain additional information regarding the blood products requested, such as the lot number and manufacturer, expiration date and status of the commercial product.
A new message type and trigger event are proposed to initiate the transmission of a blood product dispense status message each time the status of a blood product changes.
Blood product dispense status messages will use the BPS and BRP messages as described below.
|BPS^O28^BPS_O28 |Blood Product dispense status Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| | | |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for BPO) |2 |
| [{ | | |
| BPX |Blood Product dispense status/Observation |4 |
| [{NTE}] |Notes and Comments (for BPX) |2 |
| } | | |
| } | | |
|} | | |
BRP – blood product dispense status acknowledgment (event O29)
|BRP^O29^BRP_O29 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| [{BPX}] |Blood Product dispense status/Observation | |
| }] | | |
|] | | |
| | | |
BTS – blood product transfusion message (event O30)
A new message type and trigger event is proposed to notify the filler system of the final disposition (transfusion ) of a blood product.
Blood product transfusion messages will use the BTS and BRT messages as described below.
|BTS^O30^BTS_O30 |Blood Product Transfusion Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| { | | |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for BPO) |2 |
| [{ | | |
| BTX |Blood Product Transfusion Status/Observation |4 |
| [{NTE}] |Notes and Comments (for BTX) |2 |
| }] | | |
| } | | |
|} | | |
BRT – blood product transfusion acknowledgment (event O31)
|BRT^O31^BRT_O31 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID] |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| [{BTX}] |Blood Product Transfusion Status/Observation |4 |
| }] | | |
|] | | |
Blood Bank Segments
ORC - common order segment
The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.
If details are needed for a particular type of order segment (e.g., Pharmacy, Dietary), the ORC must precede any order detail segment (e.g., RXO, ODS). In some cases, the ORC may be as simple as the string ORC|OK|||.
If details are not needed for the order, the order detail segment may be omitted. For example, to place an order on hold, one would transmit an ORC with the following fields completed: ORC-1-order control with a value of HD, ORC-2-placer order number, and ORC-3-filler order number.
There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections.
HL7 Attribute Table – ORC – Common Order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |2 |ID |R |N |0119 |00215 |Order Control |
|2 |22 |EI |C | | |00216 |Placer Order Number |
|3 |22 |EI |C | | |00217 |Filler Order Number |
|4 |22 |EI |O | | |00218 |Placer Group Number |
|5 |2 |ID |O |N |0038 |00219 |Order Status |
|6 |1 |ID |O | |0121 |00220 |Response Flag |
|7 |200 |TQ |O |Y | |00221 |Quantity/Timing |
|8 |200 |CM |O | | |00222 |Parent |
|9 |26 |TS |O | | |00223 |Date/Time of Transaction |
|10 |250 |XCN |O |Y | |00224 |Entered By |
|11 |250 |XCN |O |Y | |00225 |Verified By |
|12 |250 |XCN |O |Y | |00226 |Ordering Provider |
|13 |80 |PL |O | | |00227 |Enterer’s Location |
|14 |250 |XTN |O |Y/2 | |00228 |Call Back Phone Number |
|15 |26 |TS |O | | |00229 |Order Effective Date/Time |
|16 |250 |CE |O | | |00230 |Order Control Code Reason |
|17 |250 |CE |O | | |00231 |Entering Organization |
|18 |250 |CE |O | | |00232 |Entering Device |
|19 |250 |XCN |O |Y | |00233 |Action By |
|20 |250 |CE |O | |0339 |01310 |Advanced Beneficiary Notice Code |
|21 |250 |XON |O |Y | |01311 |Ordering Facility Name |
|22 |250 |XAD |O |Y | |01312 |Ordering Facility Address |
|23 |250 |XTN |O |Y | |01313 |Ordering Facility Phone Number |
|24 |250 |XAD |O |Y | |01314 |Ordering Provider Address |
|25 |250 |CWE |O |N | |01473 |Order Status Modifier |
BPO – blood product order segment
Blood product order messages present the need for additional information that is not included in standard HL7 order messages. Order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g. irradiation and leukoreduction) and the amount of the blood product to be administered.
The following table was used to present various use cases surrounding blood product orders. Discussions of these examples led to the identification of new fields needed that are required for blood product order messages.
|Universal Service ID [ISBT-128 Universal |Blood Product Attribute |Quantity |Blood Product Amount |Units |
|Service ID] | | | | |
|002^Red Blood Cells |Leukoreduced |2 |300 |ml |
|002^Red Blood Cells |Leukoreduced |1 |60 |ml |
|002^Red Blood Cells |Irradiated |2 |15 |ml |
|002^Red Blood Cells |Leukoreduced |1 | | |
|020^Platelets |Leukoreduced |6 | | |
| |Irradiated | | | |
|024^ Apheresis Platelets |Irradiated |1 | | |
|002^Red Blood Cells | |1 | | |
|Factor VIII | |2 |910 |IU |
As can be seen from this table, in addition to the Universal Service ID, it may be necessary to order special blood product attributes, such as leukoreduced or irradiated, or it may be necessary a particular volume of red blood cells required for transfusion. The attributes for the BPO Segment are defined below.
HL7 Attribute Table – BPO – Blood Product Order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |4 |SI |R | | | |Set ID – BPO |
|2 |250 |CE |R | |ISBT128 | |BP Universal Service ID |
|3 |250 |CE |O |Y |??? | |BP Attributes |
|4 |5 |NM |O | | | |BP Amount |
|5 |250 |CE |O | | | |BP Units |
|6 |26 |TS |O | | | |BP Intended Use Date/Time |
|7 |80 |PL |O | | | |BP Intended Dispense From Location |
|8 |26 |TS |O | | | |BP Requested Dispense Date/Time |
|9 |80 |PL |O | | | |BP Requested Dispense To Location |
|10 |250 |CWE |O |Y? | | |BP Indication for Use |
|11 |1 |ID |O | |0136 | |BP Informed Consent Indicator |
BPO field definitions
BPO-1 Set ID – BPO (SI)
Definition: This field contains the sequence number for the BPO segment within the message. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
BPO-2 BP Universal service identifier (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the identifier code for the requested observation/test/battery. This can be based on local and/or “universal” codes. We recommend the “universal” procedure identifier. The structure of this CE data type is described in the control section. The preferred coding system is the ISBT 128 Product Cod e.
Blood Product Orders for commercial products such as Rh Immune Globulin or Factor VII concentrate are not defined in an international or national coding system as are blood product. Therefore, locally defined codes can be used of the Universal Service Identifier for commercial products.
Appendix 1 - ISBT 128 Product Code Database Documentation Version 1.2.0
|Code |ISBT 128 Component Class |
|001 |WHOLE BLOOD |
|002 |RED BLOOD CELLS |
|003 |WASHED RED BLOOD CELLS |
|004 |FROZEN RED BLOOD CELLS |
|005 |FROZEN REJUVENATED RED BLOOD CELLS |
|006 |DEGLYCEROLIZED RED BLOOD CELLS |
|007 |DEGLYCEROLIZED REJUVENATED RED BLOOD CELLS |
|008 |REJUVENATED RED BLOOD CELLS |
|009 |APHERESIS RED BLOOD CELLS |
|010 |FRESH FROZEN PLASMA |
|011 |THAWED FRESH FROZEN PLASMA |
|012 |APHERESIS FRESH FROZEN PLASMA |
|013 |THAWED APHERESIS FRESH FROZEN PLASMA |
|014 |APHERESIS PLASMA |
|015 |THAWED APHERESIS PLASMA |
|016 |LIQUID PLASMA |
|017 |PLASMA |
|018 |THAWED PLASMA |
|019 |PLATELET RICH PLASMA |
|020 |PLATELETS |
|021 |WASHED PLATELETS |
|022 |POOLED PLATELETS |
|023 |WASHED POOLED PLATELETS |
|024 |APHERESIS PLATELETS |
|025 |FROZEN APHERESIS PLATELETS |
|026 |THAWED APHERESIS PLATELETS |
|027 |WASHED APHERESIS PLATELETS |
|028 |CRYOPRECIPITATE |
|029 |THAWED CRYOPRECIPITATE |
|030 |POOLED CRYOPRECIPITATE |
|031 |THAWED POOLED CRYOPRECIPITATE |
|032 |APHERESIS CRYOPRECIPITATE |
|033 |THAWED APHERESIS CRYOPRECIPITATE |
|034 |GRANULOCYTES |
|035 |APHERESIS GRANULOCYTES |
|036 |POOLED GRANULOCYTES |
|037 |APHERESIS GRANULOCYTES /PLATELETS |
|038 |LEUKOCYTES |
|039 |APHERESIS LEUKOCYTES |
|040 |POOLED PLASMA |
BPO-3 BP Attributes (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required product attributes or special processing requirements for the blood product, which must be completed prior to transfusion to the intended recipient. Examples of processing requirements or product attributes include CMV Negative, HLA Matched, Irradiated or Leukoreduced. Refer to HL7 Table #### (to be assigned) - Blood Component Transfusion Requirements for suggested values.
This is an optional, repeating field.
HL7 Table #### (to be assigned) - Blood Component Transfusion Requirements
|Value |Description |
|LR |Leukoreduced |
|IR |Irradiated |
|CS |CMV Safe |
|FR |Fresh unit |
|AU |Autologous Unit |
|DI |Directed Unit |
|HL |HLA Matched |
|CM |CMV Negative |
|HB |Hemoglobin S Negative |
|WA |Washed |
|IG |IgA Deficient |
BPO-4 BP Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of blood product.
This field is optional so that a unit of blood can be ordered without an amount or unit specified.
BPO-5 BP Units (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the units for the blood product amount. This field contains the designation for unit of measure for blood products. See 7.15.3.3.2.
This field is optional so that a unit of blood can be ordered without an amount or unit of measure specified.
BPO-6 BP Intended Use Date/Time (TS)
Definition: This field specifies the date/time associated with the scheduled availability of the blood product.
This is the time when the product is expected to be available within the transfusion service. For example, the product should be available for use but not dispensed on this date/time. This field is optional.
BPO-7 BP Intended Dispense From Location (PL)
Facility: & & & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & & &
Subcomponents of channel calibration parameters: < channel calibration sensitivity correction factor (NM)> & < channel calibration baseline (NM)> & < channel calibration time skew (NM)>
Subcomponents of minimum/maximum data values: < minimum data value (NM)> &
7.14.1.3.1 7.15.3.1 Channel identifier (CM)
Subcomponents: &
7.14.1.3.2 7.15.3.1.1 Channel number (NM)
7.14.1.3.3 7.15.3.1.2 Channel name (ST)
>.
7.14.1.4 7.15.3.2 Waveform source (CM)
Subcomponents: &
7.14.1.4.1 7.15.3.2.1 Source name 1 (ST)
7.14.1.4.2 7.15.3.2.2 Source name 2 (ST)
7.14.1.5 7.15.3.3 Channel sensitivity and units (CM)
Subcomponents: & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & & &
7.14.1.5.1 7.15.3.3.1 Channel sensitivity (NM)
7.14.1.5.2 7.15.3.3.2 Unit of measure identifier (ST)
7.14.1.5.3 7.15.3.3.3 Unit of measure description (ST)
.
7.14.1.5.4 7.15.3.3.4 Unit of measure coding system (IS)
7.14.1.5.15 7.15.3.3.5 Alternate unit of measure identifier (ST)
7.14.1.5.6 7.15.3.3.6 Alternate unit of measure description (ST)
7.14.1.5.7 7.15.3.3.7 Alternate unit of measure coding system (IS)
7.14.1.6 7.15.3.4 Channel calibration parameters (CM)
Subcomponents: < channel calibration sensitivity correction factor (NM)> & < channel calibration baseline (NM)> & < channel calibration time skew (NM)>
7.14.1.6.1 7.15.3.4.1 Channel calibration sensitivity correction factor (NM)
7.14.1.6.2 7.15.3.4.2 Channel calibration baseline (NM)
7.14.1.6.3 7.15.3.4.3 Channel calibration time skew (NM)
7.14.1.7 7.15.3.5 Channel sampling frequency (NM)
7.14.1.8 7.15.3.6 Minimum and maximum data values (CM)
Subcomponents: < minimum data value (NM)> &
7.14.1.8.1 7.15.3.6.1 Minimum data value (NM)
7.14.1.8.2 7.15.3.6.2 Maximum data value (NM)
7.16 Waveform – Trigger Events & Message Definitions
7.17 Waveform – Segment Definitions
7.14.2 7.17.1 Specific observation ID suffixes
NOTE: Suggest moving this section with its components to the section on segments, perhaps as introductory text. Or, the section could move to 7.14 as introductory narrative for the entire Waveform section.
Each waveform channel in a recording contains timing, channel definition and digital time series data. The category of waveform result transmitted in a given OBX segment is determined by the Observation ID Suffix contained in OBX-3-observation identifier. Four suffixes are provided for the different categories of waveform result:
|Observation |Suffix |Data Type |
|Timing Information |TIM |TS |
|Channel Definition |CHN |CD |
|Waveform Data |WAV |NA or MA |
|Waveform Annotation |ANO |CE |
The Observation Sub-ID is used to associate the TIM, CHN, and subsequent WAV, and ANO category result segments for a given channel or channels in a waveform response message.
7.14.2.1 7.17.1.1 Timing information (TIM)
7.14.2.2 7.17.1.2 Channel definition data (CHN)
7.14.2.3 7.17.1.3 Waveform digital data (WAV)
7.14.2.4 7.17.1.4 Waveform annotation (ANO)
7.16.1 7.17.2 Combining rules for waveform OBX segments
.
7.16.2 7.17.3 Restrictions on valuation of OBX segment fields
7.16.3 7.17.4 OBX segment - TIM category
7.16.4 7.17.5 OBX segment - CHN category
7.16.5 7.17.6 OBX segment - WAV category
7.16.6 7.17.7 OBX segment – ANO category
7.17 7.18 Waveform – Examples of use
7.18 7.19 Table Listings
7.19 7.20 Outstanding Issues
131 - Add correction to TQ data type component 10 to v 2.4 and v 2.3.1 errata lists
Submitted By: Joann Larson – Kaiser Permanente
Section: 4.3.10
Priority: 39
Description: This correction to v 2.4 and v 2.3.1 is needed for the addendum that will be applied to v 2.4 and to v 2.3.1 in support of a fully specified XML encoding of the standard. The addendum provides a standard method for differentiating CM data types. It is essential that the correct component model be displayed
Justification: Editorial
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
Add to errata list for v 2.4 the following:
1) Section 4.3.10, Order Sequencing Component: Missing component model. Should be
components: ^ ^ < Placer Order Number: Namespace ID (IS)> ^ < Filler Order Number: Entity Identifier (ST)> ^ < Filler Order Number: Namespace ID (IS)> ^ < Sequence Condition Value (ST)> ^ < Maximum Number of Repeats (NM)> ^ < Placer Order Number: Universal ID (ST)> ^ < Placer Order Number: Universal ID Type (ID)> ^< Filler Order Number: Universal ID (ST)> ^ < Filler Order Number: Universal ID Type (ID)>
Add to errata list for v 2.3.1 the following:
1) Section 4.4.10, Order Sequencing Component: Missing component model. Should be
components: ^ ^ < Placer Order Number: Namespace ID (IS)> ^ < Filler Order Number: Entity Identifier (ST)> ^ < Filler Order Number: Namespace ID (IS)> ^ < Sequence Condition Value (ST)> ^ < Maximum Number of Repeats (NM)> ^ < Placer Order Number: Universal ID (ST)> ^ < Placer Order Number: Universal ID Type (ID)> ^< Filler Order Number: Universal ID (ST)> ^ < Filler Order Number: Universal ID Type (ID)>
133 - Create new HL7 Table nnnn- Specimen Type to replace existing HL7 Table 0070- Specimen Source
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.4.1.15
Priority: 25
Description: Replacement of original proposal # 37. This is a continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis.
Justification:
Minneapolis Discussion
See resolution on #39.
Proposal Language
Probable Retentions from Current Table
The following values appear in the current table 0070 as it appears in v 2.4 and will probably be brought forth to the new table. Note the addition of a Category column and re-organization of the value description so that the keyword appears first; both of these modifications were agreed upon at St. Louis.
HL7 Table nnnn - Specimen type codes
|Value |Description |Category |Comment |
|ABS |Abscess | | |
|ASP |Aspirate | | |
|BBL |Blood bag |Blood | |
|BON |Bone | | |
|BPU |Blood product unit |Blood | |
|BRN |Burn | | |
|BRTH |Breath (use EXHLD) | | |
|CALC |Calculus (=Stone) | | |
|CNJT |Conjunctiva | | |
|COL |Colostrum | | |
|CTP |Catheter tip | | |
|CYST |Cyst | | |
|DRN |Drain | | |
|EARW |Ear wax (cerumen) | | |
|ELT |Electrode | | |
|EXG |Gas, exhaled (=breath) | | |
|FIST |Fistula | | |
|FLT |Filter | | |
|FLU |Fluid, Body unsp | | |
|GAS |Gas | | |
|GAST |Fluid/contents, Gastric | | |
|GENV |Genital vaginal | | |
|IHG |Gas, Inhaled | | |
|IT |Intubation tube | | |
|MBLD |Blood, Menstrual |Blood | |
|ORH |Other | | |
|PLAS |Plasma |Blood | |
|PLB |Plasma bag |Blood | |
|PPP |Plasma, Platelet poor |Blood | |
|PRP |Plasma, Platelet rich |Blood | |
|PUS |Pus | | |
|SAL |Saliva | | |
|SER |Serum | | |
|SKN |Skin | | |
|SNV |Fluid, synovial (Joint fluid) | | |
|SPRM |Spermatozoa | | |
|SPT |Sputum | | |
|SPTC |Sputum - coughed | | |
|SPTT |Sputum - tracheal aspirate | | |
|STL |Stool = Fecal | | |
|TISS |Tissue | | |
|TISU |Tissue ulcer | | |
|UR |Urine | | |
|URC |Urine clean catch | | |
|URT |Urine catheter | | |
|VITF |Vitreous Fluid | | |
|VOM |Vomitus | | |
|WAT |Water | | |
|WICK |Wick | | |
|WND |Wound | | |
|WNDA |Wound abscess | | |
|WNDD |Wound drainage | | |
|WNDE |Wound exudate | | |
Probable exclusions:
The following table shows 71 values currently in table 0070 in v 2.4 that are under investigation as items to possibly exclude from the new table, largely because they appear to be anatomical locations.
HL7 Table 0070 Recommend Deprecations
|CD Value |CD Name |Category |Comment |
|AMN |Amniotic fluid | |Moved to Table 0163 Body Parts |
|BDY |Body, Whole | |Moved to Table 0163 Body Parts |
|BIFL |Bile fluid | |Moved to Table 0163 Body Parts |
|BLD |Blood, Whole | |Moved to Table 0163 Body Parts |
|BLDA |Blood, Arterial | |Moved to Table 0163 Body Parts |
|BLDC |Blood, Capillary | |Moved to Table 0163 Body Parts |
|BLDV |Blood, Venous | |Moved to Table 0163 Body Parts |
|BPH |Basophils | |Moved to Table 0163 Body Parts |
|BRO |Bronchial | |Moved to Table 0163 Body Parts |
|CBLD |Blood, Cord | |Moved to Table 0163 Body Parts |
|CDM |Cardiac Muscle | |Moved to Table 0163 Body Parts |
|CNL |Canula | |Moved to Table 0163 Body Parts |
|CSF |Cerebral Spinal Fluid | |Moved to Table 0163 Body Parts |
|CUR |Curettage | |Unclear meaning |
|CVM |Cervical Mucus | |Replace by Mucus & Body Part |
|CVX |Cervix | |Moved to Table 0163 Body Parts |
|DIAF |Dialysis Fluid | |Moved to Table 0163 Body Parts |
|DOSE |Dose Med Or Substance | | |
|DUFL |Duodenal Fluid | |Moved to Table 0163 Body Parts |
|EAR |Ear | |Moved to Table 0163 Body Parts |
|ENDC |Endocardium | |Moved to Table 0163 Body Parts |
|ENDM |Endometrium | |Moved to Table 0163 Body Parts |
|EOS |Eosinophils | |Moved to Table 0163 Body Parts |
|EYE |Eye | |Moved to Table 0163 Body Parts |
|FIB |Fibroblasts | |To specific |
|GEN |Genital | |Moved to Table 0163 Body Parts |
|GENC |Genital Cervix | |Moved to Table 0163 Body Parts |
|GENL |Genital Lochia | |Moved to Table 0163 Body Parts |
|HAR |Hair | |Moved to Table 0163 Body Parts |
|ISLT |Isolate | |Unclear meaning |
|LAM |Lamella | |Moved to Table 0163 Body Parts |
|LIQ |Liquid, NOS | |Unclear meaning |
|LN |Line | |Unclear meaning |
|LNA |Line, Arterial | |Moved to Collection Method |
|LNV |Line, Venous | |Moved to Collection Method |
|LYM |Lymphocytes | |Moved to Table 0163 Body Parts |
|MAC |Macrophages | |Moved to Table 0163 Body Parts |
|MAR |Marrow | |Moved to Table 0163 Body Parts |
|MEC |Meconium | |Moved to Table 0163 Body Parts |
|MILK |Milk, Breast | |Moved to Table 0163 Body Parts |
|NAIL |Nail | |Moved to Table 0163 Body Parts |
|NOS |Nose (Nasal Passage) | |Moved to Table 0163 Body Parts |
|PAFL |Pancreatic Fluid | |Moved to Table 0163 Body Parts |
|PAT |Patient | |Unclear meaning |
|PLC |Placenta | |Moved to Table 0163 Body Parts |
|PLR |Pleural Fluid (Thoracentesis Fld) | |Moved to Table 0163 Body Parts |
|PMN |Polymorphonuclear Neutrophils | |To specific |
|PRT |Peritoneal Fluid /Ascites | |Replace by Fluid & Body Part |
|RBC |Red Blood Cells | |Moved to Table 0163 Body Parts |
|RT |Route Of Medicine | |Ambiguous |
|SEM |Seminal Fluid | |Moved to Table 0163 Body Parts |
|SKM |Skeletal Muscle | |Moved to Table 0163 Body Parts |
|SPRM |Spermatozoa | |Moved to Table 0163 Body Parts |
|STON |Stone (Use CALC) |Condition |Replace by CALC |
|SWT |Sweat | |Moved to Table 0163 Body Parts |
|TEAR |Tears | |Moved to Table 0163 Body Parts |
|THRB |Throat | |Moved to Table 0163 Body Parts |
|THRT |Thrombocyte (Platelet) | |Too specific |
|TISPL |Tissue, Gall Bladder | | |
|TISS |Tissue, Large Intestine | |Replace by Tissue & Body Part |
|TISU |Tissue, Lung | |Replace by Tissue & Body Part |
|TLGI |Tissue, Placenta | |Replace by Tissue & Body Part |
|TUB |Tube NOS | |Unclear meaning |
|ULC |Ulcer | |Replace by Tissue, Ulcer |
|UMB |Umbilical Blood | |Moved to Table 0163 Body Parts |
|UMED |Unknown Medicine | | |
|URNS |Urine, Sediment | | |
|URTH |Urethra | |Moved to Table 0163 Body Parts |
|USUB |Unknown Substance | | |
|WBC |Leukocytes | |Moved to Table 0163 Body Parts |
|XXX |To Be Specified In Another Part Of | | |
| |The Message | | |
Possible Additions:
The following table shows 218 values that are still under investigation as additions to table nnnn Specimen Type.
HL7 Table nnnn Specimen Type
|CD Value |CD Name |Category |Comment |
|PELVA |Abscess, Pelvic |Condition | |
|PERIA |Abscess, Perianal |Condition |Abscess & Body Part |
|RECTA |Abscess, Rectal |Condition | |
|SCROA |Abscess, Scrotal |Condition | |
|SUBMA |Abscess, Submandibular |Condition | |
|SUBMX |Abscess, Submaxillary |Condition | |
|TSTES |Abscess, Testicular |Condition | |
|AIRS |Air Sample |Environment | |
|ALL |Allograft |Tissue | |
|AMP |Amputation |Tissue | |
|GASAN |Antrum, Gastric |Tissue | |
|ETA |Aspirate, Endotrach |Aspirate | |
|GASA |Aspirate, Gastric |Aspirate | |
|NGASP |Aspirate, Nasogastric |Aspirate | |
|TASP |Aspirate, Tracheal |Aspirate | |
|TTRA |Aspirate, Transtracheal |Aspirate | |
|AUTP |Autopsy |Tissue | |
|BX |Biopsy |Tissue | |
|GSPEC |Biopsy, Gastric |Tissue | |
|SKBP |Biopsy, Skin |Tissue | |
|CONE |Biospy, Cone |Tissue | |
|BITE |Bite |Conditions | |
|CBITE |Bite, Cat |Conditions | |
| |Bite, Dog |Conditions | |
| |Bite, Human |Conditions | |
| |Bite, Insect |Conditions | |
| |Bite, Reptile |Conditions | |
|BLEB |Bleb |Fluid/Tissue |Condition |
|BLIST |Blister |Fluid/Tissue |Condition |
|HBLUD |Blood, Autopsy |Blood | |
|CSVR |Blood, Cell Saver |Transfusion | |
|FBLOOD |Blood, Fetal |Blood | |
|WB |Blood, Whole |Blood | |
|BOIL |Boil |Condition | |
|BOWL |Bowel contents |Condition | |
|BRSH |Brush |Product |Brush or brushing (these may be 2 |
| | | |separate entries as in a physical brush|
| | | |or a portion thereof vs the substance |
| | | |obtained after a surface has been |
| | | |brushed) |
|EBRUSH |Brush, Esophageal |Product | |
| |Brushing |Product | |
|GASBR |Brushing, Gastric |Product | |
|BUB |Bubo |Condition | |
|BULLA |Bulla/Bullae |Condition | |
|CARBU |Carbuncle |Condition | |
|CAT |Catheter |Device | |
| |Catheter Insertion Site |Device | |
|ANGI |Catheter Tip, Angio |Device | |
|ARTC |Catheter Tip, Arterial |Device | |
|CVPT |Catheter Tip, CVP |Device | |
|ETTP |Catheter Tip, Endotracheal |Device | |
|FOLEY |Catheter Tip, Foley |Device | |
|HEMAQ |Catheter Tip, Hemaquit |Device | |
|HEMO |Catheter Tip, Hemovac |Device | |
|IDC |Catheter Tip, Indwelling |Device | |
|INTRD |Catheter Tip, Introducer |Device | |
|IVCAT |Catheter Tip, IV |Device | |
|MAHUR |Catheter Tip, Makurkour |Device | |
|SCLV |Catheter Tip, Subclavian |Device | |
|SPRP |Catheter Tip, Suprapubic |Device | |
|SWGZ |Catheter Tip, Swan Gantz |Device | |
|VASTIP |Catheter Tip, Vas |Device | |
|VENT |Catheter Tip, Ventricular |Device | |
|GROSH |Catheter, Groshong |Device | |
|HIC |Catheter, Hickman |Device | |
|PORTA |Catheter, Porta |Device | |
|SPRPB |Cathether Tip, Suprapubic |Device | |
|TLC |Cathether Tip, Triple Lumen |Device | |
|CLIPP |Clippings |Condition | |
|LENS1 |Contact Lens |Device | |
|LENS2 |Contact Lens Case |Device | |
|BCYST |Cyst, Baker's |Condition | |
|ICYST |Cyst, Inclusion |Condition | |
|PILOC |Cyst, Pilonidal |Condition | |
|RENALC |Cyst, Renal |Condition | |
| |Dialysate |Condition | |
|DISCHG |Discharge |Condition | |
|DIV |Diverticulum |Condition | |
|DRN |Drain |Device | |
|HEV |Drain, Hemovac |Device | |
|GTUBE |Drainage Tube, Drainage (Gastrostomy) |Condition | |
|GASD |Drainage, Gastric |Condition | |
|ILEO |Drainage, Ileostomy |Condition | |
|JP |Drainage, Jackson Pratt |Condition | |
|JEJU |Drainage, Jejunal |Condition | |
|NASDR |Drainage, Nasal |Condition | |
|NGAST |Drainage, Nasogastric |Condition | |
|PND |Drainage, Penile |Condition | |
|DRNGP |Drainage, Penrose |Condition | |
|RECT |Drainage, Rectal |Condition | |
|SUMP |Drainage, Sump |Condition | |
|DRNG |Drainage, Tube |Device | |
|EFFUS |Effusion |Condition | |
|AUTOC |Environment, Attest |Environment | |
| |Environmental, Autoclave Ampule |Environment | |
|ISL |Environmental, Autoclave Capsule |Environment | |
|EFF |Environmental, Effluent |Environment | |
| |Environmental, Eye Wash |Environment | |
| |Environmental, Food |Environment | |
| |Environmental, Isolette |Environment | |
| |Environmental, Other Substance |Environment | (Substance is Known but not in code |
| | | |Table) |
| |Environmental, Soil |Environment | |
| |Environmental, Solution (Sterile) |Environment | |
|SPS |Environmental, Spore Strip |Environment | |
|STER |Environmental, Sterrad |Environment | |
|ENVIR |Environmental, Unidentified Substance |Environment | |
| |Environmental, Water |Environment | |
|DEION |Environmental, Water (Deionized) |Environment | |
| |Environmental, Water (Tap) |Environment | |
|FAW |Environmental, Water (Well) |Environment | |
| |Environmental, Water (Ocean) |Environment | |
| |Environmental, Whirlpool |Environment | |
|EXUDTE |Exudate |Condition | |
|FLUID |Fluid |Fluid | |
|FGA |Fluid, Abdomen |Fluid | |
|CSMY |Fluid, Cystostomy Tube |Fluid | |
| |Fluid, Acne |Fluid | |
|CST |Fluid, Cyst |Fluid | |
|HYDC |Fluid, Hydrocele |Fluid | |
|IVFLD |Fluid, IV |Fluid | |
|JNTFLD |Fluid, Joint |Fluid | |
|KIDFLD |Fluid, Kidney |Fluid | |
|LSAC |Fluid, Lumbar Sac |Fluid | |
|FLD |Fluid, Other |Fluid | |
|PCFL |Fluid, Pericardial | | |
|RENC |Fluid, Renal Cyst |Fluid | |
|FRS |Fluid, Respiratory |Fluid | |
|SHUNT |Fluid, Shunt |Fluid | |
|FUR |Furuncle |Condition | |
|GRAFT |Graft |Condition | |
|GRAFT |Graft Site |Condition | |
|POPGS |Graft Site, Popliteal |Condition | |
|POPLG |Graft, Popliteal |Condition | |
|GRANU |Granuloma |Condition | |
|IMP |Implant |Device | |
|INFIL |Infiltrate |Condition | |
| |Insect |Object | |
|IUD |Intrauterine Device |Device |Common Usage |
|KELOI |Lavage |Product | |
|LAVG |Lavage, Bronhial |Product | |
|LAVGG |Lavage, Gastric |Product | |
|LAVGP |Lavage, Peritoneal |Product | |
| |Lavage, Pre-Bronch |Product | |
|LESN |Lesion |Condition | |
|ORL |Lesion, Oral |Condition |Common Usage |
|PENIL |Lesion, Penile |Condition |Common Usage |
| |Liquid, Other | | |
| |Liquid, Unspecified | | |
|MASS |Mass |Condition | |
|SMM |Mass, Sub-Mandibular |Condition | |
|MUCOS |Mucosa |Condition | |
|MUCUS |Mucus |Condition | |
|NEDL |Needle |Device | |
|NODUL |Nodule(s) |Condition | |
|CYN |Nodule, Cystic |Condition | |
|PACEM |Pacemaker |Device | |
| |Plant Material |Object | |
|POL |Polyps |Condition | |
|PROST |Prosthetic Device |Device | |
| PSC |Pseudocyst |Condition | |
|PUST |Pus |Condition |Might change to Exudates, Pus |
|PUSFR |Pustule |Condition | |
|QC3 |Quality Control |Environment | |
|RES |Respiratory |Condition |Ambiguous |
|FSCLP |Scalp, Fetal |Condition |Ambiguous |
| |Scratch, Cat |Condition | |
|SECRE |Secretion(s) |Fluid/Secretion | |
|NSECR |Secretion, Nasal |Condition | |
|ASERU |Serum, Acute |Blood | |
|CSERU |Serum, Convalescent |Blood | |
|PLEVS |Serum, Peak Level |Blood | |
| |Serum, Trough |Blood | |
|SHUNT |Shunt |Condition | |
|EXS |Shunt, External |Condition | |
|SITE |Site |Site | |
|CVPS |Site, CVP |Site | |
|INCI |Site, Incision/Surgical |Site | |
|NGS |Site, Naso/Gastric |Site | |
|NEPH |Site, Nephrostomy |Site | |
|PIS |Site, Pacemaker Insetion |Site | |
|PDSIT |Site, Peritoneal Dialysis |Site | |
|PDTS |Site, Peritoneal Dialysis Tunnel |Site | |
|PINS |Site, Pin |Site | |
|POPLV |Site, Popliteal Vein |Site | |
|SHU |Site, Shunt |Site | |
|TRAC |Site, Tracheostomy |Site | |
|TZANC |Smear, Tzanck | | |
|GSOL |Solution, Gastrostomy |Product | |
| |Source of Specimen Is Illegible | | |
| |Source, Other | | |
| |Source, Unidentified | | |
| |Source, Unspecified | | |
|DCS |Sputum, Deep Cough |Condition | |
|SPUTIN |Sputum, Inducted |Condition | |
|SPUT1 |Sputum, Simulated |Condition | |
|SPUTSP |Sputum, Spontaneous |Condition | |
|STONE |Stone, Kidney |Condition | |
|SUP |Suprapubic Tap |Product |Additional Discussion |
|SUTUR |Suture |Object | |
|ACNE |Tissue, Acne |Tissue | |
|HERNI |Tissue, Herniated |Tissue | |
| |Tissue, Keloid (Scar) |Tissue | |
|TRANS |Transudate |Condition | |
|ETTUB |Tube, Endotracheal |Device | |
|GT |Tube, Gastric |Device | |
|TUBES |Tubes |Device | |
|IVTIP |Tubing Tip, IV |Device | |
|TUMOR |Tumor |Condition | |
|DEC |Ulcer, Decubitus |Condition | |
|URINB |Urine, Bladder Washings |Condition | |
| |Urine, Catheterized |Condition | |
|USCOP |Urine, Cystoscopy |Condition | |
|URINM |Urine, Midstream |Condition | |
| |Urine, Nephrostomy |Condition | |
| |Urine, Pedibag |Device | |
|RANDU |Urine, Random |Condition | |
|WRT |Wart |Tissue | |
| WASH |Wash |Product | |
| |Washing, e.g. bronchial washing |Product | |
|WEN |Wen |Tissue | |
| |Worm |Object | |
|PUNCT |Wound, Puncture |Condition | |
134 - Add values to HL7 Table 0376- Special handling considerations
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.4.1.15
Priority: 26
Description: This is a replacement of proposal # 38. Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis
Justification:
Minneapolis Discussion
See resolution on #39
Proposal Language
13.4.3.43 SAC-43 Special handling consideration (CE)
User-defined Table 0376 - Special handling considerations
|Value |Description |
| |Store at room temperature |
| |Use lead free container |
| |Use metal free container |
|PRTL |Protect from light |
|CFRZ |Critical Frozen |
|CATM |Critical do not expose to atmosphere – Do not uncap |
|CREF |Critical refrigerated |
|CAMB |Critical ambient temperature |
|C37 |Critical maintain at 37C (e.g., cryoglobulin specimen |
User-defined Table 0376 - Special handling considerations
|Code |Description |Comment/Usage Note/Definition |
|C37 |Body temperature |Critical to keep specimen at body temperature: 36 - 38( C. |
|AMB |Ambient temperature |Keep specimen at ambient (room) temperature, approximately 22 ( 2 |
| | |°C. Accidental refrigeration or freezing is of little consequence |
|CAMB |Critical ambient temperature |Critical ambient – specimen must not be refrigerated or frozen. |
|REF |Refrigerated temperature |Keep specimen at refrigerated temperature: 4-8( C. Accidental |
| | |warming or freezing is of little consequence |
|CREF |Critical refrigerated temperature |Critical refrigerated – specimen must not be allowed to freeze or |
| | |warm until immediately prior to testing |
|FRZ |Frozen temperature |Keep specimen at frozen temperature: -4( C. Accidental thawing is |
| | |of little consequence |
|CFRZ |Critical frozen temperature |Critical frozen – specimen must not be allowed to thaw until |
| | |immediately prior to testing |
|DFRZ |Deep frozen |Deep frozen: -16 to -20( C. |
|UFRZ |Ultra frozen |Ultra cold frozen: ~ -75 to -85( C. (ultra cold freezer is |
| | |typically at temperature of dry ice). |
|NTR |Liquid nitrogen |Keep specimen in liquid nitrogen. |
|PRTL |Protect from light |Protect specimen from light (e.g., wrap in aluminum foil). |
|CATM |Protect from air |Critical. Do not expose specimen to atmosphere. Do not uncap. |
|DRY |Dry |Keep specimen in a dry environment. |
|PSO |No shock |Protect specimen from shock. |
|PSA |Do not shake |Do not shake specimen. |
|UPR |Upright |Keep specimen upright. Do not turn upside down. |
|MTLF |Metal Free |Specimen container is free of heavy metals including lead. |
137 - Add corrected component model to CD data type and to segment fields OM2-6 and OM2-9 to v 2.3.1 errata list
Submitted By: Joann Larson – Kaiser Permanente
Section: 7.15.3
Priority: 39
Description: This correction to v 2.3.1 is needed for the addendum that will be applied to v 2.3.1 in support of a fully specified XML encoding of the standard. The addendum provides a standard method for differentiating CM data types. It is essential that the correct component model be displayed.
Justification: editorial
Minneapolis Discussion
Against: 0, Abstain: 0, In Favor: 14
Proposal Language
Add to errata list for chapter 8 v 2.3.1 the following:
1) Section 8.7.4.6, OM2-6 - Reference (normal) range for ordinal and continuous observations: Component model is incorrect. Should be:
Components ^ ^ ^ ^ ^ ^
2) Section 8.7.4.6.1, OM2-6.1 - Reference (normal) range: Component model is incorrect. Should be:
Components &
3) Section 8.7.4.6.3, OM2-6.3 - Age range: Component model is incorrect. Should be:
Components &
4) Section 8.7.4.6.4, OM2-6.1 – Gestational age range: Component model is incorrect. Should be:
Components &
2) Section 8.7.4.9, OM2-9- Delta check criteria: The component model for component 1 is incorrect. The full model for the field should be:
Components ^ < Numeric threshold (NM)> ^ < Change computation (ST)> ^ < Length of time-days (NM)>
Subcomponent of CM_NRs &
Add to errata list for chapter 7 v 2.3.1 the following:
1) Section 7.15.3 CD - Channel Definition: Component model is incorrect. Should be:
Components: ^ ^ ^ ^ ^
2) Section 7.15.3.1: Channel identifier: Component model is missing. Should be:
Components: &
3) Section 7.15.3.2: Waveform source: Component model is missing. Should be:
Components: &
4) Section 7.15.3.3: Channel sensitivity and units: Component model is missing. Should be:
Components: & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & & &
5) Section 7.15.3.4: Channel calibration parameters: Data type is incorrect and component model is missing. Data type should be (CM_CCP), component model should be:
Components: & & < channel calibration time skew (NM)>
6) Section 7.15.3.5: Channel sampling frequency: Data type is missing. Should be (NM).
7) Section 7.15.3.6: Minimum and maximum data values: Data type is incorrect and component model is missing. Data type should be (CM_MDV), component model should be:
Components: &
Attachment B: SDA Discussion Document
CDA Level Three Discussion Topics
May 2001 HL7 Working Group Session
Prepared by: Bob Dolin
April 29, 2001
Introduction:
There has been concern expressed that a different representation of coded observations in V3 messages and CDA Level Three documents would create an implementation burden. These proposals begin to look at CDA Level Three documents, to see exactly how they will be similar or different from V3 messages. In particular, they address these main concerns:
• Inline vs. MIME-packaged CDA :: Is it possible to send a CDA document inline rather than as a MIME-encoded package? There's a sense that this would make the underlying concept representations more consistent – if basically we send a message, and you can just snip out the CDA document, or continue to treat it as a message. Issues that arise here include the need to apply a digital signature to an unalterable document, translating between a CDA instance and a V3 message instance, and the desire to have a discreet CDA XML DTD to validate the document.
• Representation of coded observations together with structured text :: A single instance of the Act class would have a single instance of the Act.txt attribute – therefore just one text block per Act instance. On the other hand, CDA structures (paragraphs, lists, tables, sections) contain a mix of character data, multimedia, and hyperlinks - so that within a paragraph for instance, a hyperlink can be inserted in the middle of a sentence. Issues that arise here include the question of how the text in this paragraph maps to Act.txt if we're to be able to transform between messages and documents.
• Consistency of representation of coded observations in documents and messages :: At a minimum, it must be possible to translate the coded observations in a CDA Level Three document into a V3 message, and vice versa, with no loss of information.
Principles:
• A CDA document must remain in existence in an unaltered state after it has been signed.
• Acts and observations in CDA documents will be represented the same as in V3 messages OR there will be formal and unambiguous mapping rules to transform in both directions.
• The CDA distinguishes between a "Structure" and an "Entry". Structures (body, section, list, table, paragraph, content) can nest, and can contain entries (character data, non-xml data, coded entries, multi-media, links). The main distinction between a structure and an entry is that structures are non-patient specific, and convey no patient data. Rather, they act as the scaffolding to hold entries, which do contain patient data. Structures represent the organizational aspects of a CDA document.
• The CDA will have a uniform mechanism of representing Acts within CDA Structures.
• A CDA Structure has a "context", which is derived from the RIM's Act_context class. The current CDA structure context includes (1) confidentiality; (2) origination; (3) human language. The context is applicable to the contents of the structure, and is inherited by nested structures, unless overridden.
• A CDA Entry does not have a "context" (although this may change in future versions).
Discussion Topics:
(Diagram 1 is the current representation of CDA in RIM 1.02.
Diagram 2 is the proposed representation of CDA in the RIM.
Diagrams 3 and 4 are a VISIO model of the merged MDM / CDA R-MIM)
• How to authenticate an inline CDA Document?
Merged MDM / CDA R-MIM and Hierarchical Description - not all attributes are used by CDA. How can you both (1) sign a document; and (2) preserve the ability to let certain values change over time? For instance, the MDM header includes storage_cd, whose values include "active", "active and archived", "archived and not active", etc. These values will change after a document has been legally authenticated.
• CDA Structures are quite similar to Act_contexts.
While CDA currently says that a CDA structure contains a context, it's essentially the case that a CDA structure is a kind of Act_context - a CDA structure contains attributes drawn from the Act_context class (e.g. Act_context.language_cd), a CDA structure contains other Acts, the types of values used by CEN for Act_context.level_cd are analagous to CDA structures (e.g. "section"). In fact, we should create a vocabulary domain for Act_context.level_cd that is based on the CDA-defined structures:
• Structure (abstract)
• Table_structure (abstract)
• Table_cell (abstract)
• Table_header_cell
• Table_data_cell
• Table_row_structure (abstract)
• Table_row
• Table_row_group (abstract)
• TableRowGroupType vocabulary domain (tbody, tfoot, thead)
• Table_column_structure (abstract)
• Table_column
• Table_column_group
• Table
• Content
• Paragraph
• List
• List_item
• Section
• Clinical_document_body
• Clinical_document
• CDA_levelone_clinical_document
• We can use the similarity between a CDA structure and an Act_context to define a translation between CDA documents and V3 messages. In fact, it would almost be possible to build an R-MIM for a complete CDA document - header and body. A translation between a CDA instance and a pure R-MIM instance might look something like this:
|CDA Representation |Pure R-MIM Representation |
| | |
|... | |
| |... |
| | |
| | |
| | |
| | |
| | |
| ... | ... |
| ... | ... |
| | |
| | |
| | |
• CDA Entries are quite similar to Acts.
CDA entries are similar to Acts - and are getting more and more similar over time. CDA's "observation_media" entry is derived from the Observation class by using the MDF to create an R-MIM and Hierarchical Description. Other candidate entries that can be modeled the same way include the current Unstructured_blob class (used by CDA to represent a non-XML document body), Coded_entry (used by CDA to insert codes into documents), and CharacterData (used by CDA to insert character data into documents).
Problems that arise in the translation between CDA Entries and RIM Acts include:
• CDA's use of HTML link types vs. Act_relationship.type_cd values. The HtmlLinkType vocabulary domain contains these values:
alternate, appendix, bookmark, chapter, contents, copyright, glossary, help, index, next, prev, section, start, stylesheet, subsection.
• CDA's use of narrative does not exactly map to Act.txt. For instance, the CDA defines a table data cell, , as (#PCDATA | content | link | coded_entry | observation_media | paragraph | list | local_markup)*. This would allow for the following instance.
... blah blah blah (character data) ...
...
... blah blah blah (character data) ...
My web site
... blah blah blah (character data) ...
The trouble here is that the character data cannot be equated with the Act.txt attribute, because in essence, it is occurring both before and after a nested structure, or before and after an inserted hyperlink. Some options to address this include:
• Every contiguous string of character data is an Act. The downside here is that insertion of a hyperlink into a block of text would change what was one Act into multiple Acts, even though logically the integrity of that narrative hasn't changed. We don't typically think of the text before and after a hyperlink as different Acts.
• Define a new MIME-type, to be used in Act.txt, that only contains character data and hyperlinks. The downside here may be that certain link types ARE semantic relationships between Acts that should be modeled as Act_relationships.
• Consider the sum total of character data within a CDA structure to somehow map into the Act.txt field. Thus, in the example above, all the character data contained in the tag would map to Act.txt.
Proposals:
(Diagram 1 is the current representation of CDA in RIM 1.02.
Diagram 2 is the proposed representation of CDA in the RIM.
Diagrams 3 and 4 are a VISIO model of the merged MDM / CDA R-MIM)
• Create a vocabulary domain "ContextLevel" using the values shown above, to be used for the Act_context.level_cd attribute.
• Retire classes from the RIM Infrastructure model - Unstructured_blob, Coded_entry, CharacterData. Each of these classes should be derived from the Act hierarchy, built as an R-MIM and Hierarchical Description, just as CDA currently does with .
• The draft "Merged MDM / CDA R-MIM and Hierarchical Description" model shows how the V3 MDM message will represent nested sections. While we may ultimately be seeking a uniform representation, at a minimum, we'll ensure that a back-and-forth translation between CDA documents and MDM messages carrying non-CDA documents is possible.
Diagram 1: CDA Model, RIM 1.02
Diagram 2: Proposed CDA Model
Attachment C: RMIMs
The following RMIMs represent the state of effort through the Minneapolis meeting, incorporating the decisions made.
-----------------------
[pic]
[pic]
Transfusion Service System
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
Clinical Order Entry System
(HIS)
Clinical Order Entry System
(HIS)
Transfusion Service System
Lab System
(LIS)
Clinical Order Entry System
(HIS)
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- what does the and mean in odds
- what does and mean in betting
- what are periods and groups in chemistry
- include username password in url
- what causes tingling and numbness in toes
- scope for throat and esophagus
- scope of esophagus and stomach
- esophagus scope what to expect
- how to include a file in python
- can you include closing costs in mortgage
- what is debits and credits in accounting
- what to see and do in boston