Minutes of May 2000

Orders/Observations Worksession

Attendee Company/E-Mail Mon AM

Mon PM

Tue AM

Tue PM

Wed AM

Wed PM

Thu AM

Thu PM

Fri

Susan Abernathy Saa6@nipl.em.cdc.gov

Nina August Nina.august@eclipsys.comBob Barker Bobby.barker@smed.com Rita Barsoum Rita.h.barsoum@kp.orgChristian Beale Thomas@deepthought.com.au Fred Behlen f-behlen@uchicago.edu Anita Benson Anita.benson@ey.com Brian Bishop Bebishop@uabmc.edu John Berry Jjberry@mmm.com Kris Bossard Kmbossard@mmm.comChristian Bremeau Bremeau@metaintegration.com Carol Broverman Cbroverm@sprynet.comDenny Briley Dbriley@bdm.caChris Brown Clbrown@quadramed.com Tina Buckeye Tina@epicsystems.com

Hans Buitendijk Hans.buitendijk@smed.com

John Campbell Jjcampbell@computer.orgJim Case Jcase@vols.ucdavis.edu

Carmella Couderc Carmella.couderc@smed.com

Curt Coulter Chc@cbord.com Scott Councilman Scott.councilman@mediware.comIvan Cueric Ivan@alitech.com Carol Delbene Cdelbene@corus.jnj.com Dav A Eida Eida@ghc.org

Bob Etemad Etemadr@musc.eduDavid Feirberg Daferiberg@computer.org Al Figler al_figler@idx.comJohn Firl John.firl@hboc.com John Foy John_foy@idx.comEdgar Glück Edgar.gluck@kith.no Louis R. Gordon Louis_gordon@deltahealth.comLance Griter Lance.griter@hboc.com Paul Gudmundsson Hilmar.p.gudmundsson@kp.orgKenzo Gushiken Kenzo.gushiken@kp.orgDick Harding Hardingr@health.gld.gove.au

Dan Headley Daniel.headley@marconimed.com Mike Henderson Mike.l.henderson@kp.org Rick Horning Rhorning@vmedsys.com John Hornsey Jhorn@doh.health.nsw.gov.au

Lynn Hyde Lynn.hyde@kp.orgAndrew Hinckley Ahinckley@communicationsplanning.ltd.ukPetteri Ihavadnan Petteri.ihavadnan@datex.ohmeda.comRose Jenkins Rose.jenkins@smed.comDan Jernigan Dbj0@cdc.gov

Henk Keesom Hkeesom@ocdus.jnj.com

Page 1 Orders & Observations MinutesCleveland May 2000

Attendee Company/E-Mail Mon AM

Mon PM

Tue AM

Tue PM

Wed AM

Wed PM

Thu AM

Thu PM

Fri

Gunnar Klein Gunnar@klein.seTed Klein Tedk@comermedical.com Andrzej J. Knafel Andrzej.knafel@roche.com Robert Knight Rkinght@lanier.comJoan Kapusnik-Uner

Joan_kapusnik@firstdatabank.com

Denise Koo Dkoo@cdc.gov Eileen Koski Koskie@questdiagnostics.com

Austin Kreisler Austin.kreisler@hboc.com

Tara Larkin Cotlarkin@ihc.comJoann Larson Joann.larson@ncal.kaiperm.org

Bill LeClair Leclair@metaintegration.com Marvin Lerfald Marvin_lerfald@sracom

Ken McCasun Kenneth.h.mccasun@questdiagnostics.com

Clem McDonald Clem@regen.rg.iupui.edu

Maria McHugh Zsa9@cdc.gov Gary Meyer Gary.meyer@pyxiscorp.com Kathy Neugebauer Kathleen.neugebauer@ndcorp.com Karen Nocera Kyn@chord.com

Herman Oosterwijk Herman@otechimg.com Nancy Orvis Nancy.orvis@tma.osd.milJohn Penrose John.penrose@arup-lab.comDavid Pimmel Dpimmel@epicsystems.comDaniel Pollock Dap1@cdc.govDebbie Prather Debbie.prather@hboc.com Denise Rech Interface@amh.orgLowell Reid Lowell.reid@hboc.com

Larry Reis 71045.14@compuserve.com Gail Rice Gail.p.rice@kp.orgTerri Ripley Terri.ripley@centralhealth.comScott Robertson Scott.m.robertson@kp.org

Craig Robinson Craig.robinson@smed.comDebra Routa Debrarouta@hacks.comDavid Rowed Dwrowed@f1.net.auDan Russler Dan.russler@hboc.com

Jerry Sable Sablej@health.missouri.edu Gunther Schadow Schadow@regenstrief.iupui.edu

Karen Sieber Ksieber@cerner.com

Alan Sim Asim@cdc.gov Dwight Simon Dwight@merge.com Jeremy Smith Smithjj@msx.upmc.eduGlenn M. Sperle Gsperle@hcfa.gov Joyce Spindler Joyce.spindler@smed.com

Helen Stevens Helen.stevens@hboc.com

Philip Strong Pcstrong@physicianaccess.comPhil Taggert Phil.taggert@hboc.com Greg Thomas Greg.thomas@kp.org

Alfredo Tirado-Ramos

Atr@philabs.research.philips.com

Wayne Tracy Wrtracy@wrt.win.net

Michael van Campen

Michael.vancampen@moh.hnet.bc.ca

Page 2 Orders & Observations MinutesCleveland May 2000

Attendee Company/E-Mail Mon AM

Mon PM

Tue AM

Tue PM

Wed AM

Wed PM

Thu AM

Thu PM

Fri

Heather von Allmen

Heather.vonallmen@smed.com

Gina Wade Gwade@resis.comMead Walker Andy Whitsitt Awhitsit@epicsystems.com Warner William Wxw4@cdc.gov

Mark Williams Mark_williams@vitalcom.comDaphne Young Daphne.young@hboc.com

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.

Page 3 Orders & Observations MinutesCleveland May 2000

Monday, May 22, 2000V2.x Proposals

Filler’s Expected Availability Date/Time (TS)

This field specifies the date/time the filler expects the services to be available. For example when a prescription is ready for pickup or when a supply will be sent or picked up, or for when a laboratory result is expected to be available.

HL7 Attribute Table - ORCSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

27 26 TS O N ????? Filler’s Expected Availability Date/Time

Vote: favor 10, abstain 2, against 0 - Past.

Original Order Date/Time (TS)This field contains the date/time of the original order (ORC-9) when a refill authorization is being requested. This was represented in the ORC-9 of the original order transaction.

HL7 Attribute Table - RXESEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

32 26 TS O N ????? Original Order Date/Time

Discussion:

Proposal was to add field to ORC, but discussion during meeting established that it this should be in the RXE rather than ORC because it seems to be specific to pharmacy.

Vote: Favor 10, against 0, abstain 0

Charge type Justification

HL7 Attribute Table - BLGSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

4 60 CWE O N 0nnn ????? Charge Type Reason

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

This optional field explains the choice of the charge type identified in BLG-2. Refer to User-defined Table 0nnn – Charge type reason for suggested values.

This field provides the clinical justification/rationale for the selected charge type identified in BLG-2. Such as ‘cho charge’ or ‘bill to research’ charge type as represented in the charge record.

User-defined Table 0nnn – Charge Type reason

Value Description

01 Allergy

Page 4 Orders & Observations MinutesCleveland May 2000

Value Description

02 Intolerance

03 Treatment Failure

04 Patient Request

05 No Exception

Vote: favor 10, abstain 2, against 0 - Past.

Add Order Control Code – OP - Notification of order for outside dispense

Currently there is no way to know that there is an order being placed by an outside pharmacy. The pacing system informing the filling system that the order has been generated, but filler will not fill, just register information.

Use Case:The patient elects to take a prescription to a pharmacy not connected with the Order notification

Notes on HL7 table types.1. Exclusive list that is used to prescribe behavior. HL7 Table2. Minimal list that site can add values to. User Table

OBR-45 Procedure Code Modifier field note adjustment

HL7 Attribute Table - OBRSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

4445

250250

CECE

OO

NY

00880340

0039301316

Procedure CodeProcedure Code Modifier

4.4.3.44 OBR-44 Procedure code (CE) 00393

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 contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to User-defined Table 0088 - Procedure code for suggested values. This field is a CE data type for compatibility with clinical and ancillary systems.

4.4.3.45 OBR-45 Procedure code modifier (CE) 01316

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 contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as HCFA and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to User-defined Table 0340 - Procedure code modifier for suggested values.

Page 5 Orders & Observations MinutesCleveland May 2000

Usage Rule: This field can only be used if OBR-44-procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example HCPCS codes that require a modifier to be precise.

Vote: for 9, against 0, abstain 1

Advanced Beneficiary Notice Override Reason

HL7 Attribute Table - OBRSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

?? 60 CWE C N ????? Advanced Beneficiary Notice Override Reason

Definition: This field contains the reason why the patient did not sign an Advanced Beneficiary Notice. The reason may be coded or it may be a free text entry.

Condition: This field is required if ORC-20 (Advanced Beneficiary Notice Code) indicates the patient did not sign the Advanced Beneficiary Notice with a value of 3 or 4 (based on User defined table xxx values documented in HL7 specification).

Vote: for 9, against 0, abstain 1

Medically necessary duplicate procedure

HL7 Attribute Table - OBRSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

?? 1 ID C N 00136 ????? Medically Necessary Duplicate Procedure

Definition: This field contains an indicator reporting that the procedure contained in OBR-44 (Procedure Code) is a duplicate of one ordered/charged previously for the same patient within the same date of service and has or has not been determined not to be medically necessary. Refer to HL7 Table 0136 -Yes/No Indicator in Chapter 2. A value of Y (Yes) in this field indicates that the procedure is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. A value of N (No) in this field indicates that the procedure is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined not to be medically necessary.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Condition: If the sending systems knows OBR-44 (Procedure code) is a duplicate of a procedure ordered/charged previously for the same patient within the same date of service, then this field is required.

Withdrawn by submitter.

Page 6 Orders & Observations MinutesCleveland May 2000

Medically Necessary Duplicate Procedure Reason

HL7 Attribute Table - OBRSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

?? 60 CWE C N ????? Medically Necessary Duplicate Procedure Reason.

Definition: This field is used to document why the procedure found in OBR-44 (Procedure Code) is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-defined table xxx for suggested values.Value Description

Vote: for 9, against 0, abstain 1

HL7OBR28Comment.doc (Dav Eide)

Remove the OBR-28 repetition limit from field 00260 in the next release.

Vote: for 12 , against 0, abstain 1

HL7AdminMethodProposal.doc

Discussion that making the table user defined would change data type form IS to ID and this would not be backward compatible.

Discussed that this should never have been made an HL7 defined table as this is not a complete list. For example, Inhalant and transqutaneous and swallow not included.

Options available include: Change the data type to CE that would allow for user-defined tables? Direct to vocabulary to establish complete list Change data type to ID and change table from HL7 Defined to User Defined.

Motion to undo a mistake from previous standard and change the table from HL7 to User Defined as there are obviously many values that are not included in the table. This applies to

HL7 Table 0162 - Route of administration,HL7 Table 0163 - Body Site,HL7 Table 0164 – Administration Device HL7 Table 0165 – Administration Method;

all used in RXR. This would change the minimally the RXR fields from ID to IS data types. This is required at the earliest possible time and will be included in the next ballot (2.4 or 2.x). Direct that the O/O chairs at the earliest possible review all HL7 tables contained in chapters 4, 7 & 13 and change to User Defined tables if value sets are clinical content.

Vote: for 11, against 0 , abstain 1.

Page 7 Orders & Observations MinutesCleveland May 2000

Motion: If field has been defined as CE data type and table type is HL7, then table should be technically corrected to User Defined and values identified as suggested set allowing for expansion. O/O chairs/editors to make 2.4 corrections.

Retraction of previous motion as it is included in this motion.

Vote: for 12, against 0 , abstain 0.

OBX-12ModificationProposal4.doc Effective Date of Reference Range Values

HL7 Attribute Table - OBX

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

12 26 TS O N 00580 Date Last Obs Normal Values Effective Date of Reference Range Values

Definition: This field contains the changes in the observation methods that would make values obtained from the old method not comparable with those obtained from the new method.

Null if there are no normals or units. If present, a change in this date compared to date-time recorded, the receiving system’s test dictionary should trigger a manual review of the results to determine whether the new observation ID should be assigned a new ID in the local system to distinguish the new results from the old.

Definition: This field contains the date (and, optionally, the time) on which the values in OBX-7-reference range went into effect.

Usage Rule: This field can be valued only if OBX-7-reference range is populated.

When this field is present, it facilitates comparison between identical results with different reference ranges. Reference range values may vary because of changes in laboratory practice over time. Such variances could reflect updated practice in laboratory medicine, or the use of updated instrumentation.

Vote: for 12, against 0, abstain 1.

Drug Strength Volume

Add two new fields to the RXA, RXC, RXD, RXE, RXG and RXO segments:

Discussion:

Discussion of if this is already supported by the Units definitions in OBX:6 that apply to all Units fields.

Should we add support for 2nd method to send this information (because existing algebraic expression is complicated), or should we simplify (or improve examples) of OBX:6 definition?

Do we need a new data type for ‘units’ that allows for the algebraic expression to be sent in multi components?

HL7 Attribute Table - RXA

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

?? 5 NM O N ???? Administered Drug Strength Volume?? ?? CE O N ???? Administered Drug Strength Volume Units

Page 8 Orders & Observations MinutesCleveland May 2000

HL7 Attribute Table - RXC

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

?? 5 NM O N ???? Component Drug Strength Volume?? ?? CE O N ???? Component Drug Strength Volume Units

HL7 Attribute Table - RXD

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

?? 5 NM O N ???? Actual Drug Strength Volume?? ?? CE O N ???? Actual Drug Strength Volume Units

HL7 Attribute Table - RXG

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

?? 5 NM O N ???? Give Drug Strength Volume?? ?? CE O N ???? Give Drug Strength Volume Units

HL7 Attribute Table - RXO

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

?? 5 NM O N ???? Requested Drug Strength Volume?? ?? CE O N ???? Requested Drug Strength Volume Units

X Drug Strength Volume

Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solution with a volume of 5 ML and the solution form is elixir. Other examples include, 100 Units of Iletin is in 1 ML of solution.

X Drug Strength Volume Units

Description: This field indicates the volumetric unit of measurement for the body in which the drug strength volume is maintained, for example ML.

Motion to accept fields in concept to segments listed with field names adjusted for each segment. Specific wording will be reviewed prior to publication with input from industry databases.

Move OBX:6 Units definitions to 7.1.6 section. Add field note to all Units fields to reference 7.1.6 (if don’t already exist) and deprecate use of ‘algebraic’ expression.

Vote: for 11, against 0, abstain 1.

Further review of the First Data terminology has confirmed the use of the term “volume” for this application. This removes the specific wording issue from motion above.

Add two new fields to the RXO and RXE segments:

1. Multi-item Order Link Relationship – which define the relationship of the order messages to each other.

2. Multi-item Order Link Number – which defines an identifying number for the administration/order session as opposed to the placer number which defines an identifying number for the order..

Page 9 Orders & Observations MinutesCleveland May 2000

HL7 Attribute Table - RXO

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

25 IS O Multi-item Order Link Relationship26 EI O Multi-item Order Link Number

Discussion:

Change names of fields to Associated Order Group Relationship (IS) and Associated Order Group Number (EI).

Add values and explanations to table:

User Defined Table xx – Associated Order Group Relationship

Value Description

N Nurse prerogative (give/take whichever orders nurse wants [all, none, some] )C CompoundT Tapering / Successive (give/take after the other)E Exclusive (give/take one or the other)S Simultaneous (give/take at same time)

These fields could apply to the Placer or Filler and are a mechanism to relate external orders. There are two needs, first to setup a link between the orders, secondly to describe the relationship that the link represents.

Is this a ‘linking’ of an order to another, or is it in fact a grouping of multiple orders? Determined that the intent was to actually group orders at the time of ordering – however, it is felt that there may be valid use cases to link orders to existing orders.

Kaiser has submitted other proposal to add a “Filler Group Number” field to match the ORC-4-Placer Group Number. Does this have the same requiements?

This might be already supported by the TQ data type and ORC-7.

Submitter tables proposal to reevaluate if this can be done with TQ data type or if an enhancement to TQ is required instead of additional fields.

4.12.5 RDE - pharmacy/treatment encoded order message (O11 or O01)

Include the NTE, FT1 and BLG segments in the message schematic.RDE^O11^RDE_O11 Pharmacy/Treatment Encoded Order Message ChapterMSH 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]{

Page 10 Orders & Observations MinutesCleveland May 2000

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 (for RXO) 4 [{NTE}] Notes and Comments (for RXC) 2 ] ] RXE Pharmacy/Treatment Encoded Order 4 [{NTE}] Notes and Comments (for RXE) 2 {RXR} Pharmacy/Treatment Route 4 [{RXC}] Pharmacy/Treatment Component (for RXE) 4 [{ OBX Results 7 [{NTE}] Notes and Comments (for OBX) 2 }] [{FT1}] Financial Detail 6 [BLG] Billing Segment 4 {[CTI]} Clinical Trial Identification 7}

Vote: accept 10, against 0, abstain 1.

Discussion: Representation of OBX was incorrect in the 2.4 ballot and has been corrected as follows:

Before:{ [OBX] Results 7 [{NTE}] Notes and Comments (for OBX) 2}

After:[{ OBX Results 7 [{NTE}] Notes and Comments (for OBX) 2 }]

Vote: accept 10, against 0, abstain 1.

Page 11 Orders & Observations MinutesCleveland May 2000

Tuesday, January 25, 2000RIM Harmonization and Review

Gunther Schadow reviewed the outcome of the RIM Harmonization session. The following topics required further review by the committee.

Service.recording_dttm – The name was changed to Service.availability_dttm since the time the information is known on a system is what really counts. There remained a sense of fuzzy definition. A sense that delayed availability should not be mixed with the forensic reconstruction.A motion was made to drop service.availability_dttm altogether from the RIM. Other times on the Service or Service Actor could deal with this appropriately. If future use cases support a renewed need that is clear, we’ll reconsider putting it back in.

Vote: accept 15, against 0, abstain 10.

Actor.Type_Cd – General discussion reached a consenses to soften the language in the Actor Types table to ensure it is not implied that certain codes are mandatory to exist at least once for a Service instance. This may vary by mood or be message specific. Based on HIPAA requirements an additional actor type may be necessary to support communication on who viewed what patient data when.

We recognized that Lab Automation and Image Management use various different times that require tracking. Lab Automation Samples:

1. Analysis Time2. Event Time – related to equipment3. Registration Time – related to material collection4. Expiration Time5. First Use Time6. Requested Completion Time7. Comment Complete Time

Image Management Samples:1. Content Time – Time document content creation started.2. Verification Time -

The respective SIGs will further explore these needs and put forth proposals as necessary to add any additional times.

Service.instructions_txt – This attribute was rejected by the harmonization team with the argument that service.text could already handle this. We discussed three options:1. Use Service Relationship and dedicated service codes to cover instructions, e.g., patient

instructions, pharmacy instructions, etc. This allows for using hierarchies, etc.2. Create separate class for text to allow for repetition and purpose code.3. Add note attribute to the Target class and use notes accordingly.Most people gravitated towards option 1. We agreed to pursue this through creation of use cases and expressing them in option 1. Daphne Young, Scott Robertson, and Austin Kreisler volunteered to create use case to pursue using service relationship to express multiple services. Post to list server.Need to clarify the use of the service.text attribute.

Normal Ranges – This attribute was rejected by the harmonization team as this could be achieved using already available structures. Since to date most examples have been complicated creating a sense of high complexity, we agreed that introduction of simple examples would better illustrate that the structures that enable complicated situations, are in itself not complex. We accepted the rejection. Gunther Schadow will include a simple example.

Page 12 Orders & Observations MinutesCleveland May 2000

Harmonization Issues ReviewThere are 33 open issues associated with the Orders & Observations classes/associations. These can be categorized as follows. For each category the follow-up/closure strategy is listed.

Accident Information SourceWe will leave the issue open for future review.

Container – Various FieldsThese issues require review by Lab Automation SIG first and then consolidated in joint review.

Diet – Carbohydrate_qtyWe will address these as we go through Dietary messages.

MedicationWe will address these as we go through Medication messages.

Observation – derivation_exprThis issue is being dealt with through Arden Syntax TC.

Patient EncounterThese issues are dealt with by other groups.

ReferralWe will address these as we go through Referral messages.

Service – status_cdWe will address this through the definition of messages in general. definition.

Service – textThis issue is being addressed through the follow-up necessary for service.instruction_txt.

Various Service AssociationsWe will wait for other issues to resolve, e.g., left-hand-side-of-the-RIM, before we address the association issues to avoid double work.

Therapeutic_agent.We will address this later.

Message Definition CriteriaWe reviewed criteria to determine when to create a new message vs. using an existing message. We agreed to take the following initial approach that will be refined as we define actual messages: Use the V2.x Order Control Codes, blend them with Order and Result Status Codes (ORC, OBR,

OBX), and create two lists of trigger events: one for Orders and one for Observations. Use the V2.4 Messages and categorize them by domain expertise, e.g., Lab, Rx, etc.. Create a matrix with the above lists as the respective axes (trigger events constitute the rows,

domains the column headers. Identify for each trigger event row whether to initially create one or more message per domain, or

one generic one. For example, a new order likely requires one or more messages per domain, whereas a cancel or a response could be one generic message across all domains.

Start the definition of messages one column at the time. After the first one/two we could have individual groups create proposed messages for the subsequent columns.

Gary Meyer, Scott Robertson, Austin Kreisler, and Hans Buitendijk will create a first cut of this Orders & Observations Message Matrix and post it to the ord_list.

Lab Order MessageGunther initiated the discussion to get the first set of messages defined. He stepped us through the State Transition diagram we will be using. We concluded that the following State Transition Diagram provides the backdrop for creating order messages:

We agreed to incorporate these state transitions into the Orders & Observations Messages Matrix. We also agreed on the following approaches:

Page 13 Orders & Observations MinutesCleveland May 2000

Create interaction diagram after the Orders & Observation Message Matrix is done to show between requester and provider what direction messages can flow.

Agreed to use the replacement approach when changes to an order/observation occur, rather then an incremental approach. If we want to have incremental changes in certain situations, that would have to be clearly denoted in the message definition and yield a new definition.

The message discussion was to be picked up again on Thursday.

PHCDM ModelAbdul-Malik Shakir and Mead Walker presented the model that was developed by the CDC for their message implementations. The objective was to reconcile conceptual differences where feasible.

Living Subject and Material classes were generally discussed, but referred to tomorrow. CDC intents to follow the outcome of the HL7 discussion as long as Living Subject remains an identifiable concept.

The CDC requested to consider Case, and Outbreak to be specialization of Condition Node or Episode. Advantage of Condition Node is ability to use mood code of definition as necessary.

We agreed that organization specific use of terminology and adjustments in classes is the responsibility of the respective organizations. They may apply these adjustments to improve acceptance by their specific constituents. It is not the responsibility of the HL7 organization to reflect all these naming adjustments.

After discussing the Notification class, the CDC agreed to explore more the reason codes and structure before suggesting specific changes.

Medication/Intervention: CDC will post their approach on the list server. Next meeting dedicated time to resolve as part of the Pharmacy Order/Administration message discussions.

We agreed that for Material Responsibility HL7 will adopt CDC name. CDC will prepare necessary documentation for the Harmonization meeting.

We agreed to include a name attribute in Material. CDC will prepare necessary documentation for the Harmonization meeting.

The CDC will revisit address/telecommunication with Control/Query. The CDC will review with PAFM the Facility and Material concepts. We need to schedule time to resolve Location between OO, PAFM, PC, and Scheduling. (Lab

Automation, Community).

Page 14 Orders & Observations MinutesCleveland May 2000

Wednesday, January 26, 2000Living Subject

Jim Case reviewed the most current proposal to address incorporation of the living subject concepts into the RIM 95. The following diagram summarizes the proposal that was made:

Various suggestions were made to make adjustments to the structure that were forwarded to additional discussion that occurred in various follow-up discussions outside the meeting. These results will be shared as they are further refined. We agreed that Jim Case would continue further discussions to enhance the proposals prior to Harmonization. A motion to move forward as accepted with 13 in favor, 0 against, and 6 abstentions.

ReferralsAt the January, 2000, TSC meeting there was agreement that Orders & Observations would take on Referrals and work with Patient Care to address the necessary RIM and message requirements.The Chapter 11 messages can be categorized as follows:

Information RequestsMessages focused on obtaining demographic and insurance information to support referrals.

Treatment AuthorizationMessages focused on obtaining authorization information for treatment.

Referral messagesMessages focused on requesting and updating referrals.

We agreed that messages related to the first two types of messages are likely already addressed in other areas. Information requests are probably already considered through PAFM (requires confirmation) and Treatment authorization messages will fall likely within the X12 area (requires confirmation). We therefore agreed to put these two sets on the backburner and concentrate on the referral message. We agreed to add these referral messages to the Orders & Observations Message Matrix.

Page 15 Orders & Observations MinutesCleveland May 2000

Lab Automation - MaterialsWe reviewed with the Lab Automation SIG various questions and issues as they move forward with their V3.0 discussions.

We agreed that a review of the attributes considered would best take place on the list server. There is a sense that USAM can address the concept of index units. We agreed that the following Lab Automation concepts can map to the Services class:

1. Event Class2. Notification Class3. Interaction Class4. Command – The service mood would be Order

We suggested to check out status codes to address the Interaction Active State concept, possibly requiring a new class.

We suggested considering Parameters a type of instructions.

Through the discussion it became clear that V3.0 query syntax requires further definition to address certain V2.x messages. This request will be forwarded to the appropriate committees.

Page 16 Orders & Observations MinutesCleveland May 2000

Thursday, January 26, 2000Message Development

We completed the review of the State Transition Diagram. Through the discussion it became clear that state transitions from “in progress” to “complete” required further refinement and additional transitions. The following diagram summarizes the outcome of the discussion.

Further work is required to better define the concept of “preliminary”. Prior to completion, preliminary data may be available on an observation.

We agreed to incorporate these states into the Order & Observation Message Matrix.

General Observation Reporting MessageWe agreed to keep the message simple and stay closer to V2.x to start to attain functional equivalency from which then to build additional capabilities.

Service Relationship Component – We agreed to drop everything except sequence_nmb and typ_cd for the observation message.

We agreed to only use normal range text rather then extended capabilities of structured ranges. We agreed to maintain one level of service relevant data and keep it separate from the observation

event. Further discussion is required to understand how observation event data, e.g., status, cause the right

associated order to change state. It is felt the actual change is an application’s responsibility, but that the relationship with the request event from the observation directly or its parent will enable the application to do so. If the order stub is present, the information on the observation event can be used to infer state changes on the order instance.

An open issue is when a requirement for more order information on an observation message requires more attributes/classes in the same message or a new message.

If a reflex or other additional order is required, the filler can initiate a message with a service intent to notify the original placer and establish a service request and references.

We agreed to maintain the Observation Master/Relationship class to enable explicit reference to a master entry. Note that the observation_event:service_cd and observation_master:id can be different or the same. In the latter case it may not be carried.

After reviewing microbiology specific issues we concluded that the message with microbiology incorporated could serve as the general observation message.Vote: accept 11, against 0, abstain 5.

We agreed to start the message with the patient.

General Observation Order Message We agreed that an order message can only have one author. We agreed to separate out Service Actor Verifier for the message.

Page 17 Orders & Observations MinutesCleveland May 2000

We agreed that an order would be communicated once verified, or marked as verbal, phone, etc. We need an attribute to indicate that an order was verbal, phone, fax, etc. We need an attribute/concept for pre/post-authorization numbers.

We agreed that Curt Coulter, Gary Meyer, Austin Kreisler, Heather von Allmen, Dan Russler, Gunther Schadow, and Scott Robertson would continue discussions prior to the September meeting to further refine these messages.

Page 18 Orders & Observations MinutesCleveland May 2000

Version 2.4 Comments for ReviewNegative Ballots Chapter 4/7

Clem McDonaldSection 4.4.3.46 and Section 4.4.3.47

The idea of having supplemental ordering information is understandable. Different systems have different styles for structuring their order codes. For example, a system may have a code for femur xray and allow the specification of the right and left side by an additional code. However, the particulars in this table are such a mis-mash that this proposal will reduce the inter-operability of different systems and the suggestions for alternative code systems are worse. (E.g., there is no micro-glossary in SNOMED for radiology, and I understand no work has been done. Further, when it is produced it may really define order codes not modifier codes.)

Specific criticisms of table 0411. I have many problems with this table as it is proposed. First, it is focused solely on the needs of radiology reporting, but is being proposed as a table for all of ordering. Secondly, its genesis is partly from the HCFA coding modifiers. HCFA has added required modifies for Right and Left, but it also has modifiers to identify the individual fingers and toes. HCFA uses 20 distinct modifiers (one for each finger and toe) not the five modifiers listed here. The table includes some of the variants for specifying position with respect to gravity (E.g., upright) but not the others - prone, supine, etc. It includes a modifier for Pediatric (a common part of the name of radiology tests for billing purposes because often more of the body can be obtained with less film), but the birth date defines “pediatric”. Furthermore, we have just completed a review of more than 13 hospitals reporting and billing codes for radiology and most of them have pre-coordinated the distinctions being described in the above.

Thirdly, these would be an invitation for contradictory orders without additional structure to define what modifiers are allowed with what tests.

Fourthly, this does have some relationship to the procedure code modifier listed in section 4.4.3.45. The procedure modifier came from HCFA but don’t know if they are the CPT 2000 modifier codes because can’t see the table. This has an obvious overlap with the listed purpose of this field, indeed it includes some of the same values, but I believe is intended only for billing purposes as is the procedure code

So, I would accept leaving the fields in – to serve as escape valves for needs that arise. But think we should remove the specific suggested table because it is too irregular and too specialized and it invites criticism and mis-use. In the body of the text we could mention some of the possible uses that are listed in the table, should mention the HCFA modifier codes in the body of the text, and should remove reference to anything that does not yet exist.

I would suggest the following revisions.

1) Making this a user defined CE coding sytem. Resolution: A motion was made to make this field user defined, CE, with a table with no suggested values.Vote: accept 13, against 0, abstain 0.

2) Replace the last sentence in 4.4.3.46 with the following:

“On the ordering side, this field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions). The HCFA CPT modifiers could also be used as codes in this field.”

Version 2.4 May Ballot Review Page 19

Resolution: A motion was made to replace the sentence as requested with the following modifications: “This field can be used to describe details such as whether study is to be done on the right or left, for example where the study is of the arm and the order master file does not distinguish right from left or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).” Vote: accept 13, against 0, abstain 0

3) Add a code for CPT modifier in Table 0396 of Chapter 7 just below CPT4 as follows:

CPT Modifier Code CPTM Available for the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL).

Resolution: A motion was made to add the entry as suggested.Vote: accept 14, against 0, abstain 0.Further discussion indicated that the location of table 0396 may be adjusted in accordance with new editing rules to enhance readability of large tables within text. This is considered a technical edit.Resolution: A motion was made to support the editing rules that indicate “if a table spans more then one page and readability will be enhanced, it will be moved to the end of the chapter and a hyperlink will be inserted in the originating point of reference for easy navigation.”Vote: accept 14, against 0, abstain 2.

4) Replace the last two sentences of 4.4.3.47. The uses of this field are parallel to 4.4.3.4.1. See the discussion above.

Resolution: A motion was made to make these sentences the same as was agreed upon under 4.4.3.46.Vote: accept 14, against 0, abstain 2

5) The same changes should also occur in Chapter 7 page 7-38 where these two also appear.

Resolution: A motion was made to make the same changes in Chapter 7 as appropriate in the context of Chapter 7.Vote: accept 15, against 0, abstain 1

Negative Ballot: With these votes, the negative vote was withdrawn.

4.4.1.5 – Order Status Modifier -- Negative

We currently have real problems with the receipt of ORU messages that fail to use the order status as it is currently defined (e.g., they do not report corrections which require special processing at the medical record receiving end). Including an order status modifier that is user defined would only exaggerate this problem and create new inter-operability problems. Either this field has to be much more tightly defined to avoid any collision with the current

Version 2.4 May Ballot Review Page 20

requirements of interoperability or it should be removed. I would be much more accepting of a fully specific order status modifier with prespecfied codes to accommodate the additional needs described in this field.

Resolution: A motion was made to insert language to indicate it can only be valued if ORC.5 is valued.Vote: accept 15, against 0, abstain 0.

Resolution: A motion was made to change the data type from CE to CWE.Vote: accept 15, against 0, abstain 1

With these adjustments, the negative ballot was withdrawn.

Version 2.4 May Ballot Review Page 21

Name Sect V T Existing Wording Proposed Wording CommentsKaiser 4.2 N M

i . . . . The components of a single quantity/timing specification are described in Sections 4.2.1, “Quantity component (CQ),” through 4.2.10, “Order sequencing component (CM).”

. . . . The components of a single quantity/timing specification are described in Sections 4.2.1, “Quantity component (CQ),” through 4.2.12, “Total occurrences component (NM). ”

Additional sections in standard not reflected in text of this sectionResolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 0

Kaiser 4.2.2 N Mi Subcomponents: <repeat pattern (IS)> ^

<explicit time interval (ST)>Subcomponents: <repeat pattern (IS)> & <explicit time interval (ST)>

Note: The component delimiter in this CM is demoted to a subcomponent delimiter.

As a multi-component sub-component of TQ, the component delimiter in the CM should be demoted to a subcomponent delimiterResolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 0

Kaiser 4.2.11

N Mi Subcomponents: <identifier (ST)> ^ <text (ST)>

^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system>

Subcomponents: <identifier (ST)> & <text (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system>

Note: The component delimiter in this CE is demoted to a subcomponent delimiter.

As a multi-component sub-component of TQ, the component delimiter in the CM should be demoted to a subcomponent delimiterResolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 0

Frank Oemig

4.3.1 N Mj

Thus please replace “???” by the following sequence: “<”, “OBR”, “|”, “RQD”, “|”, “RQ1”, “|”, “RXO”, “|”, “ODS”, “|”, “ODT”, “>”.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 1

Version 2.4 May Ballot Review Page 22

Name Sect V T Existing Wording Proposed Wording CommentsFrank Oemig

4.3.2 N Mj

Replace “???” by the following sequence: “<”, “OBR”, “|”, “RQD”, “|”, “RQ1”, “|”, “RXO”, “|”, “ODS”, “|”, “ODT”, “>”.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 1

Frank Oemig

4.3.3 N Mj

Replace “???” by the following sequence: “<”, “OBR”, “|”, “RQD”, “|”, “RQ1”, “|”, “RXO”, “|”, “ODS”, “|”, “ODT”, “>”.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 1

Kaiser 4.3.7 N Mi

ORL^O02^ORL_O?? ORL^O22^ORL_O22 Trigger event has been changed to O22 in this ballotResolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 0

Kaiser 4.5.2 N Mi Phone Call Queries (Q01) Examples 1

and 2 (page 64)

Replace with v2.4 query which Frank Oemig has already developed with Mark Tucker’s support

We probably do not want to establish new queries using the old-style methodology since this is being deprecated. (See chapter 5). This was probably an oversight since changes were made in response to the last ballot.

Resolution: See Affirmative Comments resolution on 4.5.2 for complete review.

Kaiser 4.9.1 N Mj/Q

RQD[{NTE}]

RQD[RQ1][{NTE}]

4.9 Indicates that, for stock supplies, “the sending application . . . may optionally send an RQ1 along with the RQD.” However this is not reflected in the message structure in 4.9.1. Resolution: Motion to accept the suggested changes as-is was made for 4.9.1.Vote: accept 14, against 0, abstain 0Resolution: Motion to accept the suggested changes as-is was made for 4.9.2 as well.Vote: accept 14, against 0, abstain 0

Version 2.4 May Ballot Review Page 23

Name Sect V T Existing Wording Proposed Wording CommentsKaiser 4.11.

1, 4.11.2

(with ref to 4.9.1, 4.9.2)

N Mi/Q

MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||ORM|100|P|2.2||<cr>

MSH|^~\&|ORSUPPLY|ORSYS|MMSUPPLY|MMSYS|19911105131523||OMS|100|P|2.2||<cr>

Should both examples be updated to use OMS and/or OMN rather than ORM. HOWEVER, note that OMS and OMN do not support RQD/RQ1 repetitions within one ORC as defined in 4.9.1 and 4.9.2(The time required to resolve this may warrant rolling into the next revision, 2.x)Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 1Resolution: Motion was made that all examples will be reviewed by Austin Kreisler and Scott Robertson for legal syntax. Findings would be posted to the list server to ensure no meanings are changed. Any fixes would be treated as technical edits.Vote: accept 15, against 0, abstain 0

Resolution: A motion was made that, as time permits, the field definition format would be adjusted to clearly separate Definition, Example, Usage Rule, and Conditionality. No content changes would be made, rather only insertion of the headers where appropriate.Vote: accept 15, against 0, abstain 0.

Kaiser 4.13.5.2

N Mi/Q

Note: The contents of RXD-2-dispense/give code should be identical to the comparable field in the RXE (RXE-2-give code). The RDS message refers ONLY to the dispensing of the drug or treatment by the pharmacy or treatment supplier.

Note: The contents of RXD-2-dispense/give code should be compatible with the comparable field in the RXE (RXE-2-give code). The RDS message refers ONLY to the dispensing of the drug or treatment by the pharmacy or treatment supplier.

Depending on the code system used in RXE-2 and RXD-2, it is permissible for the two not to be identical. For example, if RXE-2 is encoded with an NDC number, and generic substitution is allowed, the RXD-2 need not be identical but must be generically equivalent.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 14, against 0, abstain 1

Kaiser 4.13.5.26

N Mj

RXC-26 Initiating location (HD) 01477 RXD-26 Initiating location (CE) 01477

Since submitting our original proposal, we have come to the realization that we need to be able to transmit both the local and the enterprise identifier for the initiating pharmacy. A second option

Version 2.4 May Ballot Review Page 24

would be to make the data type EI and make the field repeat.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 13, against 0, abstain 2

Kaiser 4.13.5.27

N Mj

RXC-27 Packaging/assembly location (HD) 01478

RXD-27 Packaging/assembly location (CE) 01478

Since submitting our original proposal, we have come to the realization that we need to be able to transmit both the local and the enterprise identifier for the packaging/assembly pharmacy. A second option would be to make the data type EI and make the field repeat.Resolution: Motion to accept the suggested changes as-is was made.Vote: accept 13, against 0, abstain 2

Peter Rontey

4.16.2

N Mj

<patient social security number> ~ <patient birth date> ~ <patientbirth state> ~ <patient birth registration number> ~ <patient medicaid number> ~ <mother's name last^first^middle> ~ <mother's maiden name> ~<mother's Social Security number> ~ <father's name last^first^middle>~ <father's Social Security number>

<patient social security number> ~ <patient birth date> ~ <patientbirth state> ~ <patient birth registration number> ~ <patient medicaidnumber> ~ <mother's name last>~< mother's name first>~< mother's namemiddle> ~ <mother's maiden name> ~ <mother's Social Security number> ~<father's name last>~< father's name first>~< father's name middle> ~<father's Social Security number>

QRF segment, QRF-5-other query subject filter is by definition a> repeating ST (string) field (5.9.5.4). The suggested encoding deviates from that definition with the 6th and 9th repeating elements, each of which represents a composite element of undetermined data type.Such a construct will not parse correctly in many parse engines. It seems that this violation of encoding rules is unecessary. Each of these repeat elements represent discrete parameter values (not really repeated elements), so why not simply make each of the name components another named ST (string) parameter (just as curiously enough <mother's maiden name> is)?Resolution: A motion was made to not consider this suggestion for V2.4 as it pertains to material not part of the ballot. However, the suggestion does warrant further review/discussion and therefore should be brought forward as a V2.x proposal.Vote: accept 14, against 0, abstain 0This suggestion will be put on the V2.x agenda for further review.

Version 2.4 May Ballot Review Page 25

CDC 4.17 N Mj

Cut/paste did not work well because formatting was lot or changed. I am attaching a zipped version of the entire Chapter 4, but our revisions only affect Section 4.17. We have changes throughout Section 4.17 that were previously submitted but were not made or were made incorrectly. We submitted the CVX table exactly as it should be published, but it appears to have been re-typed with errors and omissions. If published this way, it would reflect negatively on us. Please ensure that everything in the table and the usage notes is exactly as submitted. If possible, please paste this version into the file rather than retype or try to correct the old one.

We have used revision marks in the attached zipped file. Our additions are colored red to make them easier to see.

Previously submitted revisions were not incorporated correctly. Resolution: The correct text should have been there. The editor will fix this to incorporate as submitted by CDC originally. After review of the revisions as a final check the motion was put forth to fix per the original submission.Vote: accept 14, against 0, abstain 0

Peter Rontey

4.18.1

N Mj

MSH|^~\&||GAVACREC||AZVACREC|199505221605||VXQ^V01|950522GA40|T|2.4|||AL<cr>QRD|199505221605|R|I|950522GA40|||1000^RD|JONES^JOHN^RICHARD|VXI|SIIS<cr>QRF|AZVACREC||||256946789~19900607~CA~CA99999999~88888888~JONES^MARY^SUE~ 898666725~JONES^MATHEW^LEE~822546618<cr>

MSH|^~\&||GAVACREC||AZVACREC|199505221605||VXQ^V01|950522GA40|T|2.4|||AL<cr>QRD|199505221605|R|I|950522GA40|||1000^RD|JONES^JOHN^RICHARD|VXI|SIIS<cr>QRF|AZVACREC||||256946789~19900607~CA~CA99999999~88888888~<JONES>~<MAR> Y>~<SUE>~ 898666725~<JONES>~<MATHEW>~<LEE>~822546618<cr>

Related to issue #1 above (4.16.2)Resolution: This issue will be reviewed as part of V2.x to synchronize with the suggestions for 4.16.2

Kaiser 7.4.2 N Mj

OBX|1|CE|71020&IMP^RADIOLOGIST'S IMPRESSION|4||^MASS LEFT LOWER LOBE|1||A||F<cr>

OBX|1|CE|71020\&IMP^RADIOLOGIST'S IMPRESSION|4||^MASS LEFT LOWER LOBE|1||A||F<cr>

Per Section 2.8.44, an escape delimiter is required prior to the use of the subcomponent separator & in component 1 of a CE data type, as component 1 is of type ST. An alternative correction would be to use a different subcomponent separator in the message. Either usage should be commented on, as the use of & in this kind of observation code is fairly common.Resolution: The suggestion and vote were withdrawn. The use of the “&” reflects long-term utilization. Kaiser

Version 2.4 May Ballot Review Page 26

will further review and determine appropriate follow-up.

Japan 8.4.1.1

N S HL7 Table 0175 HL7 Table 0175

Value : OMXDescription : Observation master file not specified

It hopes that OMA, OMB, etc. can be globally handled at a time.About the problem and the proposal, attached sheet reference.(PROP872.doc)Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Japan 8.7.2 N Mi

Note: MFN^M03 is retained for backward compatibility only

MFI-1-master file identifier = OMA, for numeric observations (second component of MSH-9 - message type = M08).[ [OM2] Numeric Observation Segment [OM3] Categorical Service/Test/Observation Segment [OM4] Observations that Require Specimens]

MFN^M08

second component of MSH-9- message type = M09

MFN^M09

second component of MSH-9-message type = M10

MFN^M10

second component of MSH-9-message type = M11

MFN^M11

second component of MSH-9-message type =

MFI-1-master file identifier = OMA, for numeric observations.[ [OM2]Numeric Observation Segment [OM3] Categorical Service/Test/Observation Segment [{OM4}] Observations that Require Specimens]

MFN^M03

MFN^M03

MFN^M03

MFN^M03

MFN^M03

It is not the best way to include the information related to the contents of the message such as the result type of observation in the MSH segment.

The observation master file is often managed regardless of the result such as a numeric type and a categorical type. Therefore, summarizing it for the trigger event M03 is more useful than using MSH extensively by using the trigger event of M08-M12.Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Version 2.4 May Ballot Review Page 27

M12

MFN^M12

Japan 8.7.2 N S MFI-1-master file identifier = OMX, for none specified observations. It is handled globally.[ [OM2] Numeric Observation Segment [OM3] Categorical Service/Test/Observation Segment [{OM4}] Observations that Require Specimens [OM6] Observations Calculated from Other Observations]

It hopes that OMA, OMB, etc. can be globally handled at a time.Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Japan 8.7.4 N Mi

HL7 Attribute Table – OM2

SEQ = 6 RP# =(No)SEQ = 7 RP# =(No)

HL7 Attribute Table – OM2

SEQ = 6 RP# =YSEQ = 7 RP# =Y

The benefit to the multiple reference & critical range by the sexuality, age.Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Japan 8.7.4.6.1

N Mi

Components: <low value & high value>

Definition: This subcomponent contains the reference (normal) range. The format of this field is where the range is taken to be inclusive (i.e., the range includes the end points). In this specification, the units are assumed to be identical to the reporting units given in OM2-2-units of measure).

Components: a) lower limit-upper limit (when

both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)

b) > lower limit (if no upper limit, e.g., >10)

c) < upper limit (if no lower limit, e.g., <15)

Definition: This subcomponent contains the reference (normal) range. The format of this field is where the range is taken to be inclusive (i.e., the range includes the end points). In this specification, the units are assumed to be identical to the

Because description such as lower bound upper bound can't be done, it is requested that it should be described in the same way as OBX-7 references range.Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Version 2.4 May Ballot Review Page 28

reporting units given in OM2-2-units of measure).

Japan 8.7.4.6.8

N Mi A range that applies unconditionally, such as

albumin, is transmitted as:

3.0 & 5.5

A normal range that depends on sex, such as Hgb, is transmitted as:

13.5 & 18^M~12.0 & 16^F

A normal range that depends on age, sex, and race (a concocted example) is:

10 & 13 ^M^0 & 2 ^^^B11 & 13.5 ^M^2 & 20 ^^^B~12 & 14.5 ^M^20 & 70 ^^^B~13 & 16.0 ^M^70 & ^^^B

A range that applies unconditionally, such as albumin, is transmitted as:

3.0 - 5.5

A normal range that depends on sex, such as Hgb, is transmitted as:

13.5 - 18^M~12.0 - 16^F

A normal range that depends on age, sex, and race (a concocted example) is:

10 - 13 ^M^0 & 2 ^^^B11 - 13.5 ^M^2 & 20

^^^B~12 - 14.5 ^M^20 & 70

^^^B~13 - 16.0 ^M^70 & ^^^B

It is the case that it was described in the same way as OBX-7 references rangResolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0e.

Japan 8.7.4.7

N Mi

Components: <low value ^ high value>

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)

Components: <ref. (normal) range> ^ <sex> ^ <age range> ^ <age gestation> ^ <species> ^ <race/subspecies> ^ <text condition>

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)

It is changed to the same components as OM2-6. Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Version 2.4 May Ballot Review Page 29

Japan 8.7.5 N Mi

HL7 Attribute Table – OM3

SEQ = 5 RP# =(No)SEQ = 6 RP# =(No)

HL7 Attribute Table – OM3

SEQ = 5 RP# =Y SEQ = 6 RP# =Y

It is necessary for the abnormal text & critical text that it can be repeated.Resolution: The proposal deals with material outside the ballot process. The suggestions do warrant discussion and therefore will be put on the V2.x agenda. A request is made to re-submit the proposal with specific suggestions for change. A motion was made to move this topic to V2.x agenda.Vote: accept 14, against 0, abstain 0

Frank Oemig

8.7.6.7

N Mj

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

...Refer to user defined table 0371 – Additive for suggested values. The table’s values are taken from NCCLS AUTO4. The value set can be extended with user specific values.

If a table is to be extended with user specific values it should not be an HL7 table but should be an user defined table.Resolution: The suggestion was withdrawn as this will be part of a general process to review proper reference and use of HL7 vs. user defined tables.

Kaiser 8.7.9 & 8.11.2

N Mi

There appear to be 2 segments addressing the same need i.e., Service Item Master (SIM). Only 1 should be retained. We personally prefer the SIM as described in 8.11.2, but either would be agreeable. If 8.11.2 is selected, field 24 of the OM7 should be added with perhaps a more descriptive name such as Charge Identifier.Resolution: The suggestion was withdrawn.

Kaiser 8.7.9.22

N Mi

Formulary indicator (ID) 01498 Formulary indicator (ID) status (IS) 01498

Since submitting our proposal it has come to our attention that this field is not a simple Yes/No. We need to change the data type to IS. Therefore, this would become user-defined table NNNN Formulary status. We have submitted additional values of “R” Item is in formulary but restricted and “G” – Item is in formulary and has guidelines. These new items were submitted under separate cover for future enhancement.Resolution: Motion to accept the

Version 2.4 May Ballot Review Page 30

suggested changes as-is was made.Vote: accept 14, against 0, abstain 0

Version 2.4 May Ballot Review Page 31

Affirmative Comments – Chapter 4

Frank Oemig

The proposal is made to replace the current text in 4.5.2 with the following text to reflect the use of the new query format.

4.5.2 Ordering non-medical services

The ORM message can be used for various types of orders. The following examples show how the ORM/ORR messages can be used to order non-medical services. The patient requests hospital specific services for a certain period of time. This can be a phone, fax, or TV in the room, or the delivery of a newspaper every day. Another example may be the use of specialized chip cards that give access to hospital specific services. Typically, a request for these services is made at the time of admission. Another example may be the printing of a form (e.g. the receipt for a payment). In case of using phones it might be a detailed list of calls for a patient or for a special extension.

To support these scenarios, the following fields are used to communicate the appropriate message:

Segment/ Field

Definition

ORC-1 Order ControlORC-2 Placer Order NumberORC-5 Order StatusORC-7.4 Start Date/Time ORC-7.5 End Date/TimeORC-16 Order Control Code ReasonORC-25 Order Status ModifierOBR-4 Universal Service IDOBX-5 Observation ValueFT1-17 Fee ScheduleFT1-11 Transaction amount – extendedBLG Billing segment

ORC-1, ORC-2, OBR-4, OBX-5These services can be started, discontinued, canceled, locked etc. according to the ORC-1- Order control code. The order is identified through ORC-2- Placer order number. The service itself is specified in the field OBR-4- Universal service ID. User defined codes are used to identify the specific services. The identification of the object of the service, e.g., phone number or card number, is done using the OBX-5- Observation value. The ORC-25- Order Status Modifier is used refine the universal service ID. For example, in the case of issuing chip cards, these fields would be valued as follows:

ORC-1 OBR-41

(in textual form)ORC-25 Description

NW Request a new chip card Issue a chip card the first timeXO Request a new chip card defect Change the previous order:

1 The text must be replaced by a coded value!

Version 2.4 May Ballot Review Page 32

issue a new chip card for a defective one

XO Request a new chip card lost Change the previous order: issue a new chipcard for a lost one

DC Return chip card cancel the chip card orderDC Return chip card lost cancel the chip card order on

account of lostDC Return chip card defective cancel the chip card order on

account of defective card

Use of different universal service IDs allows for the ability to charge an additional fee.

ORC-7The field ORC-7-: Quantity/timing describe time periods during which the requested service is valid. The components 4 and 5 denote the start and end date/time.

ORC-5In this field information on the status of the service can be transmitted. This field can be used in particular in response to a query message.

ORC-25This field allows for refining the requested universal service, e.g. to change an order for a chip card in order to distribute a new card for a lost one.

BLG-1,2,3These fields indicate to the financial system that charges are to be invoiced for this service.

FT1-17In some cases it is necessary that the placer defines a special tariff the filler has to use for computing the final balance.

FT1-11In combination with the tariff the patient can prepay the ordered service. This may be helpful when the patient uses services provided by the hospital in order to use the service from the beginning. FT1-6 must be valued at “PY”.If no amount is prepaid a limit can be established according to a special tariff. This depends on the setup of the filling system. In such a case the hospital grants a credit to the patient.

Phone Number Assignment

In case the patient requests a bedside phone and the number of this phone is assigned to him personally, a number of messages are transmitted. The objective is to connect a phone number to a patient and a room.

The update of the location master file depends on the setup of the private branch exchange system (PABX):

Version 2.4 May Ballot Review Page 33

a) Variable Numbering SystemOn admission the patient is assigned his personal call number, which he retains throughout his stay, including if he is transferred. The patient can always be reached under the same call number.To understand the mechanism for M05 events it is important to know that two different sets of phone numbers exist: One is a pool to be used when querying for a phone number for a patient, the other one is used for temporary assignments when no patient is lying in the bed (i.e. the bed is free).

b) Fixed Numbering SystemOn admission the system issues the patient with a telephone and/or TV authorization. This authorization key must be entered into the phone to activate it.No M05 messages are necessary if a fixed numbering system is used: Each telephone connection is assigned a permanent call number when the system is set up.

When the patient is admitted, a ADT^A01 message is sent to create a patient record in the phone number assigning application. Typically, the patient ID (PID-3), patient location (PV1-3), and visit number (PV1-19) are at least required. This message is acknowledged accordingly with an ACK. Then, the order for the phone number to the phone number assigning application is placed with the ORM^O01 message where the essential fields are ORC-1 = “NW”, ORC-2 = <placer order number>, and OBR-4 = “Phone”.

The ORR^O02 message is used to acknowledge the order and communicate the filler order number and order status. Then, when the phone number is available, a ORU^R01 (or ORM^O01 = status update???) message is used to communicate the phone number using OBX-5 for the phone number.

Any status changes to the order are communicated with the ORM^O01 message where ORC-1 = “SC”, ORC-2 = <placer order number>, ORC-3 = <filler order number>, ORC-5 = <order status>, OBR-4 = “Phone”, and OBX-5 = <Phone Number of Patient>. The status change is acknowledged with the ORR^O02 message.

Next, the location master files are updated. The phone number assigning application may send a MFN^M05 message to have the location master file reflect the phone number assignment as well. The fields on the message are valued as follows:

After processing the order: MFI-1 = “LOC”, MFI-3 = “UPD”, MFI-5 = <effective date/time>, MFE-1 = “MUP”, LOC-1 = <patient location>, LOC-3 = “B” (bed), LOC-6 = <Phone Number of Patient>. This message is acknowledged using the MFK^M05 message.

Transfer a patient (A02)

If a patient keeps the same phone number during the whole visit the assigned phone number must be mapped to a different phone outlet whenever a patient is transferred to a new location. In that case, the ADT^A02 message is sent to the phone number assigning application. That application not only acknowledges the message, but also sends an ORM^O01 message with ORC-1 = “SC and the other fields the same as described in the Phone Number Assignment section. Additionally, it sends a MFN^M05 message to change the location master file accordingly for the old location and another MFN^M05 to synchronize the phones for the new location.

Leave of absence (A21/A22)

When the patient leaves the hospital or the bed is vacated for a significant amount of time, the phone needs to be de-activated and re-activated appropriately. The same ORM^O01 and MFN^M05 messages are used as described above following the ADT^A21 and ADT^22 messages.

Version 2.4 May Ballot Review Page 34

Patient makes calls or (de-)activates his phone

The patient can use the phone whenever he wants to. This implies that his balance does not exceed the limit. Otherwise the phone is deactivated automatically. Furthermore the patient can activate or deactivate the phone by entering the authorization key for his own. In these scenarios the phone number assigning application sends and ORM^O01 message with ORC-1 = “OD” and the appropriate order status. The status update is necessary to provide a call switching system with the actual information.

Discharge a patient (A03)

When the patient is discharged, the ADT^A03 message is sent to indicate a discharge. The phone number assigning application sends an ORM^O01 message with a change of status to indicate completion of the order, as well as an MFN^M05 message to synchronize the location master file.

After discharging a patient his final charges must be billed. Using the query P04 returns the data in a display oriented format which can be used for printing. Alternatively a print request can be used. The billing system issues a QRY^P04 message where the fields are valued as follows: QRD-2 = “R” (record oriented format), QRD-3 = “I” (immediate response), QRD-8.1 = <Patient ID>, QRF-2 = <start date/time>, and QRF-3 = <end date/time>. The phone number assigning applications responds with a DSR^P04 message with the data in DSP-3.

Phone Call Queries (Z89)

The new query modes using a query by parameter query with a virtual table response allows for obtaining call information from the phone system to be used for charging. The query can be for accumulated data or detailed data. Both requests use this conformance statement:

Conformance StatementQuery Name: Z89 Query Information about Phone Calls

Query Trigger: Z89

Query Mode: Both

Response Trigger: X89

Query Priority: Immediate

Query Characteristics: Returns response sorted by Phone Number

Purpose: Retrieve all information about phone calls made during a defined interval either in a detailed or an accumalitve format. The identifier for the patient must be given.

Query Grammar

QBP^ Z89^RTB_Z89 QBP Message Section Reference

MSH Message Header Segment 2.15.9

QPD Query Parameter Definition 5.4.4

RCP Response Control Parameter 5.4.6

Version 2.4 May Ballot Review Page 35

Input Parameter Specification:

ColName Key/ Search

Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name

LOINC or HL7 code/ Domain

ElementName

Patient ID K Y 80 CX R = PID.3 PID.3 Patient ID

Date Range 53 DR O contains=

Detailed 2 ID O = 0136 Yes/No

Input Parameter Field Description and Commentary

Patient ID (CX)

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>

This field contains a patient identification code to identify the requested person.

If this field is not valued, no values for this field are considered to be a match.

Date Range (DR)

This field specifies the range of time, the requested records should match.

If this field is not valued, all values for this field are considered to be a match.

Detailed (ID)

This field specifies whether the output should be detailed. (no cumulative records).

If this field is not valued, a detailed result is returned..

When Detailed=Y is requested, one record for each call is returned. Each detailed record will contain columns 1, 2, 3, 4, 5, 7, 8, and 9 (Providor,Region,Extension,Destination,Date/Time,Duration,Units,Amount) for each call.

When detailed=N, the query is for accumulated data. In this case, one row record per extension is returned,.

Each row will return columns 1, 2, 6,7, 8, and 9 (Provider,Region,Quantity,Units,Amount) from the output virtual table.

Response Grammar

RTB^X89^RTB_X89 Personnel Information Message Comment Support Indicator

Sec Ref

MSH Message Header 2.15.9

Version 2.4 May Ballot Review Page 36

MSA Message Acknowledgement 2.15.8

[ERR] Error 2.15.5

QAK Query Acknowledgement 5.4.2

QPD Query Parameter Definition 5.4.4

[

RDF Table Row Definition Segment 5.4.7

{ [ RDT ] } Table Row Data Segment 5.4.8

]

[ DSC ] Continuation Pointer 2.15.4

Virtual Table

ColName Key/

Search

Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name

LOINC or HL7 code

ElementName

Provider 40 ST R

Region 40 ST R

Extension 40 XTN O

Destination number

40 XTN O

Date/Time Y 26 TS O

Quantity 4 NM O

Duration 4 NM O

Units 4 NM O

Amount 8 MO O

ExamplesExample 1:Query the accumulated list for patient 12345 from 3/2/00 till 3/3/00. Transfer the first 20 records.Query:

MSH|^&~\|PCR|Gen Hosp|PIMS||20000303201400-0800||QBP^Z89^QBP_Z89|9901|P|2.4||||||||QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y

Version 2.4 May Ballot Review Page 37

RCP|I|20^RD|Answer:

MSH|^&~\|PIMS|Gen Hosp|PCR||1998112014010800||RTB^X89^RTB_X89|8858|P|2.4||||||||MSA|AA|9901|QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y|RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|

Units^NM^4|Amount^MO^8|RDT|DTAG|CITY||||5|20|3|3.25|RDT|DTAG|R50||||1|10|2|1.00|RDT|DTAG|R200||||0|0|0|0|RDT|DTAG|NAT||||0|0|0|0|RDT|DTAG|INT||||0|0|0|0|

Example 2:Query the detailed information for patient 12345 from 3/1/00 till 3/3/00. Transfer the first 10 records.Query:

MSH|^&~\|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Z89^QBP_Z89|ACK9901|P|2.4||||||||QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||RCP|I|10^RD|

Answer:MSH|^&~\|PIMS|Gen Hosp|PCR||199811201401-0800||RTB^X89^RTB_X89|8858|P|2.4||||||||MSA|AA|8858 QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|

Units^NM^4|Amount^MO^8|RDT|DTAG|CITY|12345|555-1234|200003021715||20|12|2.25|RDT|DTAG|CITY|12345|555-4569|200003011252||21|3|0.48|

Requesting a Chip card

In case the hospital provides additional services that can be accessed through chip cards, this card has to be issued to the patient. At the end of the visit this chip card is returned. Distributing a chip card to a patient is a service which must be ordered from the chip card dispensing system, too. When discharging the patient the service (= order) is complete.

The messages are essentially the same as for issuing a phone number. The filler for the chip card order is a chip card dispensing application and instead of returning a phone number, it returns a chip card number. The following scenarios have slight variations.

New Chip Card requested due to, e.g., loss

Version 2.4 May Ballot Review Page 38

When a card is lost, or a new chip card must be requested, an additional fee can be communicated by including the FT1 segment in the ORM^O01 message and valuing FT1-11 = <additional fee>.

Request a new Chip card for a defective one

Sometimes a chip card is defective. Then the patient needs a new one. This situation requires an order using the XO control code in the ORM^O01 message. The chip card dispensing system returns an acknowledgement and an ORR^O02 (?) with the new chip card number. The ORC-16-Order Control Code Reason is used to precise the request.

Return a chip card

When the patient returns the chip card, a discontinue message is send with ORC-1 = “DC”. This message is acknowledged accordingly by the chip card dispensing system.

Printing a form

When form needs printing, the ORM^O01 could also be used. The OBR segment would contain the print form service and the OBX would contain the specific print form. A notification when completing the printing is feasible as well using the ORM^O01 with a status update associated to the appropriate placer/filler order number.

After discussion, various adjustments were made resulting in the following text:

4.5.2 Ordering non-medical services

The ORM message can be used for various types of orders. The following examples show how the ORM/ORR messages can be used to order non-medical services. The patient requests hospital specific services for a certain period of time. This can be a phone, fax, or TV in the room, or the delivery of a newspaper every day. Another example may be the use of specialized chip cards that give access to hospital specific services. Typically, a request for these services is made at the time of admission. Another example may be the printing of a form (e.g. the receipt for a payment). In case of using phones it might be a detailed list of calls for a patient or for a special extension.

To support these scenarios, the following fields are used to communicate the appropriate message:

Segment/ Field

Definition

ORC-1 Order ControlORC-2 Placer Order NumberORC-5 Order StatusORC-7.4 Start Date/Time ORC-7.5 End Date/TimeORC-16 Order Control Code ReasonORC-25 Order Status ModifierOBR-4 Universal Service ID

Version 2.4 May Ballot Review Page 39

OBX-5 Observation ValueFT1-17 Fee ScheduleFT1-11 Transaction amount – extendedBLG Billing segment

ORC-1, ORC-2, OBR-4, OBX-5These services can be started, discontinued, canceled, locked etc. according to the ORC-1- Order control code. The order is identified through ORC-2- Placer order number. The service itself is specified in the field OBR-4- Universal service ID. User defined codes are used to identify the specific services. The identification of the object of the service, e.g., phone number or card number, is done using the OBX-5- Observation value. The ORC-25- Order Status Modifier is used to refine the status of the universal service ID. For example, in the case of issuing chip cards, these fields would be valued as follows:

ORC-1 OBR-4(in textual form)

ORC 16 Description

NW chip card Issue a chip card the first timeXO chip card defective Change the previous order:

issue a new chip card for a defective one

XO chip card lost Change the previous order: issue a new chipcard for a lost one

DC chip card cancel the chip card orderDC chip card lost cancel the chip card order on

account of lostDC chip card defective cancel the chip card order on

account of defective card

Use of different universal service IDs allows for the ability to charge an additional fee.

ORC-7The field ORC-7-: Quantity/timing describe time periods during which the requested service is valid. The components 4 and 5 denote the start and end date/time.

ORC-5In this field information on the status of the service can be transmitted. This field can be used in particular in response to a query message.

ORC-25This field allows for refining the status of the requested universal service, e.g. to change an order for a chip card in order to distribute a new card for a lost one.

BLG-1,2,3These fields indicate to the financial system that charges are to be invoiced for this service.

Version 2.4 May Ballot Review Page 40

FT1-17In some cases it is necessary that the placer defines a special tariff the filler has to use for computing the final balance.

FT1-11In combination with the tariff the patient can prepay the ordered service. This may be helpful when the patient uses services provided by the hospital in order to use the service from the beginning. FT1-6 must be valued at “PY”.If no amount is prepaid a limit can be established according to a special tariff. This depends on the setup of the filling system. In such a case the hospital grants a credit to the patient.

Phone Number Assignment

In case the patient requests a bedside phone and the number of this phone is assigned to him personally, a number of messages are transmitted. The objective is to connect a phone number to a patient and a room.

The update of the location master file depends on the setup of the private branch exchange system (PABX):

c) Variable Numbering SystemOn admission the patient is assigned his personal call number, which he retains throughout his stay, including if he is transferred. The patient can always be reached under the same call number.To understand the mechanism for M05 events it is important to know that two different sets of phone numbers exist: One is a pool to be used when querying for a phone number for a patient, the other one is used for temporary assignments when no patient is lying in the bed (i.e. the bed is free).

d) Fixed Numbering SystemOn admission the system issues the patient with a telephone and/or TV authorization. This authorization key must be entered into the phone to activate it.No M05 messages are necessary if a fixed numbering system is used: Each telephone connection is assigned a permanent call number when the system is set up.

When the patient is admitted, a ADT^A01 message is sent to create a patient record in the phone number assigning application. Typically, the patient ID (PID-3), patient location (PV1-3), and visit number (PV1-19) are at least required. This message is acknowledged accordingly with an ACK. Then, the order for the phone number to the phone number assigning application is placed with the ORM^O01 message where the essential fields are ORC-1 = “NW”, ORC-2 = <placer order number>, and OBR-4 = “Phone”.

The ORR^O02 message is used to acknowledge the order and communicate the filler order number and order status. Then, when the phone number is available, a ORU^R01 message is used to communicate the phone number using OBX-5 for the phone number.

Any status changes to the order are communicated with the ORM^O01 message where ORC-1 = “SC”, ORC-2 = <placer order number>, ORC-3 = <filler order number>, ORC-5 = <order status>, OBR-4 = “Phone”, and OBX-5 = <Phone Number of Patient>. The status change is acknowledged with the ORR^O02 message.

Next, the location master files are updated. The phone number assigning application may send a MFN^M05 message to have the location master file reflect the phone number assignment as well. The fields on the message are valued as follows:

Version 2.4 May Ballot Review Page 41

After processing the order: MFI-1 = “LOC”, MFI-3 = “UPD”, MFI-5 = <effective date/time>, MFE-1 = “MUP”, LOC-1 = <patient location>, LOC-3 = “B” (bed), LOC-6 = <Phone Number of Patient>. This message is acknowledged using the MFK^M05 message.

Transfer a patient (A02)

If a patient keeps the same phone number during the whole visit the assigned phone number must be mapped to a different phone outlet whenever a patient is transferred to a new location. In that case, the ADT^A02 message is sent to the phone number assigning application. That application not only acknowledges the message, but also sends an ORM^O01 message with ORC-1 = “SC and the other fields the same as described in the Phone Number Assignment section. Additionally, it sends a MFN^M05 message to change the location master file accordingly for the old location and another MFN^M05 to synchronize the phones for the new location.

Leave of absence (A21/A22)

When the patient leaves the hospital or the bed is vacated for a significant amount of time, the phone needs to be de-activated and re-activated appropriately. The same ORM^O01 and MFN^M05 messages are used as described above following the ADT^A21 and ADT^22 messages.

Patient makes calls or (de-)activates his phone

The patient can use the phone whenever he wants to. This implies that his balance does not exceed the limit. Otherwise the phone is deactivated automatically. Furthermore the patient can activate or deactivate the phone by entering the authorization key for his own. In these scenarios the phone number assigning application sends and ORM^O01 message with ORC-1 = “OD” and the appropriate order status. The status update is necessary to provide a call switching system with the actual information.

Discharge a patient (A03)

When the patient is discharged, the ADT^A03 message is sent to indicate a discharge. The phone number assigning application sends an ORM^O01 message with a change of status to indicate completion of the order, as well as an MFN^M05 message to synchronize the location master file.

After discharging a patient his final charges must be billed. Using the query P04 returns the data in a display oriented format which can be used for printing. Alternatively a print request can be used. The billing system issues a QRY^P04 message where the fields are valued as follows: QRD-2 = “R” (record oriented format), QRD-3 = “I” (immediate response), QRD-8.1 = <Patient ID>, QRF-2 = <start date/time>, and QRF-3 = <end date/time>. The phone number assigning applications responds with a DSR^P04 message with the data in DSP-3.

Phone Call Queries (Q??)

The new query modes using a query by parameter query with a virtual table response allows for obtaining call information from the phone system to be used for charging. The query can be for accumulated data or detailed data. Both requests use this conformance statement:

Conformance StatementQuery Name: Q?? Query Information about Phone Calls

Query Trigger: Q??

Version 2.4 May Ballot Review Page 42

Query Mode: Both

Response Trigger: K??

Query Priority: Immediate

Query Characteristics: Returns response sorted by Phone Number

Purpose: Retrieve all information about phone calls made during a defined interval either in a detailed or an accumalitve format. The identifier for the patient must be given.

Query Grammar

QBP^ Z89^RTB_Z89 QBP Message Section Reference

MSH Message Header Segment 2.15.9

QPD Query Parameter Definition 5.4.4

RCP Response Control Parameter 5.4.6

Input Parameter Specification:

ColName Key/ Search

Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name

LOINC or HL7 code/ Domain

ElementName

Patient ID K Y 80 CX R = PID.3 PID.3 Patient ID

Date Range 53 DR O contains=

Detailed 2 ID O = 0136 Yes/No

Input Parameter Field Description and Commentary

Patient ID (CX)

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility (HD)>

This field contains a patient identification code to identify the requested person.

If this field is not valued, no values for this field are considered to be a match.

Date Range (DR)

This field specifies the range of time, the requested records should match.

Version 2.4 May Ballot Review Page 43

If this field is not valued, all values for this field are considered to be a match.

Detailed (ID)

This field specifies whether the output should be detailed. (no cumulative records).

If this field is not valued, a detailed result is returned..

When Detailed=Y is requested, one record for each call is returned. Each detailed record will contain columns 1, 2, 3, 4, 5, 7, 8, and 9 (Providor,Region,Extension,Destination,Date/Time,Duration,Units,Amount) for each call.

When detailed=N, the query is for accumulated data. In this case, one row record per extension is returned,.

Each row will return columns 1, 2, 6,7, 8, and 9 (Provider,Region,Quantity,Units,Amount) from the output virtual table.

Response Grammar

RTB^X89^RTB_X89 Personnel Information Message Comment Support Indicator

Sec Ref

MSH Message Header 2.15.9

MSA Message Acknowledgement 2.15.8

[ERR] Error 2.15.5

QAK Query Acknowledgement 5.4.2

QPD Query Parameter Definition 5.4.4

[

RDF Table Row Definition Segment 5.4.7

{ [ RDT ] } Table Row Data Segment 5.4.8

]

[ DSC ] Continuation Pointer 2.15.4

Virtual Table

ColName Key/

Search

Sort LEN TYPE Opt Rep Match Op TBL Segment Field Name

LOINC or HL7 code

ElementName

Provider 40 ST R

Region 40 ST R

Extension 40 XTN O

Destination number

40 XTN O

Version 2.4 May Ballot Review Page 44

Date/Time Y 26 TS O

Quantity 4 NM O

Duration 4 NM O

Units 4 NM O

Amount 8 MO O

ExamplesExample 1:Query the accumulated list for patient 12345 from 3/2/00 till 3/3/00. Transfer the first 20 records.Query:

MSH|^&~\|PCR|Gen Hosp|PIMS||20000303201400-0800||QBP^Z89^QBP_Z89|9901|P|2.4||||||||QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|YRCP|I|20^RD|

Answer:MSH|^&~\|PIMS|Gen Hosp|PCR||1998112014010800||RTB^X89^RTB_X89|8858|P|2.4||||||||MSA|AA|9901|QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4QPD|Z89^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y|RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|

Units^NM^4|Amount^MO^8|RDT|DTAG|CITY||||5|20|3|3.25|RDT|DTAG|R50||||1|10|2|1.00|RDT|DTAG|R200||||0|0|0|0|RDT|DTAG|NAT||||0|0|0|0|RDT|DTAG|INT||||0|0|0|0|

Example 2:Query the detailed information for patient 12345 from 3/1/00 till 3/3/00. Transfer the first 10 records.Query:

MSH|^&~\|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Q??^QBP_Q??|ACK9901|P|2.4||||||||QPD|Q??^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||RCP|I|10^RD|

Answer:MSH|^&~\|PIMS|Gen Hosp|PCR||199811201401-0800||RTB^K??^RTB_K??|8858|P|2.4||||||||MSA|AA|8858 QAK|Q010|OK|Z89^Query Phone Calls^HL7nnn|4

Version 2.4 May Ballot Review Page 45

QPD|Q??^Query Phone Calls^HL7nnn|Q010|12345|2000030100000^20000302235959|Y||||RDF|9|Provider^ST^20|Region^ST^40|Extension^XTN^40|Destination^XTN^40|Date/Time^TS^26|Quantity^NM^4|Duration^NM^4|

Units^NM^4|Amount^MO^8|RDT|DTAG|CITY|12345|555-1234|200003021715||20|12|2.25|RDT|DTAG|CITY|12345|555-4569|200003011252||21|3|0.48|

Requesting a Chip card

In case the hospital provides additional services that can be accessed through chip cards, this card has to be issued to the patient. At the end of the visit this chip card is returned. Distributing a chip card to a patient is a service which must be ordered from the chip card dispensing system, too. When discharging the patient the service (= order) is complete.

The messages are essentially the same as for issuing a phone number. The filler for the chip card order is a chip card dispensing application and instead of returning a phone number, it returns a chip card number. The following scenarios have slight variations.

New Chip Card requested due to, e.g., loss

When a card is lost, or a new chip card must be requested, an additional fee can be communicated by including the FT1 segment in the ORM^O01 message and valuing FT1-11 = <additional fee>.

Request a new Chip card for a defective one

Sometimes a chip card is defective. Then the patient needs a new one. This situation requires an order using the XO control code in the ORM^O01 message. The ORC-16-Order Control Code Reason is used to clarify the request. The chip card dispensing system returns the new chip card number using the ORU^R01.

Return a chip card

When the patient returns the chip card, a discontinue message is sent with ORC-1 = “DC”. This message is acknowledged accordingly by the chip card dispensing system.

Printing a form

When form needs printing, the ORM^O01 could also be used. The OBR segment would contain the print form service and the OBX would contain the specific print form. A notification when completing the printing is feasible as well using the ORM^O01 with a status update associated to the appropriate placer/filler order number.

A motion was made to accept the changes while Frank Oemig would replace the Conformance Statement with the most current balloted format and replace the ?? with the correct number.Vote: accept 13, against 0, abstain 0

Version 2.4 May Ballot Review Page 46

Version 2.4 May Ballot Review Page 47

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

Kaiser 4.2.6 A S/Q The priority component may repeat; separate

repeating values with the repeat delimiter separated by a space.

The priority component may repeat; separate repeating values with the repeat delimiter separated by a space.

Clarification of the statement intent.Resolution: Accepted as suggested.

SMS 4.2.10.2

A T Missing closing quotation after RXO segment field examplesResolution: Accepted as suggested.

Frank Oemig

4.3.1 A Q only for backward compatibility! Chapter 4.5.2 makes use of this message to order non-medical services. Which message should be taken instead?Resolution: Withdrawn.

SMS 4.3.1.1

A T Should be consistent in use of underscores and quotations in first paragraph. References to 4.9 and 4.12 use quotes and underscores, but reference to 4.6 uses only quotes.Resolution: It appears already to be correct. Withdrawn.

HBOC 4.3.2 A Q ORR^O02^ORR_O02Format - is this correct? Why is the double listed there? Other times it is OSQ Q06Resolution: It appears already to be correct. Withdrawn.

HBOC 4.3.2.1

A T Note: ORRs for supply, pharmacy, and dieteray orders all have slightly different message syntax;

Note: ORRs for supply, pharmacy, and dieteray dietary orders all have slightly different message syntax;

MisspelledResolution: Accepted as suggested.

Kaiser 4.3.5 A T OMG - general clinical order response message (event O20)

ORG - general clinical order response acknowledgement message (event O20)

The code for the acknowledgement message for the general clinical order is ORG, not OMG. Also it seems that the name in the section header should agree with the syntax.Resolution: Accepted as suggested.

Version 2.4 May Ballot Review Page 48

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

HBOC 4.3.5 A T OMG - general clinical order response message (event O20)

OMG ORG - general clinical order response message (event O20)

Correct header.Resolution: Accepted as suggested.

SMS 4.3.6 A S 1st paragraph:While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message can be used to take advantage…

While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message should be used to take advantage…

Change wording from can to should or may. Isn't the OML message the only way to take advantage of specimen and container extensions required by automated lab?Resolution: Accepted as suggested.

Kaiser 4.3.13

A T 1^Q2J^^1432

Perform a service every Tuesday at 2:32 p.m

1^QJ2^^1432

Perform a service every Tuesday at 2:32 p.m

Correct utilization of Q<integer>J<day#> repeating pattern formResolution: Accepted as suggested.

SMS 4.4.1 A Mi

In ORC attribute table, item 7, Quantity Timing should be marked as can repeat. The definition in section 4.2 clearly indicates that this field can repeat. Same would be true for OBR-27 quantity/timing fieldResolution: Accepted as suggested.

HBOC 4.4.1 A Q ORC table Fields 1 & 5 – They are now RP/# = N Does that mean non-repeating? I thought blank was non-repeating? Why specify N?Resolution: Done through Control/Query

HBOC 4.4.1.1

A Q Table 0119Missing Event/message typesNW is missing OMG OK is missing ORL and there’s moreUC, UD, UA, HR, UR, XO, UM, DE, LI are listed in there twiceResolution: Accepted as suggested.

Kaiser 4.4.1.7

A T For example, if an OBR segment describes a unit of blood, this field might request that three (3)

For example, if an OBR segment describes a unit of blood, this field

Correct utilization of QAM repeating patternResolution: Accepted as suggested.

Version 2.4 May Ballot Review Page 49

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

such units be given on successive mornings. In this case ORC-7-quantity/timing would be “1^XQAM^X3”. ORC-7-quantity/timing is the same as OBR-27-quantity/timing

might request that three (3) such units be given on successive mornings. In this case ORC-7-quantity/timing would be “1^XQAM^X3”. ORC-7-quantity/timing is the same as OBR-27-quantity/timing

Frank Oemig

4.5.2 A Mj

The specified query can be replaced by a new one using a conformance statement.The according proposal is submitted directly in form of a complete document.Resolution: Addressed earlier in the minutes.

HBOC 4.9.4 A T ORS Nonstock Requisition Order Acknowledgment Message (O08)

ORS ORN Nonstock Requisition Order Acknowledgment Message (O08)

Correct headingResolution: Accepted as suggested.

Kaiser 4.9.4 A T ORS Nonstock Requisition Order Acknowledgment Message (O08)

ORN Nonstock Requisition Order Acknowledgment Message (O08)

Correct code for Nonstock Requisition Order Acknowledgment is ORNResolution: Accepted as suggested.

HBOC 4.x.x A T All dietary / supply trigger headers should consistently say (EVENT XYZ), the document should be reviewed generally for consistency.

Example: OML – laboratory order message (event O21)ORN Nonstock Requisition Order Acknowledgment Message (O08)Resolution: Accepted as suggested.

Kaiser 4.12.5

A Q Notes and Comments (for OBX) Notes and Comments (for RXE) Although the indentation and description leads one to believe that the NTE is dependent on the OBX, the actual syntax is that the NTE can be populated without an OBX. Therefore, it would be more technically correct to

Version 2.4 May Ballot Review Page 50

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

say the NTE is for the RXE. We would not, however, be averse to correcting the syntax to look like the RXO segment in which the NTE is truly dependent on the OBX, and there is also a NTE for the RXO.Resolution: A proposal will be submitted for V2.x to add an NTE to the RDE message with the RXE segment.

Kaiser 4.12.6

A T ORP - Pharmacy/Treatment Encoded Order Acknowledgment (O12)

RRE - Pharmacy/Treatment Encoded Order Acknowledgment (O12)

The code for the Pharmacy/Treatment Order Acknowledgement is “RRE”, not “ORP”.Resolution: Accepted as suggested.

Kaiser 4.12.7

A Q Notes and Comments (for OBX) Notes and Comments (for RXD) Although the indentation and description leads one to believe that the NTE is dependent on the OBX, the actual syntax is that the NTE can be populated without an OBX. Therefore, it would be more technically correct to say the NTE is for the RXD. We would not, however, be averse to correcting the syntax to look like the RXO segment in which the NTE is truly dependent on the OBX, and there is also a NTE for the RXO.Resolution: A proposal will be submitted for V2.x to add an NTE to the RDS message with the RXD.

HBOC 4.13.1.3

A T In a nonvarying dose In a non-varying dose MisspelledResolution: Accepted as suggested.

Kaiser 4.13.4.20

A T Yes - Indicates that a warning is present. The application receiving the encoded order needs to warn the person administering the drug or treatment to pay attention to the text in RXE-22-pharmacy/treatment special dispensing instructions

Yes - Indicates that a warning is present. The application receiving the encoded order needs to warn the person administering the drug or treatment to pay attention to the text in RXE-21-pharmacy/treatment special

Correct reference to RXE-21 Pharmacy/treatment supplier’s special dispensing instructionsResolution: Accepted as suggested.

Version 2.4 May Ballot Review Page 51

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

dispensing instructions

Kaiser 4.13.5.15 – 4.13.5.27

A T RXC-15 Pharmacy/treatment supplier’s special dispensing instructions (CE) 00330Etc through 4.13.5.27

RXD-15 Pharmacy/treatment supplier’s special dispensing instructions (CE) 00330

The fields are RXD fields, not RXC.Resolution: Accepted as suggested.

SMS 4.13.5.16throu

gh4.13.5.27

A T These are definitions for RXD components, but all the headings say RXC-xx. Need to change.Resolution: Accepted as suggested.

Kaiser 4.13.5.22

A T Definition: This field contains the size of package to be dispensed. Units are transmitted in RXE-29-dispense package size unit.

Definition: This field contains the size of package to be dispensed. Units are transmitted in RXD-23-dispense package size unit.

Clarification of field referenceResolution: Accepted as suggested.

Kaiser 4.13.6.1

A T If the RXG segment carries information about multiple administrations, this field’s value is zero (0), since in this case a one-to-one matching with the RAS segment is ambiguous.

If the RXG segment carries information about multiple administrations, this field’s value is zero (0), since in this case a one-to-one matching with the RXA segment is ambiguous.

Clarification of segment referenceResolution: Accepted as suggested.

Kaiser 4.13.5.20,4.13.6.21,4.13.7.17,4.13.7.21

A Q Formatting issues, when printing without edit notations, the text of the document does not resolve into a “clean document” (possibly unbalanced edits).

NOTE: SHOULD THIS BE INCLUDED IN THE BALLOT. OVERALL I DID NOT REALLY WATCH FOR FORMATTING, BUT THESE REALLY STOOD OUT WHEN I PRINTED THE DOCUMENTResolution: Being addressed by editing.

Version 2.4 May Ballot Review Page 52

Name Sect V T Existing Wording Proposed Wording CommentsSMS 4.1.1 A T Sections 4.9 to 4.11 'Supply' includes…(e.g.,

requests o stock the ward supply room).Sections 4.9 to 4.11 'Supply' includes…(e.g., requests to stock the ward supply room).

TypoResolution: Accepted as suggested.

Kaiser 4.14.2 (b)

A T The need for strength and strength unit fields in addition to the amount and amount units fields included in various RX_ segments requires explanation. Physicians can write a prescription for a drug such as Ampicillin in two ways. One way would be: “Ampicillin 250 mg tabs capsules, 2 tabs capsules four times a day.” In this case the give amount would be 2, the give units would be tabs, the strength would be 250 and the strength units would milligrams

The need for strength and strength unit fields in addition to the amount and amount units fields included in various RX_ segments requires explanation. Physicians can write a prescription for a drug such as Ampicillin in two ways. One way would be: “Ampicillin 250 mg tabs capsules, 2 tabs capsules four times a day.” In this case the give amount would be 2, the give units would be capsules, the strength would be 250 and the strength units would milligrams

Missed one tab-to-capsule conversionResolution: Accepted as suggested.

Peter Rontey

4.18.1,para#1,sent# 3

A T Identifiers other than patient name are defined in the query by giving positional meaning to the repeat delimiters in the QRF-5-other query subject filter segment, as specified in 4.16.2, "Queries for immunization records (QRF Segments)."

Identifiers other than patient name are defined in the query by giving positional meaning to the repeat delimiters in the QRF-5-other query subject filter field, as specified in 4.16.2, "Queries for immunization records (QRF Segments).

Resolution: Accepted as suggested.

Version 2.4 May Ballot Review Page 53

Affirmative Comments – Chapter 7Name Sect V T Existing Wording Proposed Wording CommentsKaiser 7.1.5 A S Coding Schemes 1. Table 396 should be formatted as

other tables are with values in the first column, description in the second and additional comments or source in the third.

2. Section headers like “General codes” should be deleted.

3. Values should be alphabetized and duplicates removed.

Resolution: Being addressed through editing corrections.

SMS 7.3.1.27

A Mi

Need to change reference to section in chapter 4 where quantity/timing is documented. It is now in Section 4.2, not 4.4Resolution: Accepted as suggested.

HBOC 7.3.1.46

A T Refer to User-defined table 4011 - Supplemental service information values for suggested values.

Refer to User-defined table 4011 0411 - Supplemental service information values for suggested values.

Table reference should be 0411.Resolution: Accepted as suggested.

HBOC 7.3.1.47

A Q Text is different than 4.4.3.47 text regarding SNOMED, etcChapter 7: Individual implementations may extend this table using other appropriate vocabularies.Chapter 4: Individual implementations may extend this table using other appropriate vocabularies such as the SNOMED DICOM Microglossary (SDM) or private (local) entries.Resolution: Being addressed through editing corrections.

Bruce Wood

7.3.2.10

A S Table 0080 Nature of Abnormal Testing. As Species, Breed and Strain are being added to Patient Demographics should additional entries be made to this table to accommodate more specific values?Resolution: A specific proposal should be provided as part of V2.x

Version 2.4 May Ballot Review Page 54

Name Sect V T Existing Wording Proposed Wording CommentsHBOC 7.4.1 A S This examples use LOINC® clinical codes This These examples use

LOINC® clinical codesGrammarResolution: Accepted as suggested.

Kaiser 7.4.2 A T The OBX with Set ID of 1 appears to show the observation value in OBX-6 rather than OBX-5

Remove extra vertical bar after OBX-4

Resolution: Accepted as suggested.

Kaiser 7.4.2 A Q Both OBR-4 and OBX-3 are of data type CE. In this example message, all of these fields have the first component (the identifier) populated but not the third component (name of coding system). Does not population of the first component require population of the third?

Clarify usageResolution: Will be part of the example cleanup process.

Bruce Wood

7.4.5.2

A S The second paragraph states “MIC and disk diffusion (Kirby Bauer) susceptibility results can be combined in the same OBX segment.” Since HL7 is promoting the use of LOINC codes for the test identifiers and LOINC has separate codes to identify MIC vs Kirby Bauer methodologies, I feel this statement is misleading and should be removed from the HL7 documentation.Resolution: A V2.x proposal is required to address the issue.

HBOC 7.7.2 A Q Second paragraph begins with “Phase of a clinical trial.” What does this mean?

Kaiser 7.13.1.3

A S/T

CD - Channel definition This section has been flattened since the last ballot i.e. the level 6 section headers have been elevated to level 5. This makes it difficult to tell that some of the sections are sub components rather than components Agree that going down 6 levels is not desirable. Suggest a format correction and elevate Waveform data types to level N.N. This would be consistent with how data types are displayed in chapters 2 and 4.Resolution: See comments at end of table.

Kaiser 7.13.1.3

A S/T

CD - Channel definition Data types are missing in the component model. KP has submitted a

Version 2.4 May Ballot Review Page 55

Name Sect V T Existing Wording Proposed Wording Commentsdocument under separate cover showing how this could be corrected.Resolution: See comments at end of table.

Kaiser 7.13.1.3

A S/T

CD - Channel definition The sub component model is missing for those components having sub components. Resolution: See comments at end of table.

Kaiser 7.13.1.3.6

A S/T

Calibration parameters (NM) Channel calibration parameters (CM)

The data type and component name are inconsistent with chapter 2. Chapter 2 appears to be correct; an NM data type cannot have components.Resolution: Accepted as suggested.

The committee agreed unanimously for Joann Larson to follow-up with Wayne Tracy to determine whether the proposed changes required a new proposal or were technical in nature. The following represents the updated text to replace 7.14.3.

7.13 Waveform7.14 Waveform Result Data types

7.14.3 CD - Channel definitionComponents: <channel identifier (CM)> ^ <waveform source (CM)> ^ <channel sensitivity/units (CM)> ^ <channel calibration parameters (CM)> ^

<channel sampling frequency (NM)> ^ <minimum/maximum data values (CM)>

Subcomponents of channel identifier: <channel number (NM)> & <channel name (ST)>

Subcomponents of waveform source: <Source name 1 (ST)> & <Source name 2 (ST)>

Subcomponents of channel sensitivity/units: <channel sensitivity (NM)> & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & <alternate unit of measure identifier (ST)> & <alternate unit of Measure Description (ST)> & <alternate 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)> & <maximum data value (NM)>

This data type is used for labeling of digital waveform data. It defines a recording channel which is associated with one of the values in each time sample of waveform data. Each channel has a number (which generally defines its position in a multichannel display) and an optional name or label (also used in displays). One or two named waveform sources may also be associated with a channel (providing for the use of differential amplifiers with two inputs). The other components of the channel definition data type are optional. The individual components are defined as follows:

Version 2.4 May Ballot Review Page 56

Channel identifier (CM)Subcomponents: <channel number (NM)> & <channel name (ST)>

Two subcomponents separated by subcomponent delimiters (&) which identify the channel, consisting of a channel number (required, maximum 4 characters, data type NM) and a channel name (optional, maximum 17 characters, data type ST).

Channel number (NM)

The channel number identifies the recording channel associated with a specified value in a time sample of data. It generally defines its position in a multichannel display.

Channel name (ST)

The channel name is a text string used as a label in waveform data displays. If this name is not present, the channel label displayed is <source1>-<source2>, where <source1> and <source2> are the names of the two waveform sources connected to this channel, or, if only one waveform sources <source1> is specified, the channel label displayed when the channel name is not given is <source1>.

Waveform source (CM)Subcomponents: <Source name 1 (ST)> & <Source name 2 (ST)>

Identifies the source of the waveform connected to the channel. Two names (each maximum of 8 characters, data type ST) separated by a subcomponent delimiter (&) may be specified if it is necessary to individually identify the two inputs for a waveform. Only one name need be specified if the channel is connected to a single input. For example, in EKG recordings typically only one name is used (such as I or II); in electroencephalography, two names are typically used, one for each input of the differential amplifier (such as F3 and C3).. (NOTE: Although the SIG voted to make waveform source a coded entry, this is not syntactically possible. We do not have a sub-sub-component delimiter available to separate the sub-fields of the proposed coded entry. Therefore, waveform source remains a string data type.).

Source name 1 (ST)

Identifies the first input for the waveform source.

Source name 2 (ST)

Identifies the second input for the waveform source.

Channel sensitivity and units (CM)Subcomponents: <channel sensitivity (NM)> & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & <alternate unit of measure identifier (ST)> & <alternate unit of Measure Description (ST)> & <alternate unit of Measure Coding System (IS)>

This CM data type defines the channel sensitivity (gain) and the units in which it is measured. This component consists of up to seven subcomponents, separated from each other by subcomponent delimiters (&). The first subcomponent specifies the sensitivity, while the remaining six subcomponents are used to specify the units of the sensitivity, using a format similar to the components of the coded entry (CE) data type. The subcomponents of the channel sensitivity and units are as follows:

Version 2.4 May Ballot Review Page 57

Channel Sensitivity (NM)

Defines the nominal value (maximum 20 characters, data type NM) that corresponds to one unit in the waveform data, that is, the effective resolution of the least significant bit of the ADC, and the polarity of the channel. The sensitivity incorporates both the amplifier gain and the actual ADC resolution. It does not, however, relate to the vertical scaling of a waveform display (it is, for example, a measure of voltage, not voltage per unit distance). For channels recording potential differences between two electrodes using a differential amplifier, a positive sensitivity indicates that a number in the waveform data which is greater than the channel baseline represents a potential at the first electrode which is more positive than that at the second electrode. A negative sensitivity indicates that a number in the waveform data which is greater than the channel baseline corresponds to a potential at the first electrode which is more negative than that at the second electrode.

Unit of measure identifier (ST)

A units designation (for example, uv, mv, v, pal, or mm(hg) . Codes from the ISO+ extension of the standard SI single case unit abbreviations are presented as Figure 7-6, 7-7. And 7-8 in Section NNNN, the ANSI+ U.S. customary unit abbreviations, a superset of the ANSI standard which appears in Figure 7-9..

Unit of Measure Description (ST)

Definition: The full text name of the unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.

Unit of Measure Coding System (IS)

Definition: The designated system of units. Refer to User-defined table 0396 – Coding System for suggested values.

Alternate Unit of measure identifier (ST)

Definition: An alternate units designation (for example, uv, mv, v, pal, or mm(hg) . Codes from the ISO+ extension of the standard SI single case unit abbreviations are presented as Figure 7-6, 7-7. and 7-8 in Section NNNN, the ANSI+ U.S. customary unit abbreviations, a superset of the ANSI standard which appears in Figure 7-9..

Alternate Unit of Measure Description (ST)

The full text name of the alternate unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.

Alternate Unit of Measure Coding System (IS)

The alternate designated system of units. Refer to User-defined table 0396 – Coding System for suggested values.

Channel calibration parameters (CM)Subcomponents: < channel calibration sensitivity correction factor (NM)> & < channel calibration baseline (NM)> & < channel calibration time

skew (NM)>

This component consists of three optional subcomponents (each a maximum of 20 characters, data type NM), separated from each other by subcomponent delimiters (&), which define corrections to channel sensitivity, baseline, and channel time skew which may be derived from a calibration procedure. The three subcomponents are as follows:

Version 2.4 May Ballot Review Page 58

Channel calibration sensitivity correction factor (NM)

Definition: a correction factor for channel sensitivity which may be derived from the last calibration procedure performed. The actual channel sensitivity is the nominal channel sensitivity given in the previous component multiplied by the unitless correction factor.

Channel calibration baseline (NM)

Definition: the actual channel baseline (the data value which corresponds to a nominal input signal of zero). The actual baseline may differ from the ideal because of a dc offset in the amplifier connected to the ADC. The actual baseline values for all channels (which need not be integers) may be determined at the time of calibration as the average digitized values obtained when a zero input signal is connected to each channel.

Channel calibration time skew (NM)

Definition: the time difference between the nominal sampling (digitization) time (which would be the same for all channels) and the actual sampling time of the channel, in seconds (or fractions thereof). This value will differ from zero when all channels in the montage are not sampled simultaneously, as occurs in systems which sample successive channels at regular time intervals. This value may be determined from a calibration procedure in which an identical time-varying signal is applied to all channels and interchannel time differences are estimated, or more commonly it may be taken from the manufacturer’s specifications for the digitizing system used. For example, for a system which samples successive channels at regular time intervals t, the time skew of channel number n would be (n-1)t. The actual time of sampling (digitization) of sample number m of channel number n in such a system would be R + (m-1)/f + (n-1)t, where R is the reference time at the start of the epoch and f is the channel sampling frequency (t < 1/f).

Channel sampling frequency (NM)Defines the sampling frequency in hertz of the channel, that is, the reciprocal of the time in seconds between successive samples (maximum 20 characters, data type NM). Note that this is the frequency of transmitted data, which may or may not be the actual frequency at which the data was acquired by an analog-to-digital converter or other digital data source (i.e. the data transmitted may be subsampled, or interpolated, from the originally acquired data.)

Minimum and maximum data values (CM))Subcomponents: < minimum data value (NM)> & <maximum data value (NM)>

Defines the minimum and maximum data values which can occur in this channel in the digital waveform data, that is, the range of the ADC (each maximum of 20 characters, data type NM), and also specifies whether or not nonintegral data values may occur in this channel in the waveform data. If the minimum and maximum values are both integers (or not present), only integral data values may be used in this channel. If either the minimum or the maximum value contains a decimal point, then nonintegral as well as integral data values may be used in this channel. The minimum and maximum data values are separated by a component delimiter (&).

Minimum data value (NM)

Defines the minimum data value that can occur in this channel in the digital waveform data, and also specifies whether or not nonintegral data values may occur in this channel in the waveform data.

For an n-bit signed ADC, the nominal baseline B = 0, and the minimum (L) and maximum (H) values may be calculated as follows:

L = -2n-1

Version 2.4 May Ballot Review Page 59

H = 2n-1 - 1

For an unsigned n-bit ADC, the minimum value L = 0, and the nominal baseline value (B) and maximum value (H) may be calculated from the formulas,

B = 2n-1

H = 2n - 1

The actual signal amplitude A (for differentially amplified potential measurements, the potential at electrode number one minus that at electrode number two) may be calculated from the value D (range L to H) in the waveform data using the actual baseline value B and the nominal sensitivity S and actual sensitivity correction factor C by the formula,

A = SC(D-B)

Maximum data value (NM)

Defines the maximum data value that can occur in this channel in the digital waveform data, and also specifies whether or not nonintegral data values may occur in this channel in the waveform data.

For an n-bit signed ADC, the nominal baseline B = 0, and the minimum (L) and maximum (H) values may be calculated as follows:

L = -2n-1

H = 2n-1 - 1

For an unsigned n-bit ADC, the minimum value L = 0, and the nominal baseline value (B) and maximum value (H) may be calculated from the formulas,

B = 2n-1

H = 2n - 1

The actual signal amplitude A (for differentially amplified potential measurements, the potential at electrode number one minus that at electrode number two) may be calculated from the value D (range L to H) in the waveform data using the actual baseline value B and the nominal sensitivity S and actual sensitivity correction factor C by the formula,

A = SC(D-B)

Version 2.4 May Ballot Review Page 60

Affirmative Comments - Chapter 8

Name Sect V T Existing Wording Proposed Wording CommentsJapan 8.7.4.

8 OM2-8 Absolute range for ordinal and continuous observations

Japan

Components: <range> ^ <numeric change> ^ <%/a change> ^ <days>

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.

Components: <range> ^ <numeric change> ^ <%/a change> ^ <days>

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 OM2-9 Delta check criteria.

It is the format which is different from OM2-6, OM2-7, and it is the same format as OM2-9.Resolution: Accepted as suggested.

Japan 8.7.6.6 OM4-6 Specimen

Definition: This field reports the specimen as one of the specimen codes described in ASTM Table 14 of 1238-91. If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), separate them with repeat delimiters.

Definition: This field reports the specimen as one of the specimen codes described in ASTM Table 14 of 1238-91. If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), multiple segments may be included, one for each specimen type.

It is corrected to use OM4 segment for every specimen because the description of 8.7.6.6 OM4-6 Specimen contradicts the description of 8.7.6 OM4.Resolution: Will be discussed as a V2.x proposal at the next meeting.

SMS Before 8.1

A T M03 M03, M08 through M12 New events for Orders/Observations are missing.Resolution: Accepted as suggested

SMS 8.2 A T M03 – service/test/observation master file & M12-M99 – reserved for future use

M03, M08-M12 – service/test/observation master fileM13-M99 – reserved for future use

Definition of nn in Mnn is incorrect.Resolution: Accepted as suggested.

SMS 8.7.9.16

A T This field specifies the unit of time for field 8.7.3.58.

This field specifies the unit of time for OM7_15 -Consent interval quantity.

There is no field 8.7.3.58.Resolution: Accepted as suggested.

SMS 8.7.9.18

A T This field specifies the unit of time for field 8.7.3.60.

This field specifies the unit of time for OM7_17 – Consent waiting period quantity.

There is no field 8.7.3.60.Resolution: Accepted as suggested.

Version 2.4 May Ballot Review Page 61

Name Sect V T Existing Wording Proposed Wording CommentsFrank Oemig

8.3.1 A Mj

message type MFN^M01-M06 MFN^M01-M06^MFN_M01 Resolution: Accepted as suggested.

Frank Oemig

8.3.1 A Mj

message type MFK^M01-M06 MFK^M01-M06^MFK_M01 Resolution: Accepted as suggested.

Frank Oemig

8.3.2 A Mj

message type MFD^MFA MFD^MFA^MFD_MFA Resolution: Accepted as suggested.

Frank Oemig

8.3.2 A Mj

message type ACK^MFA6 ACK^MFA^ACK Resolution: Accepted as suggested.

Frank Oemig

8.3.3 A Mj

message type MFQ^M01-M06 MFQ^M01-M06^MFQ_M01 Resolution: Accepted as suggested.

Frank Oemig

8.3.3 A Mj

message type MFR^M01-M06 MFR^M01-M06^MFR_M01 Resolution: Accepted as suggested.

Frank Oemig

8.7.4.6.1

A Mj

reference (normal) range:<low value & high value>

the components don’t have a data type: please define oneResolution: Requires V2.x proposal with suggested data type. Will be discussed at next meeting.

Frank Oemig

8.7.4.6.3

A Mj

age range:<low value & high value>

the components don’t have a data type: please define oneResolution: Requires V2.x proposal with suggested data type. Will be discussed at next meeting.

Frank Oemig

8.7.4.6.4

A Mj

gestational age range:<low value & high value>

the components don’t have a data type: please define oneResolution: Requires V2.x proposal with suggested data type. Will be discussed at next meeting.

Frank Oemig

8.7.4.7

A Mj

critical range for ordinal and continuous observations:<low value & high value>

the components don’t have a data type: please define oneResolution: Requires V2.x proposal with suggested data type. Will be discussed at next meeting.

Frank Oemig

8.7.4.8

A Mj

absolute range for ordinal and continuous observations:<range> ^<numeric change> ^ <%/a change> ^ <days>

the components don’t have a data type: please define oneResolution: Requires V2.x proposal with suggested data type. Will be discussed at next meeting.

Frank Oemig

8.7.4.9

A Mj

delta check criteria:<low & high (CM) > ^ ...

the first component is not defined furtherResolution: Requires V2.x proposal with suggested definition. Will be discussed at next meeting.

Version 2.4 May Ballot Review Page 62

Name Sect V T Existing Wording Proposed Wording CommentsFrank Oemig

8.7.9 A T index information in heading: “OM1” “OM7” Resolution: Accepted as suggested

Frank Oemig

8.7.9.20

A T Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Cut and paste typoResolution: Accepted as suggested

Frank Oemig

8.7.9.21

A T OM7-21 Orderable-at location (PL) 01497Definition: This field contains the locations where the test/service can be ordered.

OM7-21 Orderable-at location (PL) 01497Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)Subcomponents of facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the locations where the test/service can be ordered.

Forgotten specification of componentsResolution: Accepted as suggested

HBOC 8.7.3.43

A Q (star) Life of the "unit." Used for blood products (asterisk) Life of the "unit." Used for blood products

Resolution: Accepted as suggested

HBOC 8.7.1 A T OM7 segment contains additional basic attributes that apply to the definition of most

OM7 segment contains additional basic attributes that apply to the

Retype to be consistent with the other segment wording.

Version 2.4 May Ballot Review Page 63

Name Sect V T Existing Wording Proposed Wording Commentsobservations/services. definition of most

observations/servicesResolution: Accepted as suggested

HBOC 8.7.3.12

A Q orderability In OM1.12 is orderability a word?

Kaiser 8.7.9.21

A S OM7-21 Orderable-at location (PL) 01497 PL does not seem to be the appropriate data type for a location that does not pertain to patients specifically. It would be better to use EI, HD, or CE.Resolution: Requires V2.x proposal with specific suggestion. Will be discussed at next meeting.

Version 2.4 May Ballot Review Page 64