Td corrigé documentcenter/public/wg/orders/minutes/Minutes-May ... - HL7.org pdf

(1)

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

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

(2)

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

May 2001 Page 2

O&O Minutes

(3)

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@marconi.com 

Michael Aryev Michael.aryev@coulter.com 

Jos Baptist Jbaptist@wxs.ne 

Calvin Beebe Cbeebe@mayo.edu 

Fred Behlen f-behlen@uchicago.edu  

Hans Buitendijk Hans.buitendijk@smed.com         

Tina Buckeye Tina@epicsystems.com     

Jim Case Jtcase@ucdavis.edu       

Howard Clark How_clark@nema.org 

Carmella Couderc Carmella.couderc@smed.com 

Miklos Csore Miklos@wyndgate.com  

Bob Dolin Robert.h.dolin@kp.org 

Jeff DuBois Jadubois@novabio.com 

Tammy Dugan Tdugan@cerner.com  

Dav A. Eide Eide.d@ghc.org        

Becky Fan Cobfan@ihc.com  

John Fehrenbach John@merge.com 

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@deltahealth.com 

Charles Hawker Hawkercd@aruplab.com  

Stan Huff Coshuff@ihc.com 

Dean Ibaraki Dean.ibaraki@kp.org  

Rose Jenkins Rosemarie.jenkins@smed.com        

Dan Jernigan Dbj0@cdc.gov 

Gaby Jewell Gjewell@cerner.com  

Andrzej J. Knafel Andrzej.knafel@roche.com  

Helmut König Helmut.koenig@shs-online.de  

Austin Kreisler Austin.kreisler@itb.mckhboc.com         

Patti Larson Plarson@itxm.org  

K.P. Lee Kp.lee@philips.com 

Andrei Leontiev Andrei_leontiev@idx.com 

Tom Marley t.marley@salford.ac.uk   

Ken McCaslin Kenneth.h.mccaslin@questdiagnostics.com    

Lloyd McKenzie Lmckenzie@la.ibm.com     

Gary Meyer Gary.meyer@pyxiscorp.com   

Claudette Murch Claudette.murch@med.va.gov  

Suzanne Nagami Suzanne.e.nagami@kp.org   

Manish Narang Mnarang@ocdus.jnj.com  

Dale Nelson Dale.nelson@oracle.com 

Karen Nocera Kyn@chord.com 

Herman Oosterwijk Herman@otechiung.com 

Alan Rector Rector@man.ac.uk 

Scott Robertson Scott.m.robertson@kp.org      

Gunther Schadow Schadow@regenstrief.iupui.edu    

Karen Sieber Ksieber@cerner.com       

David Snavely Dav_snavely@nema.org

Allan Soerensen Allan.soerensen@radiometer.dk  

Harry Solomon Harry.solomon@med.gc.com 

Helen Stevens Helen.stevens@itbhboc.com   

Sadamu Takasaka S-takasaka@cp.jp.nec.com  

Timo Tarhonen Timo.tarhonen@tto.fi 

Wayne Tracy Wrtracy@wrt.win.net  

(4)

Attendee Company/E-Mail ^Mon

AM Mon PM Tue

AM Tue PM Wed

AM Wed PM Thu

AM Thu PM Fri

Mark Tucker Mtucker@regenstrief.org 

Bob Uleski Bobul@att.net 

Jason Williams Jwilliams@fast-track.com 

Daphne Young Daphne.young@itb.hboc.com        

Mei Zhang Zhangm@partknicollet.com 

Xiaohan zhou Xiaohan.zhou@kp.org 

Communication with declared O&O participants can be done through ord@lists.hl7.org. You can sign up on this list through HL7’s home page www.hl7.org.

May 2001 Page 4

O&O Minutes

(5)

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:

(6)

 Suggestors, Requestors, Notifiers (3)

 New, revise new, activate, revise active, supercede active, complete, supercede complete, undo complete (9)

 Initiator, Acceptor/Tracker (2)

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.

 New, revise new, activate, preliminary, revise active, supercede active, complete, supercede complete, undo complete (9)

 Initiator, Acceptor/Tracker (2)

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)

3. Lab Event

 New, revise new, activate, preliminary, revise active, supercede active, complete, supercede completed, undo completed (10)

 Request, notify, reject (4)

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.

May 2001 Page 6

O&O Minutes

(7)

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

(8)

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.hl7.org 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

May 2001 Page 8

O&O Minutes

(9)

 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 Accept/Track-

Request Notification-

Activate ORD

EVTINT

Closely

- Loosely RMIM

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

(10)

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 Accept/Track-

Request Notification-

Activate Suspend Resume Abort

Undo

ORD EVTINT

Closely

Initiate Request Suspend

Resume Abort

Order Intent Event

Closely/Loosely Page 170/171 Status – close Status – loose

Initiate Notification Suspend

Resume Abort

Order Intent Event

Closely/Loosely Page 170/171 Status – close Status – loose

Accept Request Suspend

Resume Abort

Order Intent Event

Closely/Loosely Page 172 Accept/Reject – close

Accept/Reject – loose

Reject Request Suspend

Resume Abort

Order Intent Event

Closely/Loosely Page 172 Accept/Reject – close

Accept/Reject Notification Suspend Resume Abort

Order Intent Event

Closely/Loosely

Accept/Reject Request Activate Intent

Event Closely/Loosely

Reject Request Activate Order Closely/Loosely Page 172

Accept/Reject – close

Accept/Reject Notification Activate Order

Intent Event

Closely/Loosely

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

Active Order Loosely Page 167

Intent – loose

Complete Order Closely Page 166

Intent – close

Complete Order Loosely Page 167

Intent – loose

Initiate Notification Supercede

Active Intent Closely Page 166

Intent – close

Active Intent Loosely Page 167

Intent – loose

Complete Intent Closely Page 166

Intent – close

Complete Intent Loosely Page 167

Intent – loose

Initiate Notification Revise Active Intent Closely Page 166

Intent – close

May 2001 Page 10

O&O Minutes

(11)

Initiate - Accept/Track

Request - Notification

Activate Suspend Resume Abort

Undo

ORDINT EVT

Closely

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.

(12)

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.

May 2001 Page 12

O&O Minutes

(13)

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: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

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

(14)

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 <lot/ expiration date/ location/ etc> 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

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) ?????

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

May 2001 Page 14

O&O Minutes

(15)

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) ?????

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) ?????

Definition: This field contains the manufacturer of the service item in inventory.

IIM-6 Inventory Location (CWE) ?????

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) ?????

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: <quantity (NM)> ^ <denomination (ID)>

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.

(16)

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) ?????

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.

May 2001 Page 16

O&O Minutes

(17)

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: <Reference (normal) range (NR)> ^ <Administrative sex (IS)> ^ <Age range (NR)> ^

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.

(18)

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

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.

May 2001 Page 18

O&O Minutes

(19)

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.

Proposal Language

2.8.?? SPS – specimen source

Components: <specimen source name or code (CWE)> ^ <additives (TX vs CWE)> ^ <specimen collection method(TX)> ^ <body site (CWE)> ^ <site modifier (CWE)> ^ <collection method modifier code (CWE)> ^ <specimen role (CWE)>

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: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> ^

<coding system version ID (ST)> ^ alternate coding system version ID (ST)> ^ <original text(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)

(20)

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)

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)

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)

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.

May 2001 Page 20

O&O Minutes

(21)

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.

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

[{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

(22)

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.

OMI message

used Order

Entry

Imaging Department Information System

Imaging Modality (Device)

Imaging Modality (Device) Enterprise

Imaging Department

DICOM

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: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

May 2001 Page 22

O&O Minutes

(23)

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.

Placer Order [Placer Order Number]

Filler Order - Imaging Service Request [Accession Number 1]

Filler Order - Imaging Service Request [Accession Number 2]

Requested Procedure 1

Scheduled Procedure Step 1

Scheduled Procedure Step 2

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)

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)