Download Scope: What include and exclude in 3

October 2001 Minutes
Orders/Observations Worksession
Table of Contents
Table of Contents .........................................................................................................................................................1
Attendees ......................................................................................................................................................................2
Version 2.x Review ......................................................................................................................................................3
Proposal 168 - CM Data Type Replacement – Part 4 ........................................................................................3
Proposal 154 - Timing/Quantity Proposal Proposal 115 – Repeat Pattern Data Type Proposal ........................3
Proposal 172 – Data Type Continuation ............................................................................................................3
Proposal 176 - Specimen Segment Proposal ......................................................................................................3
Proposal xxx – POC Triggers and Messages .....................................................................................................4
Blood Bank V2.x Proposal ................................................................................................................................4
Version 3 Ballot Review ..............................................................................................................................................8
January Agenda .........................................................................................................................................................13
Attachment A – V2.x Proposals ................................................................................................................................ 14
CM Data Type Replacement Part 4 (OO) ................................................................................................................14
Timing Quantity (TQ1/TQ2) Segment Proposal ......................................................................................................24
Part 6 CM Data Type Replacement Proposal ..........................................................................................................56
Blood Bank Special Interest Group (BB SIG) .........................................................................................................64
Attachment B – Version 3 Ballot Response Summary ............................................................................................93
October 2001
O&O Minutes
Page 1
Attendees
Mon
PM
Tue
AM




[email protected]


[email protected]

Attendee
Company/E-Mail
Nina August
Hans Buitendijk
Jim Case
Laurecia DailyEvans
Carol Donahue
Tammy Dugan
Karen Eckert
Dav A. Eide
David Fallas
Charles Hawker
Frank Howard
Roark Hulet
Frank Innes
Julie James
Gaby Jewell
Neill Jones
Andrzej J. Knafel
Helmut König
Austin Kreisler
John Leslie
Peter Macisaac
David Markwell
Tom Marley
Ken McCaslin
Lloyd McKenzie
Dan Noack
Jeff Perry
Arkadi Popov
LaRae Prue
Alan Rector
Scott Robertson
Gunther Schadow
Benjamin C.
Schoenbrun
Karen Sieber
Anthony Smith
Wayne Tracy
Kendra Yen
[email protected]
[email protected]
[email protected]
Mon
AM
Tue
PM
Wed
AM
Wed
PM
Thu
AM
Thu
PM
Fri
















[email protected]

[email protected]


[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]










[email protected]
[email protected]
[email protected]
[email protected]
[email protected]






[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
























[email protected]






[email protected]


[email protected]
[email protected]



[email protected]
[email protected]
[email protected]
[email protected]









Communication with declared O&O participants can be done through [email protected]. You can sign up on this list
through HL7’s home page www.hl7.org.
October 2001
O&O Minutes
Page 2
Version 2.x Review
Proposal 168 - CM Data Type Replacement – Part 4






2.9.70 - Suggestion to add clarifying language if the title of Table 0100 is changed to Invocation Event.
Since this concept ties to trigger events in V3, maybe want to consider Invocation Trigger Event as the table
name. The vocabulary should be added to V3. No intent to make additions.
2.9.71 – Do not see a need to change the names to more generic, but if other parties discover the need, the
description should use the current names as examples.
2.9.72 – Suggest to provide description where charge code references multiple possibilities, e.g., points to
separate charge master, or to the “actual” service being charged, etc.
2.9.73 – Don’t want a separate segment (Issue 3). Agreement with suggestions 1, 2, and 3 on Issue 1.
Suggest that references to other definitions are either hyperlinks, or repeat the other definition. This is a
publication issue to keep it easy to read without jumping around. Leave the length increase to CQ.
2.974 – Agreement with name changes. Suggest to add “for example” to the third component’s definition to
clarify that it is not only restricted to micro. Concern that it may open up another grouping mechanism.
There is belief that it may already by used for reflex tests and the text already reference toxicology. We
agreed that it should references beyond what OO already uses. Concern that the generalization is not
appropriate as it really cannot be used elsewhere, other then OBR.26.
2.9.75 – Introductory text can go once the new TQ structure is accepted. If anybody outside OO uses it,
they need to provide input accordingly.
See Attachment A for proposed text with embedded comments.
Proposal 154 - Timing/Quantity Proposal
Proposal 115 – Repeat Pattern Data Type Proposal






Editorial in OMG that the TQ1/TQ2 structure was mistyped. 4.4.4 OMG message structure table has [{
TQ1 }] when it should just be TQ1.
Editorial in 4.13.6 to include RRE and 4/13/7 to change to 4.13.7
Agreed to keep Priority a default. Vote was 3-3-2 where current behavior superceded.
A motion was moved to approve the Repeat Pattern Data Type Proposal. There was not further discussion.
The motion was accepted with 9 in favor and 1 abstain.
A motion was moved to approve the Timing/Quantity Proposal. There were some clarifications on the
placement of the TQ1/TQ2 segments in the message structures. The motion was accepted with 8 in favor
and 2 abstain.
Both Austin Kreisler (McKesson) and Scott Robertson (Kaiser) were thanked for their efforts in creating a
much cleaner and syntactically correct structure around timing/quantity.
See Attachment A for proposed text with embedded comments.
Proposal 172 – Data Type Continuation
See Attachment A for proposal text with embedded comments.
Proposal 176 - Specimen Segment Proposal



General agreement from LAPOCT that a specimen segment makes sense. Various questions need to be
addressed though.
How is dependency between parent and dependent specimen, such as aliquot, derived, or components? Do
we need to keep parent ID, child ID (repeat), or both? Agreement to only have the parent ID. Suggest to
add Specimen Role with vocabulary from V3. Vote: Unanimous.
Suggestion to include SPM into SSU and SSR messages where the sequence would be SAC, SPM with
SPM optional. No objection. Need to change the diagram. Agreed that the diagram in the proposal only
applies to the order environment. For the lab automation environment in chapter 13 the diagram will be a
variant without the OBR. LAPOCT agrees with the proposed OML/ORL sequence. We are not sure yet
about query messages. We agreed that LAPOCT may make adjustments related to this specifically for
chapter 13.
October 2001
O&O Minutes
Page 3

Keep available volume and initial specimen volume in SAC as container specific info. Need better
explanation. Suggestion SAC-22 to be renamed to Container Available Volume and adjust definition.
Andrezj will address SAC clarifications and Jim the SPM clarifications.
Proposal xxx – POC Triggers and Messages

Will submit to V2 proposal database and contact Scott. Need to look at SPM and TQ1/TQ2.
Blood Bank V2.x Proposal
We reviewed the proposal and action items that were open up to the meeting. The following notes incorporate the
open issues and the resolutions at the meeting (flagged as O/O input). See Attachment A for the corresponding
updated in the actual proposal.
Create BBSig observation status flags and table for BP Observation Status (BPX-03
 Gaby>> This is a group effort. Assumably, O&O does not want us to use the OBX observation statuses
 Patti>> To my knowledge, we would only need three – Final, Preliminary and Corrected. Since those exst
in the original table, I don’t understand why we can’t use that table.
 O/O input – is there any reason that we can not support the existing table 85. Ok to use table 85 in this field
with changes made to document to reflect that this table is an HL7 table. Possible to indicate that some
values may not be supported in the BB environment/should indicate that the values not used have no
meaning in BB.
Need to show the relationship of conditional using something other than (+).
 Gaby>> the + and * were actually used to indicate blood component only fields and commercial product
only field. I renamed the fields. Those that begin BC are blood component only fields and indicate such in
the field definition. Those that begin CP are commercial product only fields and indicate such in the field
definition.
 Patti>> This seem fine to me.
 O/O Need to indicate in how BP, CP, and BC are used in the description of the elements of a segment It is
recommended that this explanation be placed in section 4.4 of the document.
In OMB, for NTE segment, need to enter a business statement for the type of note.
 Gaby>> matches Chapter 4’s annotation for ORM message definition.
 Patti>> No further comments
 O/O Added description of how notes will be used. It is accepted as written
BP Donation ID (BPX-05) recommended that this be an EI data type.
 Gaby >> done
 O/O Change made to segment is accepted as written. Version 3 note: will need to support unique identifier.
Need to determine the total number of characters will be specified for the identifier. Does this field need to
be repeating to support all the different places the number maybe generated? Need to validate that ABC
Codabar and ISBT 128 are defined ID issuing organizations.
Define the specification for which message has what requirements based on the product
 Gaby>> not real sure what this means
 Patti>> No further comments
 O/O We believe this is addressed through field definitions.
Need indicator to identify Commercial/blood product. This can be conveyed through the Manufacturer and Lot
number. (Felt that the universal Service Identifier defines the product).
 Gaby>> I think this is just a comment and no action is needed. We define the message as being for a
commercial product when the relevant fields are populated.
 Patti>> No further comments
 O/O This will be identified by the universal Service identifier.
October 2001
O&O Minutes
Page 4
BPX-11 (Blood Group). Adjust the conditional definition to state that field is required for blood components as well
as specified commercial products (such as detergent solvent plasma)
 Gaby>> I did. The statement reads, “This is a conditional field and is required for blood components and
certain commercial products (such as detergent solvent plasma).” Since it is for both components and
commercial products, left the name as BP Blood Group (rather than BC Blood Group for blood
component). Also, should the Blood Group in the BTX segment have the same statement? It currently
states that it is required for blood components only.
 Patti>> No further comments
 O/O Need to determine if the field is conditional field, because it is required in some case. Need more
definitions around the requirements. Need the rules for when the field is required.
BPX-12 (BP Special Testing) should be optional when there is no requirements so it needs to be changed to optional
from conditional.
 Gaby>> done.
 Patti>> No further comments
 O/O is the table owned by another organization and do we need the agreement to use the table? Need to
also talk to publication regarding placing other organization’s tables in the HL7 documents.
BPX-13 BP Expiration Date/Time Need to define conditions when this field in conditionally required. Need to build
use case for the requirements.
 Gaby>> Why? This field is defined as optional.
 Patti>> I don’t want to build too many specific rules for this. It will get too complicated when we get to
derivatives and accessories (filters, recipient sets),etc. Some of these have expiration dates, some do not.
 O/O this field is acceptable as an optional field. Recommend that if there are any AABB requirements that
could constraint this as a conditional field based on some conditions that make this field required.
Recommend a usage note to indicate that it is desired to have this field populated.
BPX-18 BP Actual Dispense to Location Need to support home health and other situations proposed to be CE and
an additional field for address. Not PL because it does not have enough fields per Scott Robertson from Kaiser. (we
later discussed that the actual home-health facility itself would be a dispense-to location built into the database just
like a ward/hospital location, and that including a patient’s address is not necessary for our purposes. We do not
need to have this address. CM)
 Gaby>> No changes made. It is actually a PL (Person Location) data type.
 Patti>> No further comments
 O/O May need to consider CE (Code Entity) then go to another field for the physical address of the
dispenser. Add a separate XAD field for the address (for the non coded address). This could create up to 3
fields to support a CE, PL, and XAD fields.
BPX-19 BP Dispensed to Receiver should be XCN. Need to support free text names.
 Gaby>> done.
 Patti>> No further comments
 O/O Accepted.
BPX-20 BP Responsible Observer – Need better name and description.
 Gaby>> Need someone else’s help here.
 Patti>> Are there are employee ID type fields in use anywhere? I don’t have the standard with me, so I
can’t look it up.
 O/O WIP BPX-21 BP Equipment Instance Identifier – Make this a repeating field and need to make sure that there is
information about repeating. Also need to make sure there is information.
 Gaby>> done.
 Patti>> No further comments
 O/O accepted. Need to review Producer’s ID field.
Where we have CE consider changing to CWE’s
October 2001
O&O Minutes
Page 5

Gaby>> The CWE data type indicates that you can send only free text if no code is provided for the concept
in the text. I searched the document for instances where it was indicated that free text was allowed in CE
fields. I found it only for BPX-8 Commercial Product, so I changed it to CWE. I question why we don’t
have the same statement for BTX-5 Commercial Product. We should probably go through each of the CE
data elements and determine whether the code is required or not. If it is required to be coded, the data type
should be CNE. CNE does not mean the field is required, it just means if there is a value in the field, it has
to be a valid code.
BPO-2 BP Universal service identifier (CE)
BPO-5 BP Units (CE)
BPO-10 BP Indication for Use (CE)
BPX-2 BP Status (CE)
BPX-6 BC Component (CE)
BPX-7 BC Donation type / intended use (CE)
BPX-11 BP Blood group (CE)
BPX-12 BC Special testing (CE)
BTX-3 BC Component (CE)
BTX-4 BC Blood Group (CE)
BTX-5 CP Commercial Product (CE)
BTX-10 BT Units (CE)
BTX-11 BT Transfusion Status (CE)
BTX-19 BT Adverse Reaction Type (CE)

Patti>> BP Units and BT Units should not be coded fields. Since there is always a text description even for
coded elements, I think the others should be coded.
BTX Blood Product Transfusion
BTX-02 BT Donation ID+ This should be changed to EI data type rather than ST and be more consistent with the
use case notes in the document.
 Gaby>> done.
 Patti>> No further comments
 O/O Done. Define BT at the beginning of 4.4
BTX-08 – Quantity BTX-09 Amount Will it ever be required for amount when Quantity is Required. Need to put
more information about the relationships of these two fields
 Gaby>> need help with this one.
 Patti>> Yes. Amount will be used to indicate the volume of blood components required when less than a
full unit is request. For example, they may order I unit containing 35 ml. Another example would be when
ordering factor concentrate. They will order 5 vials of Factor VIII dosage 2150 IU. Quantity should be
required. Amount is optional.
 O/O No additional rules that can be stated. BTX 9 and 10 can be combined. Need to clarify whether
BTX9/10 used when either overriding the implicit amount through BTX 3 or 5, or to describe the amount if
there is no implicit amount through BTX 3 or 5.
Recommend that fields BTX-18 and BTX-20 be eliminated as Y/N fields by the absences and presences of
information in BTX-19 and BTX-21.
 Gaby>> I didn’t do this because I don’t remember discussing it as a group.
 Patti>> I don’t remember discussing this as a group. I don’t have a problem with doing this, though. We
should probably bring it up again.
 O/O Consider to include AL1 as an optional repeats after BTX. Consider OBX repeat after the BTX to
support observations of allergies or adverse reactions to the transfusion.
Consider using the IAM to replace AL1 segment to replace the BTX-19&21.
 Gaby>> Again, I’m not opposed to talk about it.
 I am not familiar enough with the IAM segment to make a knowledgable decision.
October 2001
O&O Minutes
Page 6
Adverse events can be entered in the AL1.
 Gaby>> Okay, which one do they want? The IAM or the AL1? The AL1 seems more appropriate as the
IAM used to keep allergies in sync between 2 systems. What we’re really trying to convey is an adverse
reaction to a specific transfusion, right? The AL1 segment is really designed to send information about a
patient allergy. I’m not sure we have the information to complete the AL1 segment. It requires the allergy
code, and all we know is that the patient displayed an adverse reaction to a specific transfused product. I
suppose the allergy code would have to relate to a blood product (BP universal service id). The AL1 also
allows us to define the severity (Severe, Moderate, Mild) and the free text reaction. The problem is it
doesn’t allow us to tie it back to a specific blood component or commercial product. We can require that
association by it’s placement within the message (the AL1 segment must also follow the BTX segment to
which it is associated). Thoughts?
 Patti>> I don’t like the idea of using the AL1 segment. You are right – we need to be able to tie it back to a
transfusion event. I would orefe r to keep it right in our own BTX segment.
BTX-14,15, 20 have cut and past problems need to resolve.
 Gaby>> May have been done by Lloyd as I didn’t see any problems.
 Patti>> No further comments. I can’t see qnything.
 O/O Has already been resolved
BTX 18, 19 will be repeating fields.
 Gaby>> done. If we don’t use the AL1 segment, only field 19 needs to repeat.
 Patti>> Agreed.
 O/O Agreed .
Need to support TQ1 and TQ2 segments.
Does BBSIG need to support SAC segments?
Need to BTX
BPX-15 Change data type to a CQ
BPX-16 should be eliminated
Define BT to BP – Consider if possible.
October 2001
O&O Minutes
Page 7
Version 3 Ballot Review
We spend most of Tuesday through Thurday to review the V3 ballot feedback. The numbers correspond to the
entries in the table in Attachment B.
Common Review
 Issue 11, 19 - Need interactions for nullified and obsolete states.
This issue relates to the There were two triggers with two interactions. “Supercede” became “obsolete”
and “nullified” was added. Need to combine the triggers/interactions for supercede and add one for
nullified. We need other interactions as well since we can go from anywhere to obsolete. We agreed to
define interactions as follows:
1. (Obsolete) Normal to Obsolete – Common
2. (Obsolete) Normal to Obsolete and Null to Normal – Lab
3. (Obsolete) Normal to Obsolete and Null to Normal – Rx
4. (Obsolete) Normal to Nullified – Common
5. (ReActivate) Complete to Active – Rx – Medication SIG will determine whether it will be put in scope.
6. (Revise) Complete to Complete – Lab
 Need a Revise on New in the state machine. Will not create interactions for them. Needs to go to
harmonization.
 Need interaction that is tied to two state transitions. MnM
 Issue 24 - Missing receiver request and sender notify role interactions for abort, resume, cancel, hold.
They are located in section 5. Hold is outside the scope of the first cut. Request to withdraw negative.
 Issue 25 - Missing sender and receiver interactions for cancel, abort, resume, hold, and notify activate,
notify supercede.
The first three are dealt with in general order messages, hold is out of scope, notify activate is there, and
notify supercede is being revamped. Request to withdraw negative.
 Issue 32, 12, 13 – Storyboards and diagrams
We agreed to create a number of Lab and Rx storyboards. Cross Lab/Rx storyboards will be “nice to have”
and therefore be low on the priority list. On Wednesday and Thursday respectively we will establish the
storyboard and example outlines. We will need one point person to orchestrate each effort to be overall
synchronized by Hans. Ladder diagrams are part of the storyboard (one ladder diagram per storyboard).
Therefore the current ladder diagrams will collapse and be combined.
 Issue 33 –
See Issue 32 resolution
 Issue 43 Agreed to change the wording to “shared or synchronized repository”. Hans withdrew the minor negative.
 Issue 46 We did not distinguish at the trigger event level. New storyboard approach will avoid having to create
different storyboard based on loosely vs. closely coupled variants. We had agreed to only address closely
and loosely coupled variants as part of the first V3 iteration. Other variants can be addressed later based on
specific use cases. Interactions require separation. Request MB to withdraw.
 Issue 18 – Act.priority_cd vocabulary is missing.
We had already agreed that USAM values would be used, but did not make it. Needs to be submitted to
harmonization. Austin will withdraw the negative when harmonized.
 Issue 73 Committee accepts suggestion to change cardinality to 0. Will forward to the CMET Group with OO
endorsement.
 Issue 8 Acceptance to add minimum required attributes and will be passed to CMET Group as proposed changes.
Austin will withdraw once addressed.
 Issue 14 - Application Acknowledgement can’t require application acknowledgement
Control/Query already agreed with the use case and is willing to allow for this. Methodology allows for it.
OO endorses the need. Austin is willing to withdraw when Control accepts.
 Issue 86 – Vocabulary
Need improved vocabulary.
 Issue 80 – Description Enhancements
There is agreement that this must be done.
 Issue 60 - Print suppression in Micro Biology.
October 2001
O&O Minutes
Page 8
Topics for further discussion:





Normal to Obsolete, Normal to Nullify. Lloyd did some RMIM's for common messages for normal to
Obsolete.
Allergy CMET, Allergy management. We will deal with this in detail during the 3 rd Quarter.
Vocabulary - Determine what the holes are. Lloyd suggested doing a query against the data base to find this
out.
Description Enhancements. Discussed how to deal with enhancing descriptions. Charlie Hawker was
volunteered by the LAPOCT people. I latter verified that he was okay with this.
Need a mid November conference call to go over Descriptions.
Lab Storyboard Volunteers - Laurecia Dailey-Evans. Kaiser (Scott Robertson is the contact) and Quest (Ken
McCaslin is the contact) will be participating also.
Lab Descriptions Volunteers - Charlie Hawker. Kaiser (Scott Robertson is the contact) and Quest (Ken McCaslin is
the contact) will be participating also.
Allergy Discussion
 We are limiting the scope to an Allergy CMET. We won't include Allergy management messages in the next
ballot.
 Remove Device from Authoring Choice.
 The CMET won't have a capability to report allergy history.
 Rename the base class from Allergy to Intolerance.
 Remove AR_Component from the R-MIM.
 Restrict Intolerance.value data type to UVP(CE) and UVN(CE), using coding strength CWE.
 Add in attribution information (author, verifier, etc. from message control.
21 – missing interaction diagrams. Discussion: Noted that there are very few storyboards in the pharmacy ballot.
There were more storyboards submitted, but there was insufficient time to code into the ballot format. Response:
Yes, will be addressing the need for additional storyboards
22 - discussion: essentially the same as 21. Response: will be resolved with further storyboard work.
23 – missing sending role interactions for. Discussion: took a different approach than lab. Integrated tracker and
placer. Response: pharmacy roles will be revised to follow the same construct as lab.
26 – placer/filler breaking complex orders into individual event orders (i.e., dispense now). Discussion: some
applications deal with the complex order while others only deal with individual administration instances. Daphne's
comment appears to ask for an application to support both. The two scenarios are not mutually exclusive, an
application may be able to support both. It did not seem to be necessary to create a combined role, but with recent
changes in methodology, this is now possible. Resolution: will create a container application role to combine both
roles.
Nn – medication vs packaged medication. Discussion: medication cmet represents something that can be
administred. Packaged medication is something that is meant to be dispensed, which may include package info,
administratation devices. Packaged medication cmet references the medicinal product CMET. Response: cmet
descriptions will be revised to clarify intent and relationships or families of related CMETs.
Nn – vaccination management? Discussion: current vaccination is not separated as distinction orders in v3.
Vaccinations do have additional "tracking" and query requirements, however this may not be very different from the
requirements for cytotoxic regimens. We could add a means to identify a product as a vaccine, cytotoxic, etc. at the
least, we need to have vaccine related stories. An additional role(s) and interactions for vaccination
management/reporting may be necessary. Some question as to whether this is within current scope. Some of these
requirements may be business rule requirements, but the message content must support these requirements. Also,
vocab will need to incorporate terminology needed for vaccine messages/report. Response: will confirm/support
identification of a order as a vaccination order within the current pharmacy messages for special reporting
October 2001
Page 9
O&O Minutes
requirement at the order and administration event and dispense. (to support multiple reporting concepts e.g., vaccine,
controlled substances, antibiotic survey).
79 – what is P_subject 1 to many rather than 1 to 1. Discussion: was originally to support orders for families or
herds, but the CMET has been enhanced to support the concept of a group. Response: will revise cardinality to
1..1.
82 – already discussed
84 – identification of contraindications. Discussion: need to discuss the modeling of contraindications in more
detail.
85 – means to request an event. Discussion: the concept of instance orders was to support this requirement.
Response: withdrawn by submitter
27 – cd is act_code, implies that any act code is acceptable. Discussion: a vocab issue. Clinical drug is still being
settle. There may be realm-specific requirements. But there still may be need for a universal vocabulary to support
messages between realms. Further vocab work is needed. Response: Need to have domain defined and constrain cd
to that domain in the message model (keyword: harmonization)
general discussion:
 Do the messages support a primary recipient and "cc's"? This is supported in infrastructure. The message
content does not change but the message wrapper is different. Further discussion on the concept of multiple
trackers. New security issues may
 Plan for remainder of the day:
 Vocab issues: where are the holes, what is needed now, what can happen later
 Contraindications: identification, messaging issues, overrides,
 Queries: start discussion, what is absolutely needed for immediate ballot
 Storyboards …
 Call for volunteers to the CMET group
 Tom Marley

action items:


Lloyd: need to confirm that pharmacy msgs support shelf expiration and reconstitution expiration.
The second quarter focused on.

Plan for remainder of the day:
 Quick run-through the ballot
 Vocab issues: where are the holes, what is needed now, what can happen later
 Contraindications: identification, messaging issues, overrides,
 Queries: start discussion, what is absolutely needed for immediate ballot
 Storyboards …

action items (drawn forward through minutes):



(Wed Q1/Lloyd) Need to confirm that pharmacy msgs support shelf expiration and reconstitution expiration.
(Wed Q2/Lloyd) request definitive statement on attribute renaming from MnM
(Wed Q2/Lloyd) we need to look at e-claim material relative to UK container orders
October 2001
O&O Minutes
Page 10
>>Negative ballot item from MedRec. MedRec has renamed their act.id's to act.id_filler and act.is_placer. Neg
ballot by Austin to have them change back to act.id. push back that maybe orders (lab, pharmacy, ord) should use
id_filler and id_placer. Discussion acknowledges that a person may have difficulty differentiating between the ids,
but a computer would not. Additionally, new tooling will allow annotations to be conveyed down through the RMIM and HMD. Generally, attribute renaming is not considered a good idea. Outcome: Lloyd will bring issue of
attribute renaming to MnM to request a definitive statement. Ord/Pharm does not find the argument to rename the
attributes compelling, but does agree that better annotations are needed. Wayne may be willing to change back if
appropriate annotation can be introduced and maintained through all necessary levels of the messaging documents.
>>Overview/Review of Pharmacy V3 ballot by Lloyd.
Pharmacy Domain: Health & Clinical Management (HM)  Practice & Operations (PO)  Pharmacy (RX). All
artifacts are of the form HMPO_RX_xxnnnn.
Storyboards will be added to the domain level
Interaction categories are a means to group related trigger events, interactions and storyboards. Lab and Pharmacy
used a common set of categories of Order, Intent and Event.
Trigger events are an occurrence of some sort that results in one or more messages being sent. May be sent from one
application to another, or from an application to itself.
Message type is a structure that is used to send information. A type may be used in different contexts and result in
different activities on the receiving side.
Interaction is a specific message sent between two applications (or one application to itself). An interaction is a
specific message type being sent between a specific sender application (role) to a specific receiver application (role)
resulting from a specific trigger event.
(Additional definitions and descriptions can be found in the v3 guide and the backbone)
Questions led to the discussion of the state diagram. Theoretically, all states can be applied to all domains, however,
in practice some states are not relevant. For pharmacy, the new (and related states) may not be significant.
Most trigger events relate directly to state transitions. But there are trigger events that are not tied to a state
transition, e.g., a query is not a state transition. MnM is developing more specific language on when a trigger event
must be tied to state transitions.
The super-state of normal permits the transition from any of the sub-states to nullified or obsolete. An object must
exist in a sub-state of normal, but exists in normal only in relation to the sub-state.
Discussion of relationship of actions within an application as it relates to the state diagram. Some systems,
particularly MedRec, each revision of an order may be modeled as a separate object. This may be different model
concept: each revision would be a new instance rather than revisions to an given instance. In these cases, the only
need is to transition from null to normal and normal to obsolete. In these cases, it is suggested that this modeling
would use null to complete and complete to obsolete. This is in terms of messages between MedRec systems …
messages between MedRec and Lab would depend on messaging concepts of the Lab application. The filler would
send the results back to the placing system … while the filler may be changing the state to complete, the placing
system transitions to complete only when all intents associated with the order are complete. (The state of the order
on the placing system does not have to match the state of the filler system intent.)
Moods: Intent is a superset of Order. OO uses Intent in a specific way: the placer sends the Order and the filler
responds with an Intent message. The Intent contains the filler's agreement to do the requested service and any
interpretation or refinement of the Order (what would be the "encoded order" in v2x). Differentiation between Order
and Intent is done in terms of the trigger event and the application role. All are identified as separate artifacts in v3.
October 2001
O&O Minutes
Page 11
Concept of a container order. Where an order exists that consists of multiple orders. Example, a single prescription
that contains orders for three medications has an identifier for the order and separate identifiers for each of the
separate medications. (In the UK this can effect patient charges, one order of three things is charged differently than
three separate orders.)
OO 4th Quarter
 Quick Meeting with Medical Records. Discussion about changing Act.id attribute name (i.e., rename the
attribute in the R-MIM/HMD's). An alternate solution to Wayne's issue is to add a small comment to the
HMD for an alternate description for the attribute name. This appears to be the solution to the issue.
Medical Records will be reverting to the original attribute (id).
 MR wants OO to approve adding ORC/OBR addition to med record messages. OO doesn't have an issue
with this proposal. MR is going to evaluate if TQ1/TQ2 need to be added.
Other OO Stuff
The OO representatives to the new CMET group are Tom Marley (Pharmacy) and Manish Narang (LAPOCT).
Manish was volunteered by a LAPOCT co-chair (Andrzej Knafel), so this hasn't been confirmed with Manish. OO
doesn't have direct representation on the CMET group. As Austin pointed out at the meeting, direct OO membership
seems to have been dramatically reduced due to all the SIG's we now have. We have gone from one of the largest
committees to one of the smallest (no counting the SIG members). Austin feels don't know if this is a good thing or a
bad thing, but it does mean we are getting stretched pretty thin when it comes to things like this.
October 2001
O&O Minutes
Page 12
January Agenda
The agenda for January is tentatively defined as follows:
Monday
Tuesday
Wednesday
Thursday
Friday
October 2001
O&O Minutes
09:00 – 10:30
AM1
OO – Finalize
V2.5 proposals
11:00 – 12:30
AM2
OO - Finalize
V2.5 proposals
OO + Med + BB
+ LAPOCT –
V3
OO + Med – V3
OO + LAPOCT
– V3
OO – Finalize
V2.5 proposals
OO + Med + BB
+ LAPOCT –
V3
OO + Med – V3
OO + LAPOCT
– V3
OO – Finalize
V2.5 proposals
01:45 – 03:00
PM1
OO+LAPOCT –
Finalize V2.5
proposals
OO + Med + BB
+ LAPOCT –
V3
OO + Med – V3
OO + LAPOCT
– V3
Adjourn
03:30 – 05:00
PM2
OO + BB –
Finalize V2.5
proposals
OO + Med + BB
+ LAPOCT –
V3
OO + Med – V3
OO + LAPOCT
– V3
05:00 >>
Evening
Page 13
Attachment A – V2.x Proposals
CM Data Type Replacement Part 4 (OO)
Short Description:
Continue to define new data types to replace existing CM data types.
Justification:
This proposal replaces proposal # 141 and a portion of proposal # 135. Continuation of
proposal # 155,165, 166 and 167.
Data Types
2.9.70
Components:
CCD- charge code and date
<when to charge code (ID)> ^ <date/time (TS)>
HL7 Component Table - CCD – charge code and date
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
1
ID
R
100
When to charge code
2
26
TS
O
Note:
COMMENTS
SEC.REF.
Date/time
Replaces the CM data type used in section 4.5.2.1 BLG-1, as of version 2.5.
Definition: This field specifies when to charge for the ordered service.
Issue: CQ teleconference 9/19: Consider generalizing. Specifies whether an action is based on an invocation
event or is time-based.
2.9.70.1 When to charge code (ID)
Definition: The first component contains a value defined in HL7 Table 0100 - When to charge.
HL7 Table 0100 - When to chargeInvocation Event
Value
Description
D
On discharge
O
On receipt of order
R
At time service is completed
S
At time service is started
T
At a designated date/time
OO 10/1/01: expand narrative to support new name, examples or some indication of broader context.
These concepts not included in current v3 development … these are very similar to trigger events. These
values will need to be added to v3 vocabulary.
2.9.70.2 Date/time (TS)
Definition: . The second component is used to express the exact time to charge for the ordered service; it is
used only when the when to charge value is T. When used, it is expressed as a TS data type.
October 2001
O&O Minutes
Page 14
2.9. 71 EIP- entity identifier pair
Components:
<parent's placer order number (EI)> ^ <parent's filler order number (EI)>
Subcomponents of parent’s placer order number: <entity identifier (ST)> & <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (IS)>
Subcomponents of parent’s filler order number: <entity identifier (ST)> &
<universal ID (ST)> & <universal ID type (IS)>
<namespace ID (IS)> &
HL7 Component Table - EIP – entity identifier pair
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
EI
Parent's placer order number
2
EI
Parent's filler order number
COMMENTS
SEC.REF.
Note: Replaces the CM data type used in sections 4.5.1.8 - ORC-8, 4.5.3.29 – OBR-29, 7.3.1.29 – OBR-29, as of
version 2.5.
Definition: TBD
Issue: This data type should be more general. The current component names should
stand as field names.
Suggested Solution: Component 1 – Identifier 1; Component 2 – Identifier 2
Sept 19 CQ teleconference Response: We need a use case before generalizing.
2.9.71.1 Parent's placer order number (EI)
Definition: The placer order number of the parent order.
2.9.71.2 Parent's filler order number (EI)>
Definition: The filler order number of the parent order.
OO 10/1/01 – agree not to generalized unless a use case exists. If generalized, the orignial meaninig of
placer/filler should not be lost … include as example.
2.9.72 MOC- money and code
Components:
<dollar amount (MO)> ^ <charge code (CE)>
Subcomponents of dollar amount:
<quantity (NM)> & <denomination (ID)>
Subcomponents of charge code: <identifier (ST)> & <test (ST)> & <name of coding system (IS)> &
<alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
HL7 Component Table - MOC – Money and code
SEQ
LEN
DT
OPT
1
15
MO
O
Dollar amount
2
250
CE
O
Charge code
Note:
October 2001
O&O Minutes
TBL#
COMPONENT NAME
COMMENTS
SEC.REF.
Replaces the CM data type used in sections 4.5.3.23 OBR-23 and 7.4.1.23- OBR-23 as of version 2.5.
Page 15
Definition: This field is the charge to the ordering entity for the studies performed when applicable.
Issue: Need to increase field length from 40 to at least 250, the length of the largest component.
Issue: The intent of the MO data type as of version ?? is that it be used only in the
CP data type.
Solution:
1) Change the MO narrative to include usage within the MOC as well as the CP
OR,
2) Deprecate component 1 and replace with a new component 3 composite price.
2.9.72.1 Dollar amount (MO)
Definition: The first component is a dollar amount when known by the filler.
2.9.72.2 Charge code (CE)
Definition: The second is a charge code when known by the filler (results only).
Issue: What does this mean?
Issue: Need user-defined table. Does one exist? This is unclear. There is a Charge Code element in segment
field LCC-4 that has user-defined table 0132 transaction code assigned. The narrative for LCC-4 says to
use the same values as in FT1-7 transaction code.
OO 10/1/01 – pure charge codes that are parallel to the service items. Not clear of the intent, inadvisable to
specific as this not relate to current use(s). Rather than specify, detail the possible intents of the component.
2.9. 73 NDL – name with date and location
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^
<room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient
location type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name (ST)> & <given name (ST)> & <middle
initial or name (ST)> & <suffix (e.g., JR or III) (ST)> & <prefix (e.g., DR) (ST)> &
<degree (e.g., MD (ST)> & <source table (IS)> & <assigning authority (HD)>
Subcomponents of facility:
<namespace ID (IS)> & <universal ID
(ST)> & <universal ID type (ID)>
HL7 Component Table - NDL – name with date and location
SEQ
LEN
DT
OPT
1
250
?
CN
B?
2
26
TS
3
26
TS
TBL#
COMPONENT NAME
SEC.REF.
Name
Start date/time
End date/time
4
IS
302?
Point of care
5
IS
303?
Room
6
IS
304?
Bed
7
HD
362??
Facility
8
IS
306?
Location status
9
IS
305?
Patient location type
October 2001
O&O Minutes
COMMENTS
Page 16
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
10
IS
307?
Building
11
IS
308?
Floor
COMMENTS
SEC.REF.
Note: Replaces the CM data type used in sections 4.5.3.32 and 7.4.1.32-( OBR-32) , 4.5.3.33 and 7.4.1.33 - ( OBR33) 4.5.3.34 and 7.4.1.34 - ( OBR-34) 4.5.3.35 and 7.4.1.35 - ( OBR-35) as of version 2.5.
Definition: Specifies the name of the person performing a service, when the person performed the service
and where the person performed the service. Is this correct?
Issue 1: This construction is a concatenation of the CN data type (that was
deprecated and replaced by XCN in v 2.3), 2 elements of type TS, and an outdated
version of the PL data type. The CN as a component of NDL has 2 subcomponents
FN and HD that cannot be legally expressed in that they in turn have
subcomponents.
Suggested Solution:
1) Update the PL portion to 2.5
2) Deprecate the name component and replace with a new Person Name
component at the end with an XCN that has been flattened.
3) Assign table numbers as they currently exist for the PL and XCN data types.
4) Three of the 4 fields in question repeat so it is difficult to turn this into 2 fields
like we have done in some of the pharmacy segments.
Issue 2: Length should be increased from 200 to nnn. The CN component itself could
probably run 250 as could the PL portion if fully populated.
Issue: Should this be a segment?
10/01/01 OO – do not favor a new segment
The components below are the current components in the current order.
Name (CN)
Definition: Name of person performing a service.
Retained for backwards compatibility only. Cannot be fully expressed legally. Refer to components
nn –nn instead.
2.9.73.1 Start date/time (TS)
Definition: The starting date and time for what? When the person is performing the service?
2.9.73.2 End date/time (TS)
Definition: The ending date and time for what? When the person is performing the service?
2.9.73.3 Point of care (IS)
Definition: See PL.1, section 2.9.21.1
October 2001
O&O Minutes
Page 17
10/01/01 OO – using only reference is difficult to work with. Copy definition and retain reference? A
publications issue.
2.9.73.4 Room (IS)
Definition: See PL.2, section 2.9.21.2
2.9.73.5 Bed (IS)
Definition: See PL.3, section 2.9.21.3
2.9.73.6 Facility (HD)
Definition: See PL.4, section 2.9.21.4
2.9.73.7 Location status (IS)
Definition: See PL.5, section 2.9.21.5
2.9.73.8 Patient location type (IS)
Definition: See PL.6, section 2.9.21.6
2.9.73.9 Building (IS)
Definition: See PL.7, section 2.9.21.7
2.9.73.10 Floor (IS)
Definition: See PL.8, section 2.9.21.8
2.9.73.11 Location description (should this be added?)
Definition: TBD
2.9.73.12 Comprehensive identifier (should this be added?)
Definition: TBD
2.9.73.13 Begin XCN flattened list??
Definition: TBD
OO 10/01/01 – agree with suggestions 1, 2, and 3. Issue 2, length, agree that length needs to be increased
2.9.74 PRL- parent result link
Components:
<OBX-3-observation identifier of parent result (CE)> ^ <OBX-4-sub-ID of parent result
(ST)> ^ <part of OBX-5 observation result from parent (TX)see discussion>
Subcomponents of OBX-3-observation identifier of parent result: <identifier (ST)> & <test (ST)> &
<name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> &
<name of alternate coding system (ST)>
HL7 Component Table - PRL – Parent result link
SEQ
LEN
DT
1
250
COMPONENT NAME
COMMENTS
CE
OBX-3-observation identifier of
parent result Parent Observation
Identifier
defined in the
OBX-3 of the
parent result.
2
ST
OBX-4-sub-ID of parent result Parent
Observation Sub-identifier
defined in the
OBX-4 of the
parent result.
3
TX
Part of OBX-5 observation result
from parent Parent Observation
Value Descriptor
Taken from the
OBX-5 of the
parent result.
October 2001
O&O Minutes
OPT
TBL#
SEC.REF.
Page 18
Note:
Replaces the CM data type used in sections 4.5.3.26 - OBR-26 and 7.4.1.26 - OBR-26 as of version 2.5.
Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This
important information, together with the information in OBR-29-parent, uniquely identifies the parent
result’s OBX segment related to this order. The value of this OBX segment in the parent result is the
organism or chemical species about which this battery reports. For example, if the current battery is an
antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the
organism on which the susceptibility was run. This indirect linkage is preferred because the name of the
organism in the parent result may undergo several preliminary values prior to finalization.
Issue: Component names beginning with a segment field identifier would seem to be ill-advised. Consider
names like Parent Result Identifier for component 1 and Parent Result Sub-identifier for component 2. The
narrative could describe the source of the identifier and sub-identifier. This needs to be evaluated by OO.
Definition: TBD
2.9.74.1 OBX-3-observation identifier of parent result Parent Observation Identifier (CE)
Definition: Contains the unique identifier of the parent observation as defined in the OBX-3 of the parent
result. The value is the same as the OBX-3 of the parent.
2.9.74.2 OBX-4-sub-ID of parent result Parent Observation Sub-identifier (ST)>
Definition: Contains the sub-ID of the parent result as defined in the OBX-4 of the parent result. The value
is the same as the OBX-4 of the parent.
2.9.74.3 Part of OBX-5 observation result from parent Parent Observation Value
Descriptor (TX)
Definition: Contains a descriptor of the parent observation value as specified in the OBX-5 of the parent
result.
As an example, the third component may be used to record the name of the microorganism identified by the
parent result directly. The organism in this case should be identified exactly as it is in the parent culture.
Issue: Need to establish a good name for this component.
Issue: Definition needs to be fixed to include other uses than micro-organisms.
OO 10/01/01 – agree with component name changes. Note change to component 3 narrative, some thought
that this field was added to support micro, may also be used for reflex tests, generally a narrow, focused use.
If rewritten for wider use, will this just provide another method of grouping. Should not be rewritten to
expand beyond what has been defined by Orders.
Some of the field note from chapter 7 has not been pulled forward into this definition. This may have lost
some of the intent of the data type. The original field note does not generalize well. Suggest that the data
type should not be generalized in this nature. Keep more of the original language and specify that the data
type has a very limited application … just to be used for OBR.
2.8.75 OSD - order sequence definition
components:
October 2001
O&O Minutes
<Sequence/Results flag (ID)> ^ <Placer Order Number: Entity Identifier (ST)> ^
<Placer Order Number: Namespace ID (IS)> ^ <Filler Order Number: Entity Identifier
(ST)> ^ <Filler Order Number: Namespace ID (IS)> ^ <Sequence Condition Value (ST)> ^
< Maximum Number of Repeats (NM)> ^ <Placer Order Number: Universal ID (ST)> ^
<Placer Order Number: Universal ID Type(ID)> ^<Filler Order Number: Universal ID
(ST)> ^ <Filler Order Number: Universal ID Type(ID)>
Page 19
HL7 Component Table - OSD – order sequence definition
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
nn
Sequence/Results flag
1
ID
2
ST
3
IS
4
ST
5
IS
6
ST
Sequence Condition Value
7
NM
Maximum Number of Repeats
8
ST
9
ID
10
ST
11
ID
Note:
COMMENTS
SEC.REF.
Placer Order Number: Entity
Identifier
0363
Placer Order Number: Namespace
ID
Filler Order Number: Entity Identifier
0363
Filler Order Number: Namespace ID
Placer Order Number: Universal ID
0301
Placer Order Number: Universal ID
Type
Filler Order Number: Universal ID
0301
Filler Order Number: Universal ID
Type
Replaces the CM data type used in the TQ data type, component 10, as of version 2.5.
Definition: This data type specifies a fully coded version for forming a relationship between an order and
one or more other orders. The relationship may be sequential or a cyclical pattern. Usage of the OSD is
restricted to the TQ data type.
Issue: Can we strike most of the following introductory narrative since the TQ is being deprecated?
OO 10/1/01 - Assuming that TQ is accepted, then this might be struck out. However, not everybody may
implement the new TQ construct, we do not want to lose valid narrative. The level of sequencing allowed
by this data type would seem to indicate that the implementors would move to the new TQ. Appears
reasonable to strike language as appropriate.
There are many situations, such as the creation of an order for a group of intravenous (IV) solutions, where
the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g.,
hyperalimentation with multi-vitamins in every third bottle.
There are other situations where part of the order’s instructions contains a results condition of some type,
such as “PRN pain.” There is currently a free text “condition” component of ORC-7-quantity/timing which
allows any condition to be specified.
The sequencing conditions supported by this 10th component are based on the completion of a predecessor
service.
Usage Notes:
a)
Cyclic placer order groups
To implement a cyclic group of four IV orders using the parent/child paradigm, the parent specifies
a custom group of IVs, and the following occurs:
October 2001
O&O Minutes

ORC-7 quantity/timing of the second child order specifies that it follows the first child order.

ORC-7 quantity/timing 2 of the third child order specifies that it follows the second child
order.
Page 20

ORC-7 quantity/timing of the fourth child order specifies that it follows the third order.
To repeat the group of four child orders in a cyclic manner, the following occurs:

ORC-7 quantity/timing of the first child order specifies that it is to be executed once without
any dependence on the completion of other orders. Its second execution follows the
completion of the fourth order. See example in Section 4.15.2, “RXO segment field examples.
This scheme allows the following to be tracked:

The status of the whole group of orders to be reported back at the level of the parent order.

The status for each individual IV order by following the status of the corresponding child
order.
Separate Orders example:

b)
The same group of orders can be sent as a group of four orders (without a common parent),
linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7
method of transmitting the order status of the group as a whole without transmitting the status
of each of the four separate orders.
Inheritance of order status
Cancellation/discontinuation/hold order control events:

This logic implies the normal execution of the referenced predecessor order. Thus a
cancel (or discontinuation or hold) of a predecessor order implies the cancellation (or
discontinuation or hold) of all subsequent orders in the chain.

If the referenced order has been canceled (or discontinued or held), the current order
inherits that same status.
In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given
order (which can then be executed according to the specification in the TQ2 segment).
2.9.75.1 Sequence/Results flag (ID)
Definition: Identifies whether sequence conditions or a repeating cycle of orders is defined.
HL7 Table nnnn – Sequence Condition Code
Value
Description
S
Sequence conditions
C
Repeating cycle of orders
R
Reserved for possible future use
2.9.75.2 Placer Order Number: Entity Identifier (ST)
Definition: Required component that contains the first component of the placer order number, entity
identifier .
2.9.75.3 Placer Order Number: Namespace ID (IS)
Definition: Optional component that contains the second component of the placer order number, namespace
ID. Refer to user-defined table 0363 - Assigning Authority for suggested values.
October 2001
O&O Minutes
Page 21
2.9.75.4 Filler Order Number: Entity Identifier (ST)
Definition: Required component that contains the first component of the filler order number, entity
identifier .
2.9.75.5 Filler Order Number: Namespace ID (IS)>
Definition: Optional component that contains the second component of the filler order number, namespace
ID. Refer to user-defined table 0363 - Assigning Authority
2.9.75.6 Sequence Condition Value (ST)>
Definition: Defines the relationship between the start/end of the related predecessor or successor order and
the current order from ORC-2,3 or 4.
The acceptable condition values have the form commonly used in project planning methodologies: <one of
“SS”, “EE”, “SE”, or “ES”> +/- <time>
Issue: Should we declare an HL7 defined table ???? This is under consideration for
the TQ2 segment.
HL7 defined table ????
Value
Description
EE
End related order(s), end current order.
ES
End related order(s), start current order.
SS
Start related order(s), start current order.
SE
Start related order(s), end current order.
*
The first order in a cyclic group
#
The last order in a cyclic group.
For the special case where there is a cycle of orders that must be repeated, the first order to be executed will
have a “sequence condition value” whose first repeat must be an asterisk (*). The last order to be executed
may have a “sequence condition value” whose first repeat must be a pound sign (#). Example:
...|*~ES|+10^min|...
translates to: execute this order the first time without evaluating the
condition specified in the TQ2 segment; but repeat only its execution
when the specified external order’s start or finish date/time has met this
condition. This specification generates a repetition of the order for each
iteration of the cycle.
Note: This requires that the ordering application be able to specify the placer/filler/placer group order number of the last
order in the cycle in the first order’s quantity/timing specification.
2.9.75.7 Maximum Number of Repeats (NM)>
Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats
is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.
2.9.75.8 Placer Order Number: Universal ID (ST)>
Definition: Required component that contains the next to the last component of the placer order number,
universal ID
October 2001
O&O Minutes
Page 22
2.9.75.9 Placer Order Number: Universal ID Type(ID)>
Definition: Optional component that contains the last component of the placer order number. Refer to HL7
table 0301 - Universal ID Type for valid values.
2.9.75.10 Filler Order Number: Universal ID (ST)>
Definition: Required component that contains the next to the last component of the filler order number,
universal ID .
2.9.75.11 Filler Order Number: Universal ID Type(ID)>
Definition: Optional component that contains the last component of the placer order number. Refer to HL7
table 0301 - Universal ID Type for valid values.
October 2001
O&O Minutes
Page 23
Timing Quantity (TQ1/TQ2) Segment Proposal
Short Description:
Replace the TQ data type with two new segments, the TQ1 and TQ2.
Justification:
The TQ data type has a number of “features” that break the HL7 message encoding rules as given in chapter 2. To
correct these problems, and retain the TQ as a data type would require several changes to the message encoding
rules, and adding sub-sub-component delimiters, component and sub-component repeat delimiters. A much simpler
approach is to migrate this data type to a pair of new segments.
Subcommittee Findings:
This proposal is nearly complete. Once the full Orders Working Group reviews and approves the proposal, it will be
complete.
Issues:

Need to incorporate examples of usage.
Usage of the TQ1/TQ2:
TQ1 and TQ2 would form a repeating segment group within a message. The group would be in the form:
[{ TQ1 [{ TQ2 }] }]
October 2001
O&O Minutes
Page 24
Tying TQ1/TQ2 to Version 3.0:
The TQ1/TQ2 grouping has similarities to the Service/Service Relationship classes in version 3.0. The
TQ1 segment is used to define timing/quantity information about the order (service) it is associated. The
TQ2 segment is used to define the relationship between the order (service), and a separate order (service).
Adopting this type of segment group in orders gives us a bridge between 2.x orders and the version 3.0 Act
paradigms.
Suggested Solution:
4.3
Quantity/Timing (TQ) Data Type Definition
The TQ data type has a number of “features” that break the HL7 message encoding rules as given in chapter 2. To
correct these problems, and retain the TQ as a data type would require several changes to the message encoding
rules, and adding sub-sub-component delimiters, component and sub-component repeat delimiters. A much simpler
approach is to migrate this data type to a pair of new segments (TQ1, and TQ2). See sections 4.4 and 4.5 for more
details on the TQ1 and TQ2 segments. The TQ data type is maintained strictly for backward compatibility and may
not be used for the definition of new fields.
4.4.3 OSQ/OSR- query response for order status (event Q06)
OSR^Q06
Order Status Response
MSH
MSA
[ERR]
[{NTE}]
QRD
[QRF]
[
[PID
[{NTE}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
<OBR|RQD|RQ1|
RXO|ODS|ODT>
[{NTE}]
[{CTI}]
}
]
[DSC]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
Query Definition
Query Filter
Chapter
2
2
2
2
2
2
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
[Order Detail Segment] OBR, etc.
4
Notes and Comments (for Detail)
Clinical Trial Identification
2
7
Continuation Pointer
2
4
4
4
4.4.4 OMG - general clinical order message (event O19)
OMG^O19^OMG_O19
General Clinical Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[
PV1
[PV2]
]
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
3
3
2
Patient Visit
Patient Visit- Additional Info
3
3
October 2001
O&O Minutes
Chapter
Page 25
OMG^O19^OMG_O19
General Clinical Order Message
Chapter
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
6
6
6
Guarantor
Allergy Information
6
3
ORC
[{
TQ1
[{TQ2}]
}]
OBR
[{NTE}]
[CTD]
[{DG1}]
[{
OBX
[{NTE}]
}]
{[
[PID
[PD1]]
[PV1
[PV2]]
[AL1]
{
[ORC]
OBR
{[NTE]}
[{
TQ1
[{TQ2}]
}]
[CTD]
{
OBX
[{NTE}]
}
}
}]
[{FT1}]
[{CTI}]
[BLG]
}
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Observation
Notes and Comments (for Detail)
Contact Data
Diagnosis
4
]
{
4
4
4
2
11
6
Observation/Result
Notes and Comments (for Results)
Patient Identification
Additional Demographics
Patient Visit
Patient Visit Add. Info
Allergy Information
previous
previous
previous
previous
previous
result
result
result
result
result
3
3
3
3
3
Common Order
- previous
Order Detail
- previous
Notes and Comments
- previous
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Contact Data
- previous
result
result
result
4
4
2
Observation/Result
Notes and Comments
–
–
–
–
-
7
2
4
4
result
10
- previous result
- previous result
7
2
Financial Transaction
Clinical Trial Identification
Billing Segment
6
7
4
4.4.5 ORG - general clinical order acknowledgement message
(event O20)
ORG^O20^ORG_O20
General Clinical Order Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[OBR]
[{NTE}]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Observation
Notes and Comments (for Detail)
4
October 2001
O&O Minutes
Chapter
4
4
4
2
Page 26
ORG^O20^ORG_O20
[{CTI}]
General Clinical Order Acknowledgment Message
Chapter
Clinical Trial Identification
7
}
]
4.4.6 OML - laboratory order message (event O21)
OML^O21^OML_O21
Laboratory Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
[
SAC
[{OBX}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
OBR
[{
SAC
[{OBX}]
}]
[TCD]
[{NTE}]
[{DG1}]
[{
OBX
[TCD]
[{NTE}]
}]
[{
[PID
[PD1]]
[PV1
[PV2]]
[{AL1}]
{
[ORC]
OBR
{[NTE]}
[{
TQ1
[{TQ2}]
}]
{
OBX
[{NTE}]
}
}
}]
]
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit- Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
6
6
6
Guarantor
Allergy Information
6
3
October 2001
O&O Minutes
Chapter
Specimen Container Details
Additional Specimen Characteristics
13
7
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Observation Request
4
4
4
Specimen Container Details
Additional Specimen Characteristics
13
7
Test Code Details
Notes and Comments (for Detail)
Diagnosis
13
2
6
Observation/Result
Test Code Detail
Notes and Comments (for Results)
7
13
2
Patient Identification
Additional Demographics
Patient Visit
Patient Visit Add. Info
Allergy Information
–
–
–
–
-
previous
previous
previous
previous
previous
result
result
result
result
result
3
3
3
3
3
Common Order
- previous result
Order Detail
- previous result
Notes and Comments
- previous result
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
2
Observation/Result
Notes and Comments
7
2
- previous result
- previous result
4
4
Page 27
OML^O21^OML_O21
Laboratory Order Message
[{FT1}]
[{CTI}]
[BLG]
Chapter
Financial Transaction
Clinical Trial Identification
Billing Segment
6
7
4
}
]
4.4.7 ORL - general laboratory order response message to any
OML (event O22)
ORL^O22^ORL_O22
General Laboratory Order Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
{
[SAC
[{OBX}]
]
[{
ORC
[{
TQ1
[{TQ2}]
}]
[OBR
[{SAC}]
]
}]
}
]
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
3
4.5
Specimen Container Details
Additional Specimen Characteristics
Chapter
13
7
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Observation Request
Specimen Container Details
4
4
4
4
13
General segments
4.5.1 ORC - common order segment
HL7 Attribute Table – ORC – Common Order
SEQ
LEN
DT
OPT
RP/#
7
200
TQ
B
Y
4.5.1.7
TBL#
ITEM#
ELEMENT NAME
00221
Quantity/Timing
ORC-7 Quantity/timing (TQ) 00221
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST) > ^ <start date/time (TS)> ^ <end
date/time (TS)> ^ <priority (ST) (ID)> ^ <condition (ST)> ^ <text (TX)> ^
<conjunction ((ST) (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences (NM)>
Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and
TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.
This field determines the priority, quantity, frequency, and timing of an atomic service. Order segments
should be thought of as describing an atomic service. It is a composite field that is defined in detail in
Section 4.3, “Quantity/Timing (TQ) Definition.”
October 2001
O&O Minutes
Page 28
For example, if an OBR segment describes a unit of blood, this field might request that three (3) such units
be given on successive mornings. In this case ORC-7-quantity/timing would be “1^QAM^X3”. ORC-7quantity/timing is the same as OBR-27-quantity/timing.
To send information about “collection time”, use the ‘text’ component of the TQ data type in either the
ORC-7 or OBR-27.
ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If the ORC-7 and OBR-27 are both valued,
then both should be valued exactly the same. If the quantity/timing is not present in the ORC, it must be
present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and
promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in
an ORU message. In this case, the ORC is not required and the identifying filler order number must be
present in the OBR segments.
4.5.3 OBR - observation request segment
HL7 Attribute Table – OBR – Observation Request
SEQ
LEN
DT
OPT
RP/#
27
200
TQ
B
Y
4.5.3.27
TBL#
ITEM #
ELEMENT NAME
00221
Quantity/Timing
OBR-27 Quantity/timing (TQ) 00221
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end
date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total
occurrences(NM)>
Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and
TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.
This field contains information about how many services to perform at one service time and how often the
service times are repeated, and to fix duration of the request. See Section 4.3, “Quantity/Timing (TQ) Data
Type D.”
4.5.4 TQ1 – Timing/Quantity Segment
The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in
order management and scheduling systems. This segment determines the quantity, frequency, priority, and
timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the
quantity, frequency and priority of a service request over time.
Use cases showing when TQ1 may need to repeat:

Cardiac enzymes STAT and then q 4 hours

Streptokinase studies, draw 1st Stat and run Stat, then draw q 4 hours and run Stat

Gentamicin 100mg Now and 80mg q12h second dose ( First 80mg dose) given exactly 12 hours
after the 100mg dose. (Might be 2 service requests)

Activase 15mg bolus Stat then 50mg over 30 minutes, then 35mg over the next 60 minutes. (Might be
2 service requests)
October 2001
O&O Minutes
Page 29

Imodium 4mg (2 caps) po initially, then 2mg (1cap) after each unformed stool to a maximum of 16 mg
per day. (Might be 2 service requests)

Zithromax 500mg (2tabs) PO on the first day then 250mg (1tab) po qd for 5 days. (Might be 2
service requests)

Zyban (Bupropion) Start 150mg po qam x 3 days, then increase to 150mg po bid for 7 to 12 weeks.

Colchicine 1mg (2 tabs) po now then 1 tablet q1 to 2 hours until pain relief or undesirable side effects
(Diarrhea, GI upset) (Might be 2 service requests)

doxycylcine 100mg po bid on the first day then 100mg po qd.

scopolamine, xxx mg, 1 hour before surgery. Relative time = -1^hour, priority = P (preop). or
alternately repeat pattern = P1H^Preop, 1 Hour before Surgery^99LocalCode, Relative time would be
empty and priority would be P (preop).
HL7 Attribute Table - TQ1
SEQ
LEN
DT
OPT
RP/#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
4
20
540
20
20
20
26
26
250
250
250
10
20
10
SI
CQ
RPT
TM
CQ
CQ
TS
TS
CWE
TX
TX
ID
CQ
NM
O
O
O
O
O
O
O
O
O
O
O
C
O
O
N
N
Y
Y
Y
N
N
N
Y
N
N
N
N
N
TBL#
ITEM#
ELEMENT NAME
Set ID - TQ1
Quantity
Repeat Pattern
Explicit Time
Relative Time and units
Service Duration
Start date/time
End date/time
Priority
Condition text
Text instruction
Conjunction
Occurrence duration
Total occurrence's
4.5.4.0 TQ1 field definitions
4.5.4.1 Set ID - TQ1
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second
timing specification, it shall be 2; and so on.
4.5.4.2 Quantity (CQ)
Definition: This field specifies the numeric quantity of the service that should be provided at each service
interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if
three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this
field is 1.
If multiple identical services are to be requested, it is strongly recommended that multiple service requests
be placed; giving each service request it’s own unique placer/filler number.
4.5.4.3
Repeat pattern (RPT) (See RPT data type proposal)
Definition: The repeating frequency with which the treatment is to be administered. It is similar to the
frequency and SIG code tables used in order entry systems.
This field may be repeated to build up more complex repeat patterns. When the quantity timing
specification must change to a different repeat pattern after some period of time, a new TQ1 segment must
October 2001
Page 30
O&O Minutes
be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the
current timing specification ends, and the start date of the next TQ1 shows when the new timing
specification begins. The Conjunction field, TQ1-12 determines if the next TQ1 segment is to be
performed sequentially or in parallel.
Note: The following table defines possible ranges of coded values for this field. The table is not intended to imply that
these codes are to be parsed to derive the meaning of the code.
User-defined Table 0335 - Repeat pattern
Value
Description
Q<integer>S
every <integer> seconds
Q<integer>M
every <integer> minutes
Q<integer>H
every <integer> hours
Q<integer>D
every <integer> days
Q<integer>W
every <integer> weeks
Q<integer>L
every <integer> months (Lunar cycle)
Q<integer>J<day#>
repeats on a particular day of the week, from the
French jour (day). If <integer> is missing, the
repeat rate is assumed to be 1. Day numbers are
counted from 1=Monday to 7=Sunday. So Q2J2
means every second Tuesday; Q1J6 means every
Saturday.
BID
twice a day at institution-specified times (e.g.,
9AM-4PM)
TID
three times a day at institution-specified times
(e.g., 9AM-4PM-9PM)
QID
four times a day at institution-specified times (e.g.,
9AM-11AM-4PM-9PM)
XID
“X” times per day at institution-specified times,
where X is a numeral 5 or greater. E.g., 5ID=five
times per day; 8ID=8 times per day
QAM
in the morning at institution-specified time
QSHIFT
during each of three eight-hour shifts at institutionspecified times
QOD
every other day (same as Q2D)
QHS
every day before the hour of sleep
QPM
in the evening at institution-specified time
C
service is provided continuously between start
time and stop time
U <spec>
for future use, where <spec> is an interval
specification as defined by the UNIX cron
specification.
PRN
given as needed
PRNxxx
where xxx is some frequency code (e.g.,
PRNQ6H); given as needed over the frequency
period.
October 2001
O&O Minutes
Comment
Note:
None of the above three
specifications are equivalent to their
Q<integer>H counterpart. QID is not Q6H.
The former is unequally spaced; the latter
is equally spaced.
Page 31
Once
one time only. This is also the default when this
field is null.
Meal Related Timings
<timing>C (“cum”)<meal>
A
Ante (before)
P
Post (after)
I
Inter (e.g., between this meal and the next,
between dinner and sleep
M
Cibus Matutinus (breakfast)
D
Cibus Diurnus (lunch)
V
Cibus Vespertinus (dinner)
AC
before meal (from lat. ante cibus)
PC
after meal (from lat. post cibus)
IC
between meals (from lat. inter cibus)
ACM
before breakfast (from lat. ante cibus matutinus)
ACD
before lunch (from lat. ante cibus diurnus)
ACV
before dinner (from lat. ante cibus vespertinus)
PCM
after breakfast (from lat. post cibus matutinus)
PCD
after lunch (from lat. post cibus diurnus)
PCV
after dinner (from lat. post cibus vespertinus)
ICM
between breakfast and lunch
ICD
between lunch and dinner
ICV
between dinner and the hour of sleep
4.5.4.4
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Deprecated in v 2.5; retained for
backward compatibility only.
Explicit time (TM)
Definition: This field explicitly lists the actual times referenced by the code in TQ1-3. This field will be
used to clarify the TQ1-3 in cases where the actual administration times vary within an institution. If the
time of the service request spans more than a single day, this field is only practical if the same times of
administration occur for each day of the service request. If the actual start time of the service request (as
given by TQ1-7 ) is after the first explicit time, the first administration is taken to be the first explicit time
after the start time. In the case where the patient moves to a location having a different set of explicit times,
the existing service request may be updated with a new quantity/timing segment showing the changed
explicit times.
Usage Note: This field is not valued if a Repeat Pattern is not present.
4.5.4.5 Relative time and units (CQ)
Components:
<quantity (NM)> ^ <units (CE)>
Note: In future versions, CQ fields should be avoided because the same data can usually be sent as two separate
fields, one with the value and one with the units as a CE data type.
Definition: This field is used to define the interval between schedules for service request or bottle records.
If this field contains a value, it overrides any value in the explicit time interval field. The units component
of the CQ data type is constrained to units of time.
Examples:
Q6H||60^M
Q6H||6^H
QD||1^D
October 2001
O&O Minutes
Page 32
4.5.4.6 Service Duration (CQ)
Definition: This field contains the duration for which the service is requested.
The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is
constrained to units of time.
4.5.4.7 Start date/time (TS)
Definition: This field may be specified by the requester, in which case it indicates the earliest date/time at
which the services should be started. In many cases, however, the start date/time will be implied or will be
defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be
empty.
The filling service will often record a value in this field after receipt of the service request, however, and
compute an end time on the basis of the start date/time for the filling service’s internal use.
4.5.4.8 End date/time (TS)
Definition: When filled in by the requester of the service, this field should contain the latest date/time that
the service should be performed. If it has not been performed by the specified time, it should not be
performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the
basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times
specified by either the duration or the end date/time.
4.5.4.9
Priority (CWE)
Definition: This field describes the urgency of the request. If this field is blank, the default is R. The
following values are suggested. The following User defined table may be used for this field.
User Defined Table xxx - Priority
Value
Short
Text
Description
S
Stat
With highest priority
A
ASAP
Fill after S orders
R
Routine
Default
P
Preop
C
Callback
T
Timing
critical
A request implying that it is critical to come as close as possible to
the requested time, e.g., for a trough anti-microbial level.
TS<integer>
Timing critical within <integer> seconds.
TM<integer>
Timing critical within <integer> minutes.
TH<integer>
Timing critical within <integer> hours.
TD<integer>
Timing critical within <integer> days.
TW<integer>
Timing critical within <integer> weeks.
TL<integer>
PRN
4.5.4.10
Timing critical within <integer> months.
As needed
Condition text (ST)
Definition: This is a free text field that describes the conditions under which the drug is to be given. For
example, PRN pain, or to keep blood pressure below 110.
October 2001
O&O Minutes
Page 33
The presence of text in this field should be taken to mean that human review is needed to determine the how
and/or when this drug should be given.
For complex codified conditions see the TQ2 segment below.
4.5.4.11 Text Instruction (ST)
Definition: This field is a full text version of the instruction (optional).
4.5.4.12
Conjunction (ID):
Definition: This field indicates that a second TQ1 segment is to follow. This field can take values from
HL7 table 0472.
HL7 table 0472 - TQ Conjunction ID
Value
Description
S
Synchronous - Do the next specification after this one
(unless otherwise constrained by the following fields:
TQ1-7-start date/time and TQ1-8-end date/time). An “S”
specification implies that the second timing sequence
follows the first, e.g., when an service request is written
to measure blood pressure Q15 minutes for the 1st hour,
then every 2 hours for the next day.
A
Asynchronous - Do the next specification in parallel with
this one (unless otherwise constrained by the following
fields: TQ1-7-start date/time and TQ1-8-end date/time).
The conjunction of “A” specifies two parallel
instructions, as are sometimes used in medication, e.g.,
prednisone given at 1 tab on Monday, Wednesday,
Friday, and at 1/2 tab on Tuesday, Thursday, Saturday,
Sunday.
C
Actuation Time - It will be followed by a completion
time for the service. This code allows one to distinguish
between the time and priority at which a service should
be actuated (e.g., blood should be drawn) and the time
and priority at which a service should be completed (e.g.,
results should be reported).
For continuous or periodic services, the point at which the service is actually stopped is determined by the
field TQ1-8 end date/time and TQ1-6 duration, whichever indicates an earlier stopping time. Ordinarily,
only one of these fields would be present.
Condition Rule: If the TQ1 segment is repeated in the message, this field must be populated with the
appropriate Conjunction code indicating the sequencing of the following TQ1 segment.
4.5.4.13
Occurrence duration (CQ)
Definition: This field contains the duration for which a single performance of a service is requested. The
quantity component of this field must be a non-negative integer when populated. The units component is
constrained to be units of time.
Example: Whirlpool twenty minutes three times per day for three days. Twenty minutes is the occurrence
duration.
October 2001
O&O Minutes
Page 34
4.5.4.14
Total occurrences (NM)
Definition: This field contains the total number of occurrences of a service that should result from this
service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the
occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise
the number of occurrences takes precedence.
4.5.5 TQ2 – Timing/Quantity Relationship
The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are
associated with, and other service requests. The TQ2 segment will link the current service request with one
or more other service requests.
There are many situations, such as the creation of an service request for a group of intravenous (IV)
solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be
specified, e.g., hyperalimentation with multi-vitamins in every third bottle.
There are other situations where part of the service request’s instructions contains a results condition of
some type, such as “PRN pain.” There is currently a free text “condition” field of TQ1-10 (Condition text)
which allows any condition to be specified. However, to support a fully encoded version of service request
sequencing, or results condition, the TQ2, Timing/Quantity Relationship segment has been defined.
HL7 Attribute Table - TQ2
SEQ
LEN
DT
OPT
RP/#
1
2
3
4
5
6
7
8
9
10
4
1
22
22
22
2
1
20
10
1
SI
ID
EI
EI
EI
ID
ID
CQ
NM
ID
O
O
C
C
C
C
C
O
O
C
N
N
Y
Y
Y
N
N
N
N
N
TBL#
???
???
???
ITEM#
ELEMENT NAME
Set ID - TQ2
Sequence/Results Flag
Related Placer number
Related Filler number
Related Placer group number
Sequence condition code
Cyclic Entry/Exit Indicator
Sequence condition time interval
Cyclic group maximum number of repeats
Special service request relationship
TQ2 Usage notes
a)
Cyclic placer service request groups
To implement a cyclic group of four IV service requests using the parent/child paradigm, the
parent specifies a custom group of IVs, and the following occurs:

TQ2 of the second child service request specifies that it follow the first child service request.

TQ2 of the third child service request specifies that it follow the second child service request.

TQ2 of the fourth child service request specifies that it follow the third service request.
To repeat the group of four child service requests in a cyclic manner, the following occurs:

October 2001
O&O Minutes
TQ2 of the first child service request specifies that it is to be executed once without any
dependence on the completion of other service requests. Its second execution follows the
completion of the fourth service request. See example in Section 4.15.2, “RXO segment field
examples.
Page 35
This scheme allows the following to be tracked:

The status of the whole group of service requests to be reported back at the level of the parent
service request.

The status for each individual IV service request by following the status of the corresponding
child service request.
Separate Service requests example:

b)
The same group of service requests can be sent as a group of four service requests (without a
common parent), linked only by the data in their quantity/timing fields. In this case, there is no
convenient HL7 method of transmitting the service request status of the group as a whole
without transmitting the status of each of the four separate service requests.
Inheritance of service request status
Cancellation/discontinuation/hold service request control events:

This logic implies the normal execution of the referenced predecessor service request.
Thus a cancel (or discontinuation or hold) of a predecessor service request implies the
cancellation (or discontinuation or hold) of all subsequent service requests in the chain.

If the referenced service request has been canceled (or discontinued or held), the current
service request inherits that same status.

In the case of hold, the removal of the hold of the predecessor implies a removal of the
hold for the given service request (which can then be executed according to the specification
in the TQ2 segment).
4.5.5.0 TQ2 field definitions
4.5.5.1 Set ID – TQ2 (SI)
Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second
timing specification, it shall be 2; and so on.
4.5.5.2
Sequence/Results Flag (ID)
Definition: This flag defines the sequencing relationship between the current service request, and the
related service request(s) specified in this TQ2 segment. See HL7 table ??? for values. If not value is
present, the S - Sequential is the default value.
HL7 defined table ???
Value
October 2001
O&O Minutes
Description
S
Sequential
C
Cyclical - The C will be used for indicating a repeating cycle of
service requests; for example, individual intravenous solutions
used in a cyclical sequence (a.k.a. “Alternating IVs”). This value
would be compatible with linking separate service requests or
with having all cyclical service request components in a single
service request. Likewise, the value would be compatible with
either Parent-Child messages or a single service request
message to communicate the service requests’ sequencing.
R
Reserved for future use
Page 36
4.5.5.3
Related Placer number (EI)
Definition: The placer numbers of the service request(s) to which this TQ2 segment links the current
service request. This field should be populated with the appropriate "Placer number " from the current
service request. For orders, the Placer Order Number from ORC-2 is the appropriate "Placer number".
Repeats of this field indicates the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
4.5.5.4 Related Filler number (EI)
Definition: The filler numbers of the service request(s) to which this TQ2 segment links the current service
request. This field should be populated with the appropriate "Filler number " from the current service
request. For orders, the Filler Order Number from ORC-3 is the appropriate "Filler number". Repeats of this
field indicates the current service request is related to multiple service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
4.5.5.5 Related Placer group number (EI)
Definition: The placer group numbers of the service request(s) to which this TQ2 segment links the current
service request. . This field should be populated with the appropriate "Placer group number " from the
current service request. For orders, the Placer Group Number from ORC-4 is the appropriate "Placer group
number". Repeats of this field indicates that the current service request is related to multiple groups of
service requests.
Conditional Rule: At least one of TQ2-3, TQ2-4, TQ2-5 must contain a value.
4.5.5.6 Sequence Condition Code (ID)
Definition: Defines the relationship between the start/end of the related service request(s) (from TQ2-3,
TQ2-4, or TQ2-5) and the current service request from ORC-2,3 or 4. See HL7 defined table ??? for
allowed values.
Conditional Rule: Either this field or TQ2-??? must be present.
HL7 defined table ????
Value
Description
EE
End related service request(s), end current service request.
ES
End related service request(s), start current service request.
SS
Start related service request(s), start current service request.
SE
Start related service request(s), end current service request.
4.5.5.7 Cyclic Entry/Exit Indicator (ID)
Definition: Indicates if this service request is the first, last, service request in a cyclic series of service
requests. If null or not present, this field indicates that the current service request is neither the first or last
service request in a cyclic series of service requests.
Usage note: Should not be populated when TQ2-2 (Sequence/Results Flag) is not equal to a 'C' (cyclic
service request).
HL7 defined table ????
Value
Description
*
The first service request in a cyclic group
#
The last service request in a cyclic group.
October 2001
O&O Minutes
Page 37
Example of TQ2 - 6, 7, & 8 Usage:
...|ES|*|+10^min|...
translates to: execute this service request the first time without evaluating
the condition specified in the TQ2 segment; but repeat only its execution
when the specified external service request’s start or finish date/time has
met this condition. This specification generates a repetition of the service
request for each iteration of the cycle.
Note: This requires that the requesting application be able to specify the placer/filler/placer group number of the last
service request in the cycle in the first service request’s quantity/timing specification.
4.5.5.8 Sequence condition time interval (CQ)
Definition: Defines the interval of time between the start/end of the related service request(s) and the
start/end of the current service request. The unit's component is constrained to units of time. If this field is
not populated, then there should be no interruption between start/ending the current service request, and the
related service request(s).
4.5.5.9 Cyclic group maximum number of repeats (NM)
Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats
is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.
4.5.5.10 Special service request relationship (ID)
Definition: This defines an additional or alternate relationship between this service request and other
service requests. It's primary intended use for Pharmacy administration service requests, but it may be
useful for other domains. See HL7 Table ?? for allowed values.
Conditional Rule: Either this field or TQ2-6 must be present.
HL7 defined table ???
Value
October 2001
O&O Minutes
Description
N
Nurse prerogative - RN Prerogative order. I've seen it ordered so that the
nurse can chose between 3 or 4 different items, depending on which the patient
can tolerate at the moment. Another example would be:Milk of Magnesia PO
30 ml qhs (at bedtime)/Dulcolax Supp R @ hs prn /Colace 100 mg capsule PO
bid
The nurse may be giving the Colace twice daily as a stool softener, but may
also give the Dulcolax Supp along with it if Colace is not producing any
"results". For example give order 1 and order 2 or order 3. This can be
extended to more than three orders. The old TQ did not handle this many to
many scenario.
C
Compound - A compound is an extempo order which may be made up of
multiple drugs. For example, many hospitals have a standard item called
"Magic Mouthwash". The item is ordered that way by the physician. The
extempo items will contain multiple products, such as Maalox, Benadryl,
Xylocaine, etc. They will all be mixed together and will be dispensed in a single
container.
T
Tapering - A tapering order is one in which the same drug is used, but it has a
declining dosage over a number of days.
For example, Decadron 0.5 mg is often ordered this way. The order would look
like this:
Decadron 0.5 mg qid (four times a day) for 2 days, then
Decadron 0.5 mg tid (three times a day) for 2 days, then
Decadron 0.5 mg bid (twice a day) for 2 days, then
Decadron 0.5 mg qd (daily) for 2 days, then stop.
E
Exclusive - An exclusive order is an order where only one of the multiple items
Page 38
should be administered at any one dosage time. The nurse may chose
between the alternatives, but should only give ONE of them. An example would
be: Phenergan 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally
every 6 hours as needed).
S
Simultaneous - A simultaneous order is 2 or more drugs which are ordered to
be given at the same time. A common example of this would be Demerol and
Phenergan (Phenergan is given with the Demerol to control the nausea that
Demerol can cause). The order could be:Demerol 50 mg IM with Phenergan 25
mg IM q4h prn (every 4 hours as needed).
4.7.1 OMD - dietary order (event O03)
OMD^O03^OMD_O03
Dietary Order
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[
PV1
[PV2]
]
[{
IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
{ODS}
[{NTE}]
[{
OBX
[{NTE}]
}]
]
}
{
[
ORC
[{
TQ1
[{TQ2}]
}]
{ODT}
[{NTE}]
]
}
Message Header
Notes and Comments (for Header)
Chapter
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
3
3
2
Patient Visit
Patient Visit - Additional Info
3
3
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
6
6
6
Guarantor
Allergy Information
6
3
Common Order Segment
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Dietary Orders, Suppl., Prefer.
Notes and Comments (for ODS)
4
2
Results
Notes and Comments (for OBX)
7
2
Common Order Segment
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Diet Tray Instructions
Notes and Comments (for ODT)
4
4
4
4
4
4
2
4.7.2 ORD - dietary order acknowledgment (event O04)
ORD^O04^ORD_O04
Dietary Order Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
Message Header
Message Acknowledgment
Error
Notes and Comments (for MSA)
October 2001
O&O Minutes
Chapter
2
2
2
2
Page 39
[
PID
[{NTE}]
Patient Identification
Notes and Comments (for Patient ID)
3
2
ORC
[{
TQ1
[{TQ2}]
}]
[{ODS}]
[{NTE}]
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Dietary Orders, Supplements, and Preferences
Notes and Comments (for ODS)
4
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Diet Tray Instructions
Notes and Comments (for ODT)
4
]
{
4
4
4
2
}
[{
ORC
[{
TQ1
[{TQ2}]
}]
[{ODT}]
[{NTE}]
4
4
4
2
]}
]
4.10.1 OMS - stock requisition order message (event O05)
OMS^O05^OMS_O05
Stock Requisition Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
RQD
[RQ1]
[{NTE}]
[
{
OBX
[{NTE}]
}
]
[BLG]
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
6
6
6
Guarantor
Allergy Information
6
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Requisition Detail
Requisition Detail-1
Notes and Comments (for RQD)
4
Observation/Result
Notes and Comments (for OBX)
7
2
Billing Segment
4
4.10.2
4
4
4
4
2
ORS - stock requisition order acknowledgment message
(event O06)
ORS^O06^ORS_O06
Stock Order Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
October 2001
O&O Minutes
Chapter
Chapter
2
2
2
2
Page 40
[PID
[{NTE}]
]
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Requisition Detail
Requisition Detail-1
Notes and Comments (for RQD)
4
{
ORC
[{
TQ1
[{TQ2}]
}]
RQD
[RQ1]
[{NTE}]
4
4
4
4
2
}
]
4.10.3
OMN - non-stock requisition order message (event O07)
OMN^O07^OMN_O07
Nonstock Requisition Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
RQD
[RQ1]
[{NTE}]
[
{
OBX
[{NTE}]
}
]
[BLG]
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
6
6
6
Guarantor
Allergy Information
6
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Requisition Detail
Requisition Detail-1
Notes and Comments (for RQD)
4
Observation/Result
Notes and Comments (for OBX)
7
2
Billing Segment
4
4.10.4
Chapter
4
4
4
4
2
ORN - non-stock requisition order acknowledgment
message (event O08)
ORN^O08^ORN_O08
General Order Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
October 2001
O&O Minutes
Chapter
4
4
Page 41
RQD
[RQ1]
[{NTE}]
Requisition Detail
Requisition Detail-1
Notes and Comments (for RQD)
4
4
2
}
]
4.13.3 OMP - pharmacy/treatment order message (event O09)
OMP^O09^OMP_O09
Pharmacy/treatment Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
RXO
[{NTE}]
{RXR}
[
{RXC}
[{NTE}]
]
[
{
OBX
[{NTE}]
}
]
[{FT1}]
[BLG]
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
6
6
6
Guarantor
Allergy Information
6
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Order
Notes and Comments (for RXO)
Pharmacy/Treatment Route
4
Pharmacy/Treatment Component
Notes and Comments (for RXC)
4
2
Observation/Result
Notes and Comments (for OBX)
7
2
Financial Transaction
Billing Segment
6
6
4.13.4
Chapter
4
4
4
2
4
ORP - pharmacy/treatment order acknowledgment (event
O10)
ORP^O10^ORP_O10
Description
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXO
[{NTE}]
{RXR}
Message Header
Message Acknowledgment
Error
Notes and Comments (for Response Header)
2
2
2
2
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Order
Notes and Comments (for RXO)
Pharmacy/Treatment Route
4
2
4
October 2001
O&O Minutes
Chapter
4
4
Page 42
[{RXC}]
[{NTE}]
Pharmacy/Treatment Component
Notes and Comments (for RXC)
4
2
]
}
]
4.13.5
RDE - pharmacy/treatment encoded order message (event
O11)
RDE^O11^RDE_O11
Pharmacy/Treatment Encoded Order Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXO
[{NTE}]
{RXR}
[
{RXC}
[{NTE}]
]
]
RXE
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
[{
OBX
[{NTE}]
}]
{[CTI]}
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
Guarantor
Allergy Information
6
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Prescription Order
Notes and Comments (for RXO)
Pharmacy/Treatment Route
4
2
4
Pharmacy/Treatment Component (for RXO)
Notes and Comments (for RXC)
4
2
Pharmacy/Treatment Encoded Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component (for RXE)
4
Results
Notes and Comments (for OBX)
7
2
4.13.6
Clinical Trial Identification
Chapter
6
6
4
4
4
4
4
4
7
RRE - pharmacy/treatment encoded order
acknowledgment (event O12)
RRE^O12^RRE_O12
Pharmacy/Treatment Encoded Order Acknowledgment
Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]
]
{
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for PID)
3
2
October 2001
O&O Minutes
Chapter
Page 43
ORC
[{
TQ1
[{TQ2}]
}]
[
RXE
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
]
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Encoded Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
4
4
4
4
4
4
}
]
4.13.7
RDS - pharmacy/treatment dispense message (event O13)
RDS^O13^RDS_O13
Pharmacy/Treatment Dispense Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[{AL1}]
[
PV1
[PV2]
]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXO
[
{NTE}
{RXR}
[
{RXC}
[{NTE}]
]
]
]
[
RXE
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
]
RXD
{RXR}
[{RXC}]
[{
OBX
[{NTE}]
}]
[{FT1}]
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for PID)
Allergy Information
3
3
2
2
Patient Visit
Patient Visit - Additional Info
3
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy /Treatment Order
4
Notes and Comments (for RXO)
Pharmacy/Treatment Route
2
4
Pharmacy/Treatment Component
Notes and Comments (for RXC)
4
2
Pharmacy/Treatment Encoded Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
Pharmacy/Treatment Dispense
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
4
4
Results
Notes and Comments (for OBX)
7
2
Financial Transaction segment
6
October 2001
O&O Minutes
Chapter
4
4
4
4
4
4
Page 44
4.13.8
RRD - pharmacy/treatment dispense acknowledgement
message (event O14)
RRD^O14^RRD_O14
Pharmacy/Treatment Dispense Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXD
{RXR}
[{RXC}]
]
}
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for Patient ID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Dispense
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
4
4
4.13.9
Chapter
4
4
RGV - pharmacy/treatment give message (event O15)
RGV^O15^RGV_O15
Pharmacy/Treatment Give
MSH
[{NTE}]
[
PID
[{NTE}]
[{AL1}]
[PV1
[PV2]]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXO
[
{NTE}
{RXR}
[
{RXC}
[{NTE}]
]
]
]
[
RXE
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
]
{
RXG
{
TQ1
[{TQ2}]
}
{RXR}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Notes and Comments (for PID)
Allergy Information
Patient Visit
Patient Visit - Additional Info
3
2
2
3
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy /Treatment Order
4
Notes and Comments (for RXO)
Pharmacy/Treatment Route
2
4
Pharmacy/Treatment Component
Notes and Comments (for RXC)
4
2
Pharmacy/Treatment Encoded Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
Pharmacy/Treatment Give
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
4
October 2001
O&O Minutes
Chapter
4
4
4
4
4
4
4
4
4
Page 45
[{RXC}]
{
[OBX]
[{NTE}]
}
Pharmacy/Treatment Component
4
Observation/Results
Notes and Comments (for OBX)
7
2
}
}
4.13.10
RRG - pharmacy/treatment give acknowledgment
message (event O16)
RRG^O16^RRG_O16
Pharmacy/Treatment Give Acknowledgment Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXG
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
]
}
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for PID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Give
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
4.13.11
Chapter
4
4
4
4
4
4
RAS - pharmacy/treatment administration message
(event O17)
RAS^O17^RAS_O17
Pharmacy/Treatment Administration
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[{AL1}]
[PV1
[PV2]]
]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
RXO
[
{NTE}
{RXR}
[
{RXC}
[{NTE}]
]
]
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for PID)
Allergy Information
Patient Visit
Patient Visit - Additional Info
3
3
2
2
3
3
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy /Treatment Order
4
Notes and Comments (for RXO)
Pharmacy/Treatment Route
2
4
Pharmacy/Treatment Component
Notes and Comments (for RXC)
4
2
October 2001
O&O Minutes
Chapter
4
4
Page 46
]
[
RXE
{
TQ1
[{TQ2}]
}
{RXR}
[{RXC}]
]
{{RXA}
RXR
{[OBX
{[NTE]}
]}}
{[CTI]}
Pharmacy/Treatment Encoded Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Pharmacy/Treatment Route
Pharmacy/Treatment Component
4
Pharmacy/Treatment Administration
Pharmacy/Treatment Route
Observation/Result
Notes and Comments (for OBX)
4
4
7
2
Clinical Trial Identification
7
4
4
4
4
}
4.13.12
RRA - pharmacy/treatment administration
acknowledgment message (event O18)
RRA^O18^RRA_O18
Pharmacy/Treatment Administration Acknowledgment
Message
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{NTE}]]
{
ORC
[{
TQ1
[{TQ2}]
}]
[
{RXA}
RXR
]
}
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
2
2
2
2
Patient Identification
Notes and Comments (for PID)
3
2
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy/Treatment Administration
Pharmacy/Treatment Route
4
4
4.14.4
Chapter
4
4
RXE - pharmacy/treatment encoded order segment
HL7 Attribute Table – RXE – Pharmacy/Treatment Encoded Order
SEQ
LEN
DT
OPT
1
200
TQ
B
4.14.4.1
RP/#
TBL#
ITEM #
00221
ELEMENT NAME
Quantity/Timing
RXE-1 Quantity/timing (TQ) 00221
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end
date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total
occurrences(NM)>
Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and
TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.
See Section 4.14.4, “RXE - pharmacy/treatment encoded order segment,” for necessary modification for
this field’s definition to cover interorder dependencies needed by pharmacy/treatment orders. This field is
used by the pharmacy or non-pharmacy treatment supplier to express the fully-coded version of the drug or
October 2001
O&O Minutes
Page 47
treatment timing. It may differ from ORC-7-quantity/timing, which contains the requested quantity/timing
of the original order.
4.14.6
RXG - pharmacy/treatment give segment
HL7 Attribute Table – RXG – Pharmacy/Treatment Give
SEQ
LEN
DT
OPT
3
200
TQ
B
4.14.6.3
RP/#
TBL#
ITEM #
ELEMENT NAME
00221
Quantity/Timing
RXG-3 Quantity/timing (TQ) 00221
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end
date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total
occurrences(NM)>
Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and
TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.
This field contains the quantity/timing specification that refers to either a single scheduled give instruction
only or to multiple give instructions. In the former case, RXG-1-give sub-ID counter is a positive integer
greater than or equal to one (1). In the latter case, RXG-1-give sub-ID counter is zero (0). The quantity
will always be 1. This quantity/timing field may differ from the ORC quantity/timing field, which contains
the requested quantity/timing of the original order.
Note:
The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).
4.17.5
VXR - vaccination record response (event V03)
VXR^V03
Vaccination Response
MSH
MSA
QRD
[QRF]
PID
[PD1]
[{NK1}]
[PV1
[PV2]]
[{GT1}]
[{IN1
[IN2]
[IN3]
}]
[{
[
ORC
[{
TQ1
[{TQ2}]
}]
]
RXA
[RXR]
[{OBX
[{NTE}]
}]
}]
Message Header
Message Acknowledgment
Query Definition
Query Filter
Patient Identification
Additional Demographics
Next of Kin/Associated Parties
Patient Visit
Patient Visit - Additional Info
Guarantor
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
2
2
2
2
3
3
3
3
3
6
6
6
6
Common Order
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy Administration
Pharmacy Route
Observation/Result
Notes (Regarding Immunization)
4
4
7
2
October 2001
O&O Minutes
Chapter
4
4
Page 48
4.17.6
VXU - unsolicited vaccination record update (event V04)
VXU^V04
Unsolicited Vaccination Update
MSH
PID
[PD1]
[{NK1}]
[PV1
[PV2]]
[{GT1}]
[{IN1
[IN2]
[IN3]
}]
[{
[
ORC
[{
TQ1
[{TQ2}]
}]
]
RXA
[RXR]
{[ OBX
[{NTE}]
]}
}]
Message Header Segment
Patient Identification Segment
Additional Demographics
Next of Kin/Associated Parties
Patient Visit
Patient Visit - Additional Info
Guarantor
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
Chapter
2
3
3
3
3
3
6
6
6
6
Common Order Segment
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
Pharmacy Administration Segment
Pharmacy Route
Observation/Result
Notes (Regarding Immunization)
4
4
7
2
4
4
7
7.3.1 ORU - unsolicited observation message (event R01)
ORU^R01
Unsolicited Observation Message
MSH
{
[
Message Header
Chapter
2
PID
[PD1]
[{NK1}]
[{NTE}]
[
PV1
[PV2]
]
Patient Identification
Additional Demographics
Next of Kin/Associated Parties
Notes and Comments
3
3
3
2
Patient Visit
Patient Visit - Additional Info
3
3
[ORC]
OBR
{[NTE]}
[{
TQ1
[{TQ2}]
}]
[CTD]
{
[OBX]
{[NTE]}
}
[{FT1}]
{[CTI]}
Order common
Observations Report ID
Notes and comments
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Contact Data
4
7
2
11
Observation/Result
Notes and comments
7
2
Financial Transaction
Clinical Trial Identification
6
7
Continuation Pointer
2
]
{
}
}
[DSC]
October 2001
O&O Minutes
4
4
Page 49
7.3.2 OUL - unsolicited laboratory observation message (R21)
OUL^R21^OUL_R21
Unsolicited Laboratory Observation Message
MSH
[NTE]
[
PID
[PD1]
[{NTE}]
]
[
PV1
[PV2]]
]
{
[
SAC
[SID]
[{OBX}]
]
[ORC]
OBR
[{NTE}]
[{
TQ1
[{TQ2}]
}]
{
[OBX]
[TCD]
{[SID]}
[{NTE}]
}
[{CTI}]
}
[DSC]
Message Header
Notes and Comments
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
3
3
2
Patient Visit
Patient Visit – Additional Information
3
3
Specimen Container Details
Substance Identifier
Additional Specimen Characteristics
13
13
7
Common Order
Observation
Notes and Comments (for Detail)
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
7
2
Observation Result
Test Code Detail
Substance Identifier
Notes and Comments
7
13
13
2
Clinical Trial Identification
7
Continuation Pointer
2
7.4
Chapter
4
4
Segments
7.4.1 OBR - observation request segment
HL7 Attribute Table – OBR – Observation Request
SEQ
LEN
DT
OPT
RP/#
27
200
TQ
B
Y
7.4.1.27
TBL#
ITEM #
ELEMENT NAME
00221
Quantity/Timing
OBR-27 Quantity/timing (TQ) 00221
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end
date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total
occurrences(NM)>
Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and
TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.
This field contains information about how many services to perform at one service time and how often the
service times are repeated, and to fix duration of the request. See Section 4.3, “Quantity/Timing (TQ) Data
Type D.”
October 2001
O&O Minutes
Page 50
7.7.2 CSU - unsolicited study data message (events C09-C12)
CSU^C09-C12^CSU_C09
Unsolicited Study Data Message
MSH
MSA
QRD
[QRF]
{
[
PID
[{NTE}]
]
{
[ORC]
OBR
{[NTE]}
[{
TQ1
[{TQ2}]
}]
[CTD]
{
[OBX]
{[NTE]}
}
{[CTI]}
}
}
[ERR]
[QAK]
[DSC]
Message Header
Message Acknowledgment
Query Definition
Query Filter
2
2
2
2
Patient ID
Notes and Comments
3
3
Order common
Observation request
Notes and comments
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
Contact Data
2
7
2
11
Observation/Result
Notes and comments
7
2
Clinical Trial Identification
7
Error
Query Acknowledgement
Continuation Pointer
2
5
2
11.3.5
Chapter
4
4
RQC/RCI - request for patient clinical information (event
I05)
RCI^I05^RCI_I05
MSH
MSA
QRD
[QRF]
{
PRD
[{CTD}]
}
PID
[{DG1}]
[{DRG}]
[{AL1}]
[
{
OBR
[{NTE}]
Return Clinical Information
Message Header
Message Acknowledgment
Query Definition
Query Filter
[{
TQ1
[{TQ2}]
}]
[
{
OBX
[{NTE}]
}
]
October 2001
O&O Minutes
Chapter
2
3
5
5
Provider Data
Contact Data
11
11
Patient Identification
Diagnosis
Diagnosis Related Group
Allergy Information
3
6
6
3
Observation Request
Notes and Comments
4
2
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
Observation/Result
Notes and Comments
7
2
Page 51
}
]
[{NTE}]
11.4.1
RQA^I08I11^RQA_I08
MSH
[RF1]
[
AUT
[CTD]
]
{
PRD
[{CTD}]
}
PID
[{NK1}]
[[{GT1}]
{
IN1
[IN2]
[IN3]
}
]
[ ACC ]
[{DG1}]
[{DRG}]
[{AL1}]
[
{
PR1
[
AUT
[CTD]
}
]
[
{
OBR
[{NTE}]
[{
TQ1
[{TQ2}]
}]
[
{
OBX
[{NTE}]
}
]
}
]
[
PV1
[PV2]
]
[{NTE}]
Notes and Comments
RQA/RPA - request patient authorization message
Request Patient Authorization
Chapter
Message Header
Referral Information
2
11
Authorization Information
Contact Data
11
11
Provider Data
Contact Data
11
11
Patient Identification
Next of Kin/Associated Parties
Guarantor
3
6
6
Insurance
Insurance Additional Info
Insurance Add'l Info - Cert
6
6
6
Accident Information
Diagnosis
Diagnosis Related Group
Allergy Information
6
6
6
3
Procedure
6
Authorization Information
Contact Data
]
11
11
Observation Request
Notes and Comments
4
2
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
Observation/Result
Notes and Comments
7
2
Patient Visit
Patient Visit Additional Info
3
3
Notes and Comments
2
RPA^I08-
Return Patient Authorization
I11^RPA_I08
MSH
Message Header
October 2001
O&O Minutes
2
Chapter
2
Page 52
MSA
[RF1]
[
AUT
[CTD]
]
{
PRD
[{CTD}]
}
PID
[{NK1}]
[{GT1}]
[
{
IN1
[IN2]
[IN3]
}
]
[ ACC ]
[{DG1}]
[{DRG}]
[{AL1}]
{
PR1
[
AUT
[CTD]
]
}
[
{
OBR
[{NTE}]
Message Acknowledgment
Referral Information
3
11
Authorization Information
Contact Data
11
11
Provider Data
Contact Data
11
11
Patient Identification
Next of Kin/Associated Parties
Guarantor
3
6
6
Insurance
Insurance Additional Info
Insurance Add'l Info - Cert
6
6
6
Accident Information
Diagnosis
Diagnosis Related Group
Allergy Information
6
6
6
3
Procedure
6
Authorization Information
Contact Data
11
11
Observation Request
Notes and Comments
4
2
[{
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
Observation/Result
Notes and Comments
7
2
Patient Visit
Patient Visit Additional Info
3
3
Notes and Comments
2
TQ1
[{TQ2}]
}]
[
{
OBX
[{NTE}]
}
]
}
]
[
PV1
[PV2]
]
[{NTE}]
11.5.1
REF^I12I15^REF_I12
MSH
[RF1]
[
AUT
[CTD]
]
{
PRD
[{CTD}]
}
PID
October 2001
O&O Minutes
REF/RRI - patient referral message
Patient Referral
Chapter
Message Header
Referral Information
2
11
Authorization Information
Contact Data
11
11
Provider Data
Contact Data
11
11
Patient Identification
3
Page 53
[{NK1}]
[{GT1}]
[
{
IN1
[IN2]
[IN3]
}
]
[ACC]
[{DG1}]
[{DRG}]
[{AL1}]
[
{
PR1
[
AUT
[CTD]
}
]
[
{
OBR
[{NTE}]
[{
TQ1
[{TQ2}]
}]
[
{
OBX
[{NTE}]
}
]
}
]
[
PV1
[PV2]
]
[
PV1
[PV2]
]
[{NTE}]
RRI^I12I15^RRI_I12
MSH
[MSA]
[RF1]
[
AUT
[CTD]
]
{ PRD
[{CTD}]
}
PID
[ACC]
[{DG1}]
[{DRG}]
[{AL1}]
[
{
PR1
[
AUT
October 2001
O&O Minutes
Next of Kin/Associated Parties
Guarantor
6
6
Insurance
Insurance Additional Info
Insurance Add'l Info -Cert
6
6
6
Accident Information
Diagnosis
Diagnosis Related Group
Allergy Information
6
6
6
3
Procedure
6
Authorization Information
Contact Data
]
11
11
Observation Request
Notes and Comments
4
2
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
Observation/Result
Notes and Comments
7
2
Patient Visit
3
Patient Visit Additional Info
3
Patient Visit
Patient Visit Additional Info
3
3
Notes and Comments
2
Return Referral Information
Chapter
Message Header
Message Acknowledgment
Referral Information
2
3
11
Authorization Information
Contact Data
11
11
Provider Data
Contact Data
11
11
Patient Identification
Accident Information
3
6
Diagnosis
Diagnosis Related Group
Allergy Information
6
6
3
Procedure
6
Authorization Information
11
Page 54
[CTD]
}
]
[
{
OBR
[{NTE}]
[{
TQ1
[{TQ2}]
}]
[
{
OBX
[{NTE}]
}
]
}
]
[
PV1
[PV2]
]
[{NTE}]
October 2001
O&O Minutes
Contact Data
]
11
Observation Request
Notes and Comments
4
2
Start Timing/Quantity Group
Timing/Quantity
Timing/Quantity Order Sequence
End Timing/Quantity Group
4
4
Observation/Result
Notes and Comments
7
2
Patient Visit
Patient Visit Additional Info
3
3
Notes and Comments
2
Page 55
Part 6 CM Data Type Replacement Proposal
Short Description:
Continue to define new data types to replace existing CM data types.
Justification:
Continuation of proposal # 155,165, 166, 167 and 168.
Pharm 10/01/01 – will the use of CM_xxx names for 2.3.1 and 2.4 and new names (e.g.,
LA1) in 2.5 create problems with interversion messages when using XML. Strongly
suggest that the new names be used for 2.3.1 and 2.4, or keep the CM names in 2.5.
Control
Data Types
2.9.80
LA1 - location with address variation 1
HL7 Component Table – LA1 – Location with Address Variation 1
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
COMMENTS
SEC.REF.
1
IS
302
Point of Care
2.9.29.1
2
IS
303
Room
2.9.29.2
3
IS
304
Bed
2.9.29.3
4
HD
Facility
2.9.29.4
5
IS
306
Location Status
2.9.29.5
6
IS
305
Patient Location Type
2.9.29.6
7
IS
307
Building
2.9.29.7
8
IS
308
Floor
2.9.29.8
9
AD
Address
2.9.29.9
Note:
Replaces the CM data type used in 4.14.1.8 RXO-8 and 4.14.4.8 RXE-8 as of version 2.5.
Definition: Specifies a location and its address.
Issue 1: Although the CM applied to RXO-8, RXE-8, RXD-13, RXG-11 and RXA-11
began life as the same structure, they separated into 2 structures in versions 2.3 and 2.3.1.
This was confirmed by CQ on 2/9/01 and a distinct CM_LA1 structure and a CM_LA2
structure were defined and applied as an interim measure. Can we now move toward
bringing them together again or will we apply a bandaid and ask OO to deprecate the
fields and replace them with a new structure –perhaps a new XPL data type or perhaps 2
fields? The difference is that the LA1 has a component with an AD data type while LA2
has flattened the AD into components of the parent data type LA2.
Pharm 10/01/01 – agree that we do not want to consolidate the two at this time. But, one
of these two should be deprecated to prevent reuse … which would be better to keep?
Since AD is deprecated, suggest that LA1 be deprecated (not the fields, deprecate use of
the data type for future work) and LA2 be favored.
October 2001
O&O Minutes
Page 56
2.9.80.1 Point of Care (IS)
Definition:
Issue 2: This has already been defined as part of the PL data type. Should the definition
for this component and the following 7 components be repeated here? Should I simply
say: See 2.9.29.1 – PL-1 for definition?
Pharm 10/01/01 – prefer to have definition copied from PL into these components and
include a statement that the definition should be the same as the referenced PL
component defintion.
2.9.80.2 Room (IS)
Definition:
2.9.80.3 Bed (IS)
Definition:
2.9.80.4 Facility (HD)
Definition:
2.9.80.5 Location Status (IS)
Definition:
2.9.80.6 Patient Location Type (IS)
Definition:
2.9.80.7 Building (IS)
Definition:
2.9.80.8 Floor (IS)
Definition:
2.9.80.9 Address (AD)
Definition:
Issue 3: The AD data type has been deprecated and should not be applied to new uses.
Should this be replaced by the XAD data type? The XAD has an embedded complex data
type SAD. Maybe use of the AD can be considered definition of a current use not a new
use. If that is the case, should we say: See section 2.9.1?
Pharm 10/01/01 – since the CM already exists, the use of AD should not be an issue.
Additionally, our suggestion (see above) is to deprecate this data type, which would limit
the impact of using AD.
2.9.80 LA2 - Location with Address Variation 2
HL7 Component Table – LA2 – Location with Address Variation 2
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
COMMENTS
SEC.REF.
1
IS
302
Point of Care
2.9.29.1
2
IS
303
Room
2.9.29.2
3
IS
304
Bed
2.9.29.3
4
HD
Facility
2.9.29.4
October 2001
O&O Minutes
Page 57
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
COMMENTS
SEC.REF.
5
IS
306
Location Status
2.9.29.5
6
IS
305
Patient Location Type
2.9.29.6
7
IS
307
Building
2.9.29.7
8
IS
308
Floor
2.9.29.8
9
ST
Street Address
2.9.1.1
10
ST
Other Designation
2.9.1.2
11
ST
City
2.9.1.3
12
ST
State or Province
2.9.1.4
13
ST
Zip or Postal Code
2.9.1.5
14
ID
399
Country
2.9.1.6
15
ID
190
Address Type
2.9.1.7
16
ST
Note:
2.5.
Other Geographic Designation
Replaces the CM data type used in 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as of version
Definition: Specifies a location and its address.
Issue 1: 2/9: CQ confirms the LA1 structure and the LA2 structure are different; therefore
they are 2 distinct data types. Can we now move toward bringing them together again or
will we apply a bandaid and ask OO to deprecate the fields and replace them with a new
structure –perhaps a new XPL data type or perhaps 2 fields?
Pharm 10/01/01 – see above
2.9.80.1 Point of Care (IS)
Definition:
Issue 2: This has already been defined as part of the PL data type. Should the definition
for this component and the following 7 components be repeated here?
Pharm 10/01/01 – see above
2.9.80.2 Room (IS)
Definition:
2.9.80.3 Bed (IS)
Definition:
2.9.80.4 Facility (HD)
Definition:
2.9.80.5 Location Status (IS)
Definition:
2.9.80.6 Patient Location Type (IS)
Definition:
2.9.80.7 Building (IS)
Definition:
October 2001
O&O Minutes
Page 58
2.9.80.8 Floor (IS)
Definition:
2.9.80.9 Street Address (ST)
Definition:
Issue: This has already been defined as part of the AD data type. Should the definition
for this component and the following 7 components be repeated here? Or do we say: See
section 2.9.1.1?
Pharm 10/01/01 – see above PL discussion, same applies to ADOther Designation (ST)
Definition:
2.9.80.10 City (ST)
Definition:
2.9.80.11 State or Province (ST)
Definition:
2.9.80.12 Zip or Postal Code (ST)
Definition:
2.9.80.13 Country (ID)
Definition:
2.9.80.14 Street Address (ID)
Definition:
2.9.80.15 Other Geographic Designation (ST)
Definition:
2.9.81 WVI - channel identifier
HL7 Component Table – Channel Identifier
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
NM
Channel Number
2
ST
Channel Name
COMMENTS
SEC.REF.
Note: Replaces the CM data type used in 7.14.1.3.1 OBX-5.1 where OBX-5 Observation value (*) is data type CD as
of version 2.5.
Definition: This data type specifies the number and name of the recording channel where waveform data is
trnsmitted.
2.9.81.1 Channel number (NM)
Definition: This component specifies the number of the recording channel.
2.9.81.2 Channel name (ST)
Definition: This component specifies the name of the recording channel.
2.9.82 WVS - waveform source
HL7 Component Table – Waveform Source
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
ST
Source Name 1
2
ST
Source Name 2
October 2001
O&O Minutes
COMMENTS
SEC.REF.
Page 59
Note: Replaces the CM data type used in 7.14.1.4 OBX-5.2 where OBX-5 Observation value (*) is data type CD as of
version 2.5.
Definition: This data type identifies the source of the waveform connected to a channel.
2.9.82.1 Source name 1 (ST)
Definition: This component identifies the first input for the waveform source.
2.9.82.1 Source name 2 (ST)
Definition: This component identifies the second input for the waveform source.
2.9.83 CSU - channel sensitivity
HL7 Component Table – Channel Sensitivity
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
NM
Channel Sensitivity
2
ST
Unit of Measure Identifier
3
ST
4
ID
5
ST
Alternate Unit of Measure Identifier
6
ST
Alternate Unit of Measure
Description
7
ID
COMMENTS
SEC.REF.
Unit of Measure Description
396
396
Unit of Measure Coding System
Alternate Unit of Measure Coding
System
Note: Replaces the CM data type used in 7.14.1.5 OBX-5.3 where OBX-5Observation value (*) is data type CD as of
version 2.5.
Definition: This data type defines the channel sensitivity (gain) and the units in which it is measured in a
waveform result.
2.9.83.1 Channel sensitivity (NM)
Definition: This component transmits the nominal value 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.
2.9.83.2 Unit of measure identifier (ST)
Definition: The units designation for the channel sensitivity.
2.9.83.3 Unit of measure description (ST)
Definition: The full text name of the unit of measure identifier.
2.9.83.4 Unit of measure coding system (ID)
Definition: Specifies the coding system for the unit of measure.
2.9.83.5 Alternate unit of measure identifier (ST)
Definition: An alternate units designation for the channel sensitivity.
2.9.83.6 Alternate unit of measure description (ST)
Definition: The full text name of the alternate unit of measure identifier.
2.9.83.7 Alternate unit of measure coding system (ID)
Definition: Specifies the coding system for the alternate unit of measure.
October 2001
O&O Minutes
Page 60
2.9.84 CCP - channel calibration parameters
HL7 Component Table – Channel Calibration Parameters
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
1
NM
Channel Calibration Sensitivity
Correction Factor
2
NM
Channel Calibration Baseline
3
NM
Channel Calibration Time Skew
COMMENTS
SEC.REF.
Note: Replaces the CM data type used in 7.14.1.6 OBX-5.4 where OBX-5 Observation value (*) is data type CD as of
version 2.5.
Definition: This data type identifies the corrections to channel sensitivity, the baseline, and the channel time
skew when transmitting waveform results.
2.9.84.1 Channel calibration sensitivity correction factor (NM)
Definition: This component defines 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.
2.9.84.2 Channel calibration baseline (NM)
Definition: This component defines 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.
2.9.84.3 Channel calibration time skew (NM)
Definition: This component defines 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).
2.9.85 PLN – practitioner license or other ID number
Components:
<ID number (ST)> ^ <type of ID number (IS)> ^ <state/other qualifying info (ST)> ^
<expiration date (DT)>
Note: this a duplicate of the data type presented in proposal #167. It is repeated here for
the convenience of OO who will need to address some of the issues..
HL7 Component Table - PLN – practitioner license or other ID number
SEQ
LEN
DT
OPT
1
20
ST
R
2
8
IS
R
October 2001
O&O Minutes
TBL#
COMPONENT NAME
COMMENTS
SEC.REF.
ID number
0338
Type of ID number
Page 61
SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
3
62
ST
O
State/other qualifying info
4
8
DT
O
Expiration date
COMMENTS
SEC.REF.
Definition: This data type specifies a practitioner’s license number, or other ID number such as UPIN,
Medicare and Medicaid number, and associated detail.
Note:
Replaces the CM data type used in 15.4.5.6 PRA-6 as of version 2.5.
Issue: This data type should replace the CM data type applied to PRA-6 Practitioner
ID numbers as defined in chapter 15, section 15.4.5.6 , PRD-7 Provider identifiers as
defined chapter 11, section 11.6.3.7, and CTD-7 Contact identifiers as defined in
chapter 11, section 11.6.4.7. It should be noted that the PRA-6 may be deprecated in
v 2.5.
Issue: PRD-7 and CTD-7 currently do not have the 4th component “expiration date”.
Also, the 3rd component is described as “other qualify information”. However, the
narrative refers the reader to the PRA-6 for further specification.
Response: suggest OO TC deprecate these 2 segment fields and replace with new
fields of data type revised CX.
Issue: Should there be a proposal to deprecate PRD-7 and CTD-7 in favor of new
fields assigned data type CX?
Pharm 10/01/01 – agrees with the idea to deprecate these fields in favor of new fields
of type CX
2.9.85.1 ID number (ST)
Definition: Specifies the license number or other ID number such as UPIN, Medicare and Medicaid number.
2.9.85.2 Type of ID number (IS)
Definition: Specifies the type of number..
The practitioner ID number type (component 2) is a user-defined table (Table 0338).
User-defined Table 0338 - Practitioner ID number type
Value
CY
DEA
County number
Drug Enforcement Agency no.
GL
General ledger number
L&I
Labor and industries number
MCD
Medicaid number
MCR
Medicare number
QA
October 2001
O&O Minutes
Description
QA number
Page 62
Value
SL
Description
State license number
TAX
Tax ID number
TRL
Training license number
UPIN
Unique physician ID no.
2.9.85.3 State/other qualifying info (ST)
Definition: Optional component whichthat specifies the state or province in which the license or ID is valid,
if relevant, or other qualifying information. It is recommended that state qualifications use the
abbreviations from the postal service of the country.
2.9.85.4 Expiration date (DT)
Definition: Specifies the date when the license or ID is no longer valid..
October 2001
O&O Minutes
Page 63
Blood Bank Special Interest Group (BB SIG)
Proposal for Changes:
Blood Product Order Message
Blood Product Dispense Status Message
Blood Product Transfusion Message
October 2001
O&O Minutes
Page 64
Table of Contents
4.1
Document Objective
66
4.2
Message Identification 68
4.3
bLOOD bANK trigger events and messages
70
4.3.1
Usage notes for blood bank messages ................................................................................... 70
4.3.2
OMB – blood product order message (event O26) ............................................................... 70
4.3.3
ORB – blood product order acknowledgment (event O27) .................................................. 70
4.3.4
BPD – blood product dispense status message (event O28) ................................................. 71
4.3.5
BRP – blood product dispense status acknowledgment (event O29) .................................... 71
4.3.6
BTS – blood product transfusion message (event O30) ........................................................ 72
4.3.7
BRT – blood product transfusion acknowledgment (event O31) .......................................... 72
4.4
Blood Bank Segments
72
4.4.1
ORC - common order segment.............................................................................................. 72
4.4.2
BPO – blood product order segment ..................................................................................... 73
4.4.3
BPX – blood product dispense status segment...................................................................... 77
4.4.4
BTX – blood product transfusion segment ........................................................................... 87
October 2001
O&O Minutes
Page 65
Document Objective
This working document is intended to serve as an organized means of communicating all the information gathered
through the Blood Bank Special Interest Group (BB SIG). Information presented in this document has originated
from BB SIG meeting discussions, conference calls, individual contributions, and previously existing HL7
documents.
Note: The proper name for the laboratory area, which performs pre-transfusion testing for a patient to determine
product compatibility, is a transfusion service. The more commonly used name is blood bank. However, in the
blood bank industry, blood bank usually refers to the blood center where blood donations are made. Throughout
this document an attempt has been made to utilize the more appropriate name of transfusion service for the patientrelated messaging.
Problem:
The current HL7 standard does not adequately address the following transfusion service related interface issues:
1.
The specimen used for testing in a blood bank / transfusion service differs from a routine lab- oratory
specimen, as it has an extended expiration date and may be used for multiple orders for the duration of
the life of that specimen. This information needs to be communicated between the clinical staff and the
transfusion service. Also, labeling of blood specimens must follow very stringent labeling
requirements. Mis-labeled, mis-identified and expired specimens cannot be used for testing and this
information must also be communicated between the hospital staff and the transfusion service.
2.
There is no standard means of ordering blood products intended for transfusion to a patient, particularly
for a patient with special transfusion requirements.
3.
There is currently no standard means of communicating the status of blood products that are made
ready for transfusion to a patient by the transfusion service, or have been dispensed or transfused to a
patient.
4.
In order for the transfusion service medical staff to perform a prospective review of appropriateness of
a blood product order or subsequent transfusion, it is necessary to view the patient's current hematology
results of specific tests. This is readily performed when the transfusion service computer system is a
module within an LIS. However, stand-alone transfusion service computer systems do not have
immediate access to such information and are dependent upon receiving this information from the
clinician when the order is placed. There is currently no standard means of transmitting this
information.
5.
Transfusion service testing frequently involves performing tests that are relevant to more than one
individual, such as a mother and infant or a potential organ donor and intended recipient. There is
currently no way to link the results of testing to the related individual.
This current proposal addresses these issues in the following manner:
1) The transmission of specimen information is of great importance to the BB SIG. However, a proposed
solution is not included in this current proposal as the BB SIG is investigating the use of the Specimen
Source (SPM) segment, providing the required attributes can be added to that segment. This specimen
information should be included in any new messages in this proposal since the availability and status of
a blood bank specimen can change at any time. The BB SIG will seek the approval of the Specimen
Source committee for the additional specimen attributes.
2) Proposed new Blood Product Order message:
a)
Proposed new trigger event for the message (to be officially assigned by O/O):
26
b) New detail segment containing specific blood-product related attributes:
BPO
c)
ORB
New Acknowledgment message for the blood product order:
d) New trigger event for the acknowledgement (to be officially assigned by O/O):
e)
October 2001
O&O Minutes
OMB
27
Relevant clinical information is included in the OBX segment as needed.
Page 66
3) Proposed new Blood Product Dispense status message:
a)
Proposed new trigger event for the message (to be officially assigned by O/O):
BPS
28
b) New detail segment containing specific blood-product related attributes:
BPX
c)
BRP
New Acknowledgment message for the blood product order:
d) New trigger event for the acknowledgement (to be officially assigned by O/O):
4) Proposed new blood product transfusion message:
a)
Proposed new trigger event for the message (to be officially assigned by O/O):
29
BTS
30
b) New detail segment containing specific blood-product related attributes:
BTX
c)
BRT
New Acknowledgment message for the blood product order:
d) New trigger event for the acknowledgement (to be officially assigned by O/O):
31
The remaining sections of the proposal include the detail descriptions of the messages, segments and message usage.
October 2001
O&O Minutes
Page 67
Patient Related Messages
Message Identification
The following diagram depicts the message flow of the proposed new blood product messages.
Clinical Order
Entry System
(HIS)
Lab System
(LIS)
Transfusion
Service
System
Blood Product Order Message from Placer
(Trigger Event O26)
OMB
Acknowledgement from Filler
(Trigger Event O27)
ORB
Modification to order from placer or filler
(Trigger Event O26)
OMB
OMB
Acknowledgement from filler or placer
(Trigger Event O27)
ORB
ORB
Blood Product Dispense Status Message - Blood Product Ready to Dispense (RD) from filler
(Trigger Event O28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Clinical Order
Entry System
(HIS)
October 2001
O&O Minutes
Clinical Order
Entry System
(HIS)
Transfusion
Service
System
Page 68
Blood Product Dispense Message - Blood Product Dispensed (DI)
(Trigger Event 28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Stop/Cancel Transfusion
(Trigger Event O32)
BTS
Acknowledgement by filler
(Trigger Event O33)
BRT
Complete Transfusion by placer
(Trigger Event O30)
BTS
Acknowledgement by filler
(Trigger Event O31)
BRT
October 2001
O&O Minutes
Page 69
bLOOD bANK trigger events and messages
Usage notes for blood bank messages
OMB – blood product order message (event O26)
Blood product order messages present the need for additional information that is not included in standard
HL7 order messages. Order messages need to contain accompanying details regarding the blood product
component, such as special processing requirements (e.g. irradiation and leukoreduction), and the amount of
the blood product to be administered. Additionally, specific relevant clinical information can be included to
allow the prospective review of the appropriateness of the blood product order
Blood product orders can use the OMB message with the BPO segment for the detail segment and the
acknowledgment message, ORB as described below.
OMB^O26^OMB_O26
Blood Product Order Message
Chapter
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
BPO
[{NTE}]
[{DG1}]
[{
OBX
[{NTE}]
}]
[{FT1}]
[BLG]
}
Message Header
Notes and Comments (for Header)
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
3
3
2
3
3
6
6
6
Guarantor
Allergy Information
6
3
Common Order
Blood Product Order
Notes and Comments (for Order)
Diagnosis
4
4
2
6
Observation/Result
Notes and Comments (for Results)
7
2
Financial Transaction
Billing Segment
6
6
OMB use notes
a)
The NTE segment(s) can be included in the OMB message in four places; in each place the NTE refers
to the segment that it follows. In particular, the NTEs following the MSH refer only to the message
header; the NTEs following the blood product order segment apply to the service defined by that ORC
and blood product order segment.
b) The PID segment is required if and only if new orders are being entered and they are related to a
particular patient. For non-patient-related orders the PID segment is never included.
c)
The optional PV1 segment is present mainly to permit transmission of patient visit information such as
current location with an order.
ORB – blood product order acknowledgment (event O27)
ORB^O27^ORB_O27
Description
MSH
MSA
[ERR]
[{NTE}]
[
Message Header
Message Acknowledgment
Error
Notes and Comments (for Response Header)
October 2001
O&O Minutes
Chapter
2
2
2
2
Page 70
[PID
[{
ORC
[BPO]
}]
]
Patient Identification
3
Common Order
Blood Product Order
4
4
]
BPD – blood product dispense status message (event O28)
In the pre-transfusion processing of blood products, it is necessary for the transfusion service to
communicate information that is not included in the current HL7 order/observation model. Examples of pretransfusion processing include performing a crossmatch test to ensure compatibility with the patient, or
irradiation of the blood product due to a special transfusion requirement for the patient. The blood product
dispense status messages need to contain additional information regarding the blood products requested
such as the Donation ID number, product code, blood type, expiration date/time and current status of the
blood product.
In the processing of commercial blood products, such as Rh Immune Globulin, Factor Concentrate, or
Albumin Products, it is necessary for the transfusion service to communicate information that is not
included in the current HL7 order/observation model. The status messages need to contain additional
information regarding the blood products requested, such as the lot number and manufacturer, expiration
date and status of the commercial product.
A new message type and trigger event are proposed to initiate the transmission of a blood product dispense
status message each time the status of a blood product changes.
Blood product dispense status messages will use the BPS and BRP messages as described below.
BPS^O28^BPS_O28
Blood Product dispense status Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
]
{
ORC
BPO
[{NTE}]
[{
BPX
[{NTE}]
}]
}
Message Header
Notes and Comments (for Header)
Chapter
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
3
3
2
3
3
Common Order
Blood Product Order
Notes and Comments (for BPO)
4
4
2
Blood Product dispense status/Observation
Notes and Comments (for BPX)
4
2
BRP – blood product dispense status acknowledgment (event O29)
BRP^O29^BRP_O29
Description
MSH
MSA
[ERR]
[{NTE}]
[
[PID
[{
ORC
[BPO]
[{BPX}]
}]
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Response Header)
2
2
2
2
Patient Identification
3
Common Order
Blood Product Order
Blood Product dispense status/Observation
4
4
October 2001
O&O Minutes
Chapter
Page 71
BTS – blood product transfusion message (event O30)
A new message type and trigger event is proposed to notify the filler system of the final disposition
(transfusion) of a blood product.
Blood product transfusion messages will use the BTS and BRT messages as described below.
BTS^O30^BTS_O30
Blood Product Transfusion Message
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[PV1
[PV2]]
]
{
ORC
BPO
[{NTE}]
[{
BTX
[{NTE}]
}]
}
Message Header
Notes and Comments (for Header)
Chapter
2
2
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
3
3
2
3
3
Common Order
Blood Product Order
Notes and Comments (for BPO)
4
4
2
Blood Product Transfusion Status/Observation
Notes and Comments (for BTX)
4
2
BRT – blood product transfusion acknowledgment (event O31)
BRT^O31^BRT_O31
Description
MSH
MSA
[ERR]
[{NTE}]
[
[PID]
[{
ORC
[BPO]
[{BTX}]
}]
]
Message Header
Message Acknowledgment
Error
Notes and Comments (for Response Header)
Chapter
2
2
2
2
Patient Identification
3
Common Order
Blood Product Order
Blood Product Transfusion Status/Observation
4
4
4
Blood Bank Segments
ORC - common order segment
The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of
services that are requested). The ORC segment is required in the Order (ORM) message. ORC is
mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not
required otherwise.
If details are needed for a particular type of order segment (e.g., Pharmacy, Dietary), the ORC must precede
any order detail segment (e.g., RXO, ODS). In some cases, the ORC may be as simple as the string
ORC|OK|<placer order number>|<filler order number>|<cr>.
If details are not needed for the order, the order detail segment may be omitted. For example, to place an
order on hold, one would transmit an ORC with the following fields completed: ORC-1-order control with a
value of HD, ORC-2-placer order number, and ORC-3-filler order number.
There is some overlap between fields of the ORC and those in the order detail segments. These are
described in the succeeding sections.
October 2001
O&O Minutes
Page 72
HL7 Attribute Table – ORC – Common Order
SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM#
ELEMENT NAME
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2
22
22
22
2
1
200
200
26
250
250
250
80
250
26
250
250
250
250
250
250
250
250
250
250
ID
EI
EI
EI
ID
ID
TQ
CM
TS
XCN
XCN
XCN
PL
XTN
TS
CE
CE
CE
XCN
CE
XON
XAD
XTN
XAD
CWE
R
C
C
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
N
0119
N
0038
0121
00215
00216
00217
00218
00219
00220
00221
00222
00223
00224
00225
00226
00227
00228
00229
00230
00231
00232
00233
01310
01311
01312
01313
01314
01473
Order Control
Placer Order Number
Filler Order Number
Placer Group Number
Order Status
Response Flag
Quantity/Timing
Parent
Date/Time of Transaction
Entered By
Verified By
Ordering Provider
Enterer’s Location
Call Back Phone Number
Order Effective Date/Time
Order Control Code Reason
Entering Organization
Entering Device
Action By
Advanced Beneficiary Notice Code
Ordering Facility Name
Ordering Facility Address
Ordering Facility Phone Number
Ordering Provider Address
Order Status Modifier
Y
Y
Y
Y
Y/2
Y
0339
Y
Y
Y
Y
N
BPO – blood product order segment
Blood product order messages present the need for additional information that is not included in standard
HL7 order messages. Order messages need to contain accompanying details regarding the blood product
component, such as special processing requirements (e.g. irradiation and leukoreduction) and the amount of
the blood product to be administered.
The following table was used to present various use cases surrounding blood product orders. Discussions
of these examples led to the identification of new fields needed that are required for blood product order
messages.
Universal Service ID [ISBT-128
Universal Service ID]
Blood Product
Attribute
Quantity
Blood Product
Amount
Units
002^Red Blood Cells
Leukoreduced
2
300
ml
002^Red Blood Cells
Leukoreduced
1
60
ml
002^Red Blood Cells
Irradiated
2
15
ml
002^Red Blood Cells
Leukoreduced
1
020^Platelets
Leukoreduced
Irradiated
6
024^ Apheresis Platelets
Irradiated
1
910
IU
002^Red Blood Cells
1
Factor VIII
2
October 2001
O&O Minutes
Page 73
As can be seen from this table, in addition to the Universal Service ID, it may be necessary to order special
blood product attributes, such as leukoreduced or irradiated, or it may be necessary a particular volume of
red blood cells required for transfusion. The attributes for the BPO Segment are defined below.
HL7 Attribute Table – BPO – Blood Product Order
SEQ
LEN
DT
OPT
1
2
3
4
5
6
7
8
9
10
11
4
250
250
5
250
26
80
26
80
250
1
SI
CE
CE
NM
CE
TS
PL
TS
PL
CWE
ID
R
R
O
O
O
O
O
O
O
O
O
RP/#
TBL
#
Y
ITEM #
???
Y?
0136
ELEMENT NAME
Set ID – BPO
BP Universal Service ID
BP Attributes
BP Amount
BP Units
BP Intended Use Date/Time
BP Intended Dispense From Location
BP Requested Dispense Date/Time
BP Requested Dispense To Location
BP Indication for Use
BP Informed Consent Indicator
BPO field definitions
BPO-1 Set ID – BPO (SI)
Definition: This field contains the sequence number for the BPO segment within the message. For the first
order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
BPO-2 BP Universal service identifier (CE)
Components: <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 identifier code for the requested observation/test/battery. This can be
based on local and/or “universal” codes. We recommend the “universal” procedure identifier. The structure
of this CE data type is described in the control section. The preferred coding system is the ISBT 128
Product Cod e.
Blood Product Orders for commercial products such as Rh Immune Globulin or Factor VII concentrate are
not defined in an international or national coding system as are blood product. Therefore, locally defined
codes can be used of the Universal Service Identifier for commercial products.
Figure x-x. Appendix 1 - ISBT 128 Product Code Database Documentation Version 1.2.0
Code
ISBT 128 Component Class
001
WHOLE BLOOD
002
RED BLOOD CELLS
003
WASHED RED BLOOD CELLS
004
FROZEN RED BLOOD CELLS
005
FROZEN REJUVENATED RED BLOOD CELLS
006
DEGLYCEROLIZED RED BLOOD CELLS
007
DEGLYCEROLIZED REJUVENATED RED BLOOD CELLS
008
REJUVENATED RED BLOOD CELLS
009
APHERESIS RED BLOOD CELLS
010
FRESH FROZEN PLASMA
011
THAWED FRESH FROZEN PLASMA
012
APHERESIS FRESH FROZEN PLASMA
013
THAWED APHERESIS FRESH FROZEN PLASMA
014
APHERESIS PLASMA
October 2001
O&O Minutes
Page 74
015
THAWED APHERESIS PLASMA
016
LIQUID PLASMA
017
PLASMA
018
THAWED PLASMA
019
PLATELET RICH PLASMA
020
PLATELETS
021
WASHED PLATELETS
022
POOLED PLATELETS
023
WASHED POOLED PLATELETS
024
APHERESIS PLATELETS
025
FROZEN APHERESIS PLATELETS
026
THAWED APHERESIS PLATELETS
027
WASHED APHERESIS PLATELETS
028
CRYOPRECIPITATE
029
THAWED CRYOPRECIPITATE
030
POOLED CRYOPRECIPITATE
031
THAWED POOLED CRYOPRECIPITATE
032
APHERESIS CRYOPRECIPITATE
033
THAWED APHERESIS CRYOPRECIPITATE
034
GRANULOCYTES
035
APHERESIS GRANULOCYTES
036
POOLED GRANULOCYTES
037
APHERESIS GRANULOCYTES /PLATELETS
038
LEUKOCYTES
039
APHERESIS LEUKOCYTES
040
POOLED PLASMA
BPO-3 BP Attributes (CE)
Components: <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 additional information about the blood component class associated with the
Universal Service ID. The placer of the order can specify any required product attributes or special
processing requirements for the blood product, which must be completed prior to transfusion to the intended
recipient. Examples of processing requirements or product attributes include CMV Negative, HLA
Matched, Irradiated or Leukoreduced. Refer to HL7 Table #### (to be assigned) - Blood Component
Transfusion Requirements for suggested values.
This is an optional, repeating field.
HL7 Table #### (to be assigned) - Blood Component Transfusion Requirements
Value
October 2001
O&O Minutes
Description
LR
Leukoreduced
IR
Irradiated
CS
CMV Safe
FR
Fresh unit
AU
Autologous Unit
DI
Directed Unit
HL
HLA Matched
CM
CMV Negative
HB
Hemoglobin S Negative
WA
Washed
IG
IgA Deficient
Page 75
BPO-4 BP Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of blood product.
This field is optional so that a unit of blood can be ordered without an amount or unit specified.
BPO-5 BP Units (CE)
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the units for the blood product amount. This field contains the designation
for unit of measure for blood products. See 7.15.3.3.2.
This field is optional so that a unit of blood can be ordered without an amount or unit of measure specified.
BPO-6 BP Intended Use Date/Time (TS)
Definition: This field specifies the date/time associated with the scheduled availability of the blood
product.
This is the time when the product is expected to be available within the transfusion service. For example,
the product should be available for use but not dispensed on this date/time. This field is optional.
BPO-7 BP Intended Dispense From Location (PL)
Components:
<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: The first component contains location from which the blood component is to be issued (if
applicable). Locally defined codes can be used for this field. This field is an optional field and is used when
the transfusion service has more than one site from which blood products can be dispensed. This location
would indicate the specific facility from which the blood product should be dispensed.
BPO-8 BP Requested Dispense Date/Time (TS)
Definition: This field specifies the date/time that the requested blood products must be ready to dispense.
This date/time may be different from the Intended Use Date/time. For example, the patient may be
scheduled to come in for a transfusion at a specified time. However, the placer would request that the blood
product be ready to dispense prior to that in order to have the blood component ready for transfusion at the
scheduled time.
BPO-9 BP Requested Dispense To Location (PL)
Components:
<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: The first component contains the inpatient or outpatient location to which the blood component
is to be dispensed. The default (null) value is the current census location for the patient. Site-specific table.
The first eight components have the same form as the first eight components of PV1-3-assigned patient
location. The final eight components replace the ninth component of PV1-3-assigned patient location and
represent the full address specification.
BPO-10 BP Indication for Use (CE)
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
This is a coded optional field. The value indicates the reason that the blood product was ordered. Locally
defined codes can be used for this value. This information is helpful for prospective review or retrospective
October 2001
O&O Minutes
Page 76
studies of blood product ordering practices of the ordering provider by the Quality Assurance Department
and/ or Transfusion Committee. User-defined table #### – Indication for use is used as the HL7 identifier
for the user-defined table of values for this field.
User-defined Table #### – Indication for use
Value
Description
No suggested values
BPO-11 BP Informed Consent Indicator (ID)
This field indicates whether consent for the transfusion has been obtained.
This is an optional yes/no field.
BPX – blood product dispense status segment
In the processing of blood products, it is necessary for the transfusion service to communicate information
that is not included in the current HL7 order/observation model. The status messages need to contain
additional information regarding the blood products requested such as the unique donation ID, product
code, blood type, expiration date/time of the blood product, and current status of the product. This
segment is similar to an OBX segment, but contains additional attributes.
A new message type and trigger event is proposed to initiate the transmission of a blood product dispense
status message each time the blood product dispense status changes.
BP indicates that the component is Blood Products
CP indicates that the component is Commerical Product
BC indicates that the blood component.
HL7 Attribute Table – BPX – Blood Product dispense status
SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM #
ELEMENT NAME
Set ID – BPX
1
4
SI
R
2
3
4
5
6
7
8
9
10
11
12
13
14
15
250
1
26
22
250
250
250
250
22
250
250
26
5
5
CE
ID
TS
EI
CE
CE
CWE
XON
EI
CE
CE
TS
NM
NM
R
R
R
C
C
C
C
C
C
O
O
O
R
O
16
250
CE
O
BP Units
17
22
EI
O
BP Unique ID
18
80
PL
O
BP Actual Dispense To Location
19
250
XCN
O
BP Dispensed to Receiver
20
250
XCN
O
21
22
EI
O
October 2001
O&O Minutes
???
0085
?
?
?
Y
?
?
BP Status
BP Observation Status
BP Date/Time of Status
BC Donation ID
BC Component
BC Donation Type / Intended Use
CP Commercial Product
CP Manufacturer
CP Lot Number
BP Blood Group
BC Special Testing
BP Expiration Date/Time
BP Quantity
BP Amount
BP Responsible Observer
Y
BP Equipment Instance Identifier
Page 77
BPX field definitions
BPX-1 Set ID – BPX (SI)
Definition: This field contains the sequence number for the BPX segment under the related BPO segment.
For the first blood product dispense status transmitted, the sequence number shall be 1; for the second
product dispense status, it shall be 2; and so on.
BPX-2 BP Status (CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field is used to indicate the current status of the specified blood product as indicated by the
filler. For example, the first status change of a product that may trigger a Blood Product dispense status
Message is when it first becomes linked to a patient and is ready to dispense to a patient. When the blood
product is delivered or issued to a patient, the status of the blood product would be changed to indicate that
it has now been “dispensed.” A final status would indicate that the product has actually been “transfused.”
Refer to HL7 Table #### (to be assigned) - Blood product dispense status for suggested values.
HL7 Table #### - Blood product dispense status
Value
Placer(P)/Filler (F)
Description
RI
Received into inventory (for specified patient)
F
RD
Reserved and ready to dispense
F
RS
Reserved (ordered and product allocated for the patient)
F
RE
Released (no longer allocated for the patient)
F
DS
Dispensed to patient location
F
RA
Returned unused/no longer needed
F
RL
Returned unused/keep linked to patient for possible use later
F
WA
Wasted (product no longer viable)
F
PT
Presumed transfused (dispensed and not returned)
F
CR
Released into inventory for general availability
F
RQ
Request to dispense blood product
P
BPX-3 BP Observation status (ID)
Definition: The most commonly used values in a BPX will be preliminary and final. A status is considered
preliminary until a blood product has reached a final disposition for the patient. For example, when the
product is first cross-matched and a status message is sent, it would be considered preliminary. When the
product is dispensed to the patient, that status would also be considered preliminary. However, once the
product is transfused, the status would be considered final. The status of a blood product can continue to
change and the previous result should be overwritten until it reaches a final status. Refer to HL7 table 0085.
Table 0085 - Observation result status codes interpretation
Value
October 2001
O&O Minutes
Description
C
Record coming over is a correction and thus replaces a final result
D
Deletes the OBX record
F
Final results; Can only be changed with a corrected result.
I
Specimen in lab; results pending
N
Not asked; used to affirmatively document that the observation identified in the OBX was
not sought when the universal service ID in OBR-4 implies that it would be sought.
O
Order detail description only (no result)
P
Preliminary results
R
Results entered -- not verified
S
Partial results
X
Results cannot be obtained for this observation
Page 78
Value
Description
U
Results status change to final without re-transmitting results already sent as ‘preliminary.’
E.g., radiology changes status from preliminary to final
W
Post original as wrong, e.g., transmitted for wrong patient
BPX-4 BP Date/time of status (TS)
Definition: This field indicates the date and time that the status of the blood component was changed. For
example, if the blood component had a status, of "RD" (Ready to Dispense) , the date and time in this field
would indicate the date and time that component was made ready to dispense by the filler system. This is a
required field.
BPX-5 BC Donation ID (EI)
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: The donation ID is the unique identification number assigned to a blood donation. The donation
number will depend upon the bar code labeling system used for the component. There are currently two
blood component labeling standards: ABC CODABAR and ISBT 128. If using ISBT 128, the donation ID
Number is an internationally unique identifier consisting of the following 13 characters:
Country Code
Collection Facility
Donation Year
Serial Number
This is a conditional field and is required for blood components. It is not applicable for commercial
product messages.
BPX-6 BC Component
(CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: The Blood Component field includes a description of the specific blood component.
1st component: The numeric or alphanumeric product code, which represents the type of blood component.
The coding system will be determined by the bar code labeling system on the particular component of
blood. The preferred coding system is ISBT 128. If using ISBT 128 labeling standard, the product code
will consist of an 8-character alphanumeric code, starting with an alpha character and will include the
component class, donation type/intended use and division indicator.
If using CODABAR product labeling standard, the product code will consist of a 5-character numeric.
2nd Component: Product Description: The Product Description is a textual description of the numeric or
alphanumeric product code.
This is a conditional field and is required for blood components. It is not applicable for commercial
product messages.
User-defined table #### – Blood product component is used as the HL7 identifier for the user-defined table
of values for this field.
User-defined Table #### – Blood product component
Value
Description
No suggested values
October 2001
O&O Minutes
Page 79
BPX-7 BC Donation type / intended use (CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: Donation Type is used to indicate the type of donation or collection/intended use. This value is
populated from the list of Reference values below. The default value is “0” or “Unspecified.” Other values
will indicate if the blood product is an allogeneic unit from a volunteer donor, or is intended for a specific
recipient but may be crossed over and used for another recipient, or is an autologous donation intended only
for that particular recipient. Refer to Table 5 -Type of Donation in the ISBT 128 Bar Code Symbology and
Application Specification for Labeling of Whole Blood and Blood Components.
Figure X.X. ISBT 128 Table 5 – Type of Donation
Value
Description
0
Not specified
1
For autologous use only
X
For autologous use only – biohazardous
V
Voluntary allogeneic
D
Directed voluntary donation – eligible for crossover
Small d
Directed paid donation – eligible for crossover
P
Paid allogeneic donation
2
Directed voluntary allogeneic donation – for directed donor use only
L
Directed voluntary allogeneic donation – for directed donor use only – limited exposure
3
Directed voluntary allogeneic donation – for directed donor use only – biohazardous
4
Designated voluntary allogeneic donation
5
Dedicated voluntary allogeneic donation
R
Voluntary research donation
Small r
Paid research donation
S
Voluntary source donation
T
Voluntary therapeutic collection
This is a conditional field and is optional for blood component messages. It is not applicable for noncommercial product messages.
BPX-8 CP Commercial Product (CWE)
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 code and description to identify a commercial product. Examples of
commercial products are blood derivatives such as Rh Immune Globulin and Factor VIII concentrate,
Leukoreduction filters, and blood administration sets.
A site-specific table determines the value of the Commercial Product field. Free text can be utilized if no
update is to occur. User-defined table #### – Commercial product is used as the HL7 identifier for the
user-defined table of values for this field.
User-defined Table #### – Commercial product
Value
Description
No suggested values
This is a conditional field and is required for commercial blood products. It is optional for blood
component messages.
October 2001
O&O Minutes
Page 80
BPX-9 CP Manufacturer (XON)
Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be
the same as the supplier of the commercial product.
This is a conditional field and is required for commercial blood products. It is not applicable for blood
component messages.
BPX-10 CP Lot Number (EI)
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as
accessories to transfusion.
This is a conditional field and is required for commercial blood products. It is not applicable for blood
component messages.
BPX-11 BP Blood group (CE)
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 indicates the blood group of the blood component. The preferred values for the blood
group are the ISBT 128 specified values in Table 3A - Encodation of Blood Group in the ISBT 128 Bar
Code Symbology and Application Specification.
This is a conditional field and is required for blood components and certain commercial products (such as
detergent solvent plasma).
Figure 4-n. ISBT 128 Table 3A - Encodation of Blood Group
Value
Description
95
O Rh negative
51
O Rh positive
06
A Rh negative
62
A Rh positive
17
B Rh negative
73
B Rh Positive
28
AB Rh negative
84
AB Rh positive
55
O
66
A
77
B
88
AB
D6
para-Bombay Rh negative
E6
para-Bombay Rh positive
G6
Bombay Rh negative
H6
Bombay Rh positive
BPX-12 BC Special testing (CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This is a repeating optional field – to allow multiple entries for special testing that was
performed. The Special Testing code is used to indicate any types of Special Testing performed on the
blood component. The preferred coding system for Special Testing is defined in the ISBT 128 Bar Code
October 2001
O&O Minutes
Page 81
Symbology and Application Specification. Proposals have been developed and will soon be published by
ICCBBA, Inc. for the encodation of other antigen and antibody specificities including, HLA, platelet, red
cell and other types of markers.
This field is optional for blood component messages. It is not applicable for non-commercial product
messages.
Refer to Table Table I3 - Special Testing Codes of the ISBT 128 Bar Code Symbology and Application
Specification,
Figure 4-n. ISBT 128 Table I3 - Special Testing Codes
Code
October 2001
O&O Minutes
Description
N0000
default
N0001
HLA phenotyped
N0002
HPA phenotyped
N0003
IgA deficient
N0004
RBC phenotyped
N0005
RBC antibody(ies) present
N0006
RBC antibody absent
N0007
Specific antibody present
N0008
CMV seronegative
N0009
CMV seropositive
N0010
HLA antibody(ies) present
N0011
HLA antibody absent
N0012
HPA antibody(ies) present
N0013
HPA antibody absent
N0014
HLA phenotyped
HPA phenotyped
N0015
HLA phenotyped
IgA deficient
N0016
HLA phenotyped
RBC phenotyped
N0017
HLA phenotyped
RBC antibody(ies) present
N0018
HLA phenotyped
RBC antibody absent
N0019
HLA phenotyped
CMV seropositive
N0020
HLA phenotyped
CMV seronegative
N0021
HLA phenotyped
HLA antibody(ies) present
N0022
HLA phenotyped
HLA antibody absent
N0023
HLA phenotyped
HPA antibody(ies) present
N0024
HLA phenotyped
HPA antibody absent
N0025
HLA phenotyped
HPA phenotyped
RBC phenotyped
N0026
HLA phenotyped
HPA phenotyped
Page 82
RBC phenotyped
CMV seronegative
October 2001
O&O Minutes
N0027
HLA phenotyped
HPA phenotyped
RBC phenotyped
CMV seropositive
N0028
HLA phenotyped
RBC phenotyped
RBC antibody(ies) present
N0029
HLA phenotyped
RBC phenotyped
RBC antibody absent
N0030
HLA phenotyped
HLA antibody absent
RBC phenotyped
N0031
HLA phenotyped
HLA antibody absent
RBC phenotyped
CMV seronegative
N0032
HPA phenotyped
IgA deficient
N0033
HPA phenotyped
RBC phenotyped
N0034
HPA phenotyped
RBC antibody(ies) present
N0035
HPA phenotyped
RBC antibody absent
N0036
HPA phenotyped
CMV seronegative
N0037
HPA phenotyped
CMV seropositive
N0038
HLA antibody(ies) present
HPA phenotyped
N0039
HLA antibody absent
HPA phenotyped
N0040
HPA phenotyped
HPA antibody(ies) present
N0041
HPA phenotyped
HPA antibody absent
N0042
RBC phenotyped
IgA deficient
N0043
IgA deficient
CMV seronegative
N0044
IgA deficient
CMV seropositive
N0045
RBC phenotyped
RBC antibody(ies) present
N0046
RBC phenotyped
RBC antibody absent
N0047
RBC phenotyped
Specific antibody present
N0048
RBC phenotyped
CMV seronegative
N0049
RBC phenotyped
Page 83
CMV seropositive
October 2001
O&O Minutes
N0050
HLA antibody(ies) present
RBC phenotyped
N0051
HLA antibody absent
RBC phenotyped
N0052
HPA antibody(ies) present
RBC phenotyped
N0053
HPA antibody absent
RBC phenotyped
N0054
RBC phenotyped
RBC antibody absent
CMV seronegative
N0055
RBC phenotyped
RBC antibody absent
CMV seropositive
N0056
HLA antibody absent
RBC phenotyped
RBC antibody absent
CMV seronegative
N0057
HLA antibody absent
RBC phenotyped
RBC antibody absent
CMV seropositive
N0058
HLA antibody absent
HPA antibody absent
RBC phenotyped
RBC antibody absent
CMV seronegative
N0059
HLA antibody absent
HPA antibody absent
RBC phenotyped
RBC antibody absent
CMV seropositive
N0060
RBC antibody(ies) present
Specific antibody(ies) present
N0061
RBC antibody(ies) present
CMV seronegative
N0062
RBC antibodiy(ies) present
CMV seropositive
N0063
HLA antibody(ies) present
RBC antibody(ies) present
N0064
HLA antibody absent
RBC antibody(ies) present
N0065
HPA antibody(ies) present
RBC antibody(ies) present
N0066
HPA antibody absent
RBC antibody(ies) present
N0067
RBC antibody absent
Specific antibody present
N0068
RBC antibody absent
CMV seronegative
N0069
RBC antibody absent
CMV seropositive
N0070
HLA antibody(ies) present
Page 84
RBC antibody absent
October 2001
O&O Minutes
N0071
HLA antibody absent
RBC antibody absent
N0072
HPA antibody(ies) present
RBC antibody absent
N0073
HPA antibody absent
RBC antibody absent
N0074
CMV seronegative
Specific antibody present
N0075
CMV seropositive
Specific antibody present
N0076
HLA antibody(ies) present
Specific antibody present
N0077
HLA antibody absent
Specific antibody present
N0078
HPA antibody(ies) present
Specific antibody present
N0079
HPA antibody absent
Specific antibody present
N0080
HLA antibody(ies) present
CMV seronegative
N0081
HLA antibody absent
CMV seronegative
N0082
HPA antibody(ies) present
CMV seronegative
N0083
HPA antibody absent
CMV seronegative
N0084
HLA antibody(ies) present
CMV seropositive
N0085
HLA antibody absent
CMV seropositive
N0086
HPA antibody(ies) present
CMV seropositive
N0087
HPA antibody absent
CMV seropositive
N0088
HLA antibody(ies) present
HPA antibody(ies) present
N0089
HLA antibody(ies) present
HPA antibody absent
N0090
HLA antibody absent
HPA antibody(ies) present
N0091
HLA antibody absent
HPA antibody absent
N0092
For future use
N0093
For future use
N0094
For future use
N0095
For future use
N0096
For future use
N0097
For future use
N0098
For future use
N0099
For future use
N0100
CMV antibody present
N0101
Anti-D present
Page 85
N0102
HAV antibody present
N0103
HBV antibody present
N0104
Tetanus antibody present
N0105
Varicella Zoster antibody present
BPX-13 BP Expiration date/time (TS)
Definition: The expiration date/time specifies the date and time that the blood product expires. The blood
product is no longer considered acceptable once the expiration date has been reached unless cleared by the
blood bank medical staff.
BPX-14 BP Quantity (NM)
Definition: This field indicates the number of blood bank products or components.
This is a required field.
BPX-15 BP Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of a blood bank
component. This is an optional field.
BPX-16 BP Units (CE)
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 units for the blood product quantity. (See Chapter 7 for more details
about identifying reporting units.) This field may be used to specify the units of measure for volume of a
blood component (i.e. 50 ml). It may also be used to indicate the unit of measure or dosage of a
commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate).
BPX-17 BP Unique ID (EI)
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: This field is a unique system-generated number assigned to the blood product to which the
message is referring. Each time the status is updated, the new message should replace the previous message
if the Blood Product dispense status ID Number is the same. If the Blood Product dispense status ID
Number is different, it indicates that the status applies to a different blood product.
This is an optional field and its use must be agreed upon by the sending and receiving systems.
BPX-18 BP Dispensed to Location (PL)
Components:
<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: The first component contains the inpatient or outpatient location to which the blood component
was actually dispensed. The default (null) value is the current census location for the patient. Site-specific
table. The first eight components have the same form as the first eight components of PV1-3-assigned
patient location. The final eight components replace the ninth component of PV1-3-assigned patient
location and represent the full address specification
This field is optional.
BPX-19 BP Dispensed to receiver (XCN)
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.,
October 2001
O&O Minutes
Page 86
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)>
Subcomponents of assigning authority:
type (ID)
Subcomponents of assigning facility:
type (ID)
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
Definition: This is the person who picked up the blood unit(s) and transported them. The code for the
receiver is recorded as a XCN data type. If the identity is sent as a local code, it should be unique and
unambiguous when combined with BPX-25-producer ID (need to determine what this means BTX 14, 15).
This field can be free text to permit capture without table update. In this case, the receiver’s name must be
recorded as the second through fourth components of the field.
This field is optional.
BPX-20 BP Responsible Observer (XCN)
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)>
Subcomponents of assigning authority:
type (ID)
Subcomponents of assigning facility:
type (ID)
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
Definition: This field is used to indicate the identification of the individual who prepared the blood
component. This is an optional field.
BPX-21 BP Equipment Instance Identifier (EI)
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: This field identifies the Equipment Instance (e.g., Analyzer, Analyzer module, group of
Analyzers) responsible for the production of the observation. This is the identifier from an institution's
master list of equipment, where the institution is specified by the namespace ID or if it is blank, then by the
“BP Producer’s ID” (BPX-7). It should be possible to retrieve from this master list the equipment type,
serial number, etc., however it is not planned to transfer this information with every BPX. The repeating of
this field allows for the hierarchical representation of the equipment (lowest level first), e.g., module of an
instrument, instrument consisting of modules, cluster of multiple instruments, etc.
BTX – blood product transfusion segment
HL7 Attribute Table – BTX – Blood Product Transfusion
SEQ
LEN
DT
OPT
1
4
SI
R
2
3
4
5
6
7
8
22
250
250
250
250
22
5
EI
CE
CE
CE
XON
EI
NM
C
C
C
C
C
C
R
October 2001
O&O Minutes
RP/#
TBL#
ITEM #
ELEMENT NAME
Set ID – BTX
?
?
?
BC Donation ID
BC Component
BC Blood Group
CP Commercial Product
CP Manufacturer
CP Lot Number
BT Quantity
Page 87
SEQ
LEN
DT
OPT
9
10
11
12
5
250
250
1
NM
CE
CE
ID
O
O
R
R
RP/#
TBL#
?
?
ITEM #
ELEMENT NAME
BP Amount
BT Units
BT Transfusion Status
BT Observation Status
13
26
TS
R
BT Date/Time of Status
14
250
XCN
O
BT Administrator
15
250
XCN
O
BT Verifier
16
26
TS
O
BT Start Date/Time
17
26
TS
O
18
1
ID
O
19
250
CE
O
20
1
ID
21
250
CWE
BT End Date/Time
0136
Y
BT Adverse Reaction Indicator
?
BT Adverse Reaction Type
O
0136
BT Transfusion Interrupted
O
?
BT Transfusion Interrupted Reason
BTX field definitions
BTX-1 Set ID – BTX (SI)
Definition: This field contains the sequence number for the BTX segment under the related BPO segment.
For the first product transfusion transmitted, the sequence number shall be 1; for the second product
transfusion, it shall be 2; and so on.
BTX-2 BC Donation ID (EI)
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: The donation ID is the unique identification number assigned to a blood donation. The donation
number will depend upon the bar code labeling system used for the component. There are currently two
blood component labeling standards: ABC CODABAR and ISBT 128. If using ISBT 128, the donation ID
Number is an internationally unique identifier consisting of the following 13 characters:
Country Code
Collection Facility
Donation Year
Serial Number
This is a conditional field and is required for blood components. It is not applicable for commercial
product messages.
BTX-3 BC Component (CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: The Blood Component field includes a description of the specific blood component.
1st component: The numeric or alphanumeric product code, which represents the type of blood component.
The coding system will be determined by the bar code labeling system on the particular component of
blood. The preferred coding system is ISBT 128. If using ISBT 128 labeling standard, the product code
will consist of an 8-character alphanumeric code, starting with an alpha character and will include the
component class, donation type/intended use and division indicator.
If using CODABAR product labeling standard, the product code will consist of a 5-character numeric.
2nd Component: Product Description: The Product Description is a textual description of the numeric or
alphanumeric product code.
This is a conditional field and is required for blood components. It is not applicable for commercial
product messages.
October 2001
O&O Minutes
Page 88
BTX-4 BC Blood Group (CE)
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 indicates the blood group of the blood component. The preferred values for the blood
group are the ISBT 128 specified values in Table 3A - Encodation of Blood Group in the ISBT 128 Bar
Code Symbology and Application n Specification.
This is a conditional field and is required for blood components. It is not applicable for commercial
product messages.
Refer to section 4.4.3.11 for the contents of figure x-x. ISBT 128 Table 3A - Encodation of Blood Group.
BTX-5 CP Commercial Product (CE)
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 code and description to identify a commercial product. Examples of
commercial products are blood derivatives, such as Rh Immune Globulin and Factor VIII Concentrate and
transfusion accessories, such as Leukoreduction filters, and blood administration sets. User-defined table
#### – Commercial product is used as the HL7 identifier for the user-defined table of values for this field.
User-defined Table #### – Commercial product
Value
Description
No suggested values
This is a conditional field and is required for commercial blood products. It is optional for blood
component messages.
BTX-6 CP Manufacturer (XON)
Definition: This field identifies the manufacturer of the commercial product. The manufacturer may not be
the same as the supplier of the commercial product.
This is a conditional field and is required for commercial blood products. It is not applicable for blood
component messages.
BTX-7 CP Lot Number (EI)
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type (ID)>
Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as
accessories to transfusion.
This is a conditional field and is required for commercial blood products. It is not applicable for blood
component messages.
BTX-8 BT Quantity (NM)
Definition: This field indicates the number of blood bank products or components.
BTX-9 BT Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of a blood bank
component. This is an optional field.
October 2001
O&O Minutes
Page 89
BTX-10 BT Units (CE)
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 units for the blood product quantity. (See Chapter 7 for more details
about identifying reporting units.) This field may be used to specify the units of measure for volume of a
blood component (i.e. 50 ml). It may also be used to indicate the unit of measure or dosage of a
commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate.
BTX-11 BT Transfusion Status (CE)
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier
(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field is used to indicate the current status of the specified blood product as indicated by the
placer. For example, the placer may return the blood product to the transfusion service unused or wasted
because an IV could not be started. A final status would indicate that the product has actually been
“transfused.” Refer to HL7 Table #### (to be assigned) - Blood Product Transfusion Status for suggested
values.
HL7 Table #### - Blood Product Transfusion Status
Value
Description
DS
Dispensed to patient location
RA
Returned unused/no longer needed
RL
Returned unused/keep linked to patient for possible use later
WA
Wasted (product no longer viable)
TX
Transfused
TR
Transfused with adverse reaction
BTX-12 BT Observation status (ID)
Definition: The most commonly used values in a BTX will be preliminary and final. A status is considered
preliminary until a blood product has reached a final disposition for the patient. For example, when the
product is first cross-matched and a status message is sent, it would be considered preliminary. When the
product is dispensed to the patient, that status would also be considered preliminary. However, once the
product is transfused, the status would be considered final. The status of a blood product can continue to
change and the previous result should be overwritten until it reaches a final status.
Table 0085 - Observation result status codes interpretation
Value
October 2001
O&O Minutes
Description
C
Record coming over is a correction and thus replaces a final result
D
Deletes the OBX record
F
Final results; Can only be changed with a corrected result.
I
Specimen in lab; results pending
N
Not asked; used to affirmatively document that the observation identified in the OBX
was not sought when the universal service ID in OBR-4 implies that it would be sought.
O
Order detail description only (no result)
P
Preliminary results
R
Results entered -- not verified
S
Partial results
X
Results cannot be obtained for this observation
U
Results status change to final without retransmitting results already sent as
‘preliminary.’ E.g., radiology changes status from preliminary to final
W
Post original as wrong, e.g., transmitted for wrong patient
Page 90
BTX-13 BT Date/time of status (TS)
Definition: This field indicates the date and time that the status of the blood component was changed. For
example, if the blood component had a status, of "TX" (Transfused), the date and time in this field would
indicate the date and time that component was transfused the placer system.
BTX-14 BT Administrator (XCN)
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)>
Subcomponents of assigning authority:
type (ID)
Subcomponents of assigning facility:
type (ID)
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
Definition: This field contains the identity of the individual who administers the transfusion of the blood
product. The identity for the individual is recorded as a XCN data type. If the code is sent as a local code,
it should be unique and unambiguous when combined with BPX-250-producer ID. This field can be free
text to permit capture without table update. In this case, the administrator’s name must be recorded as the
second through fourth components of the field.
This field is optional.
BTX-15 BT Verifier (XCN)
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)>
Subcomponents of assigning authority:
type (ID)
Subcomponents of assigning facility:
type (ID)
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
<namespace ID (IS)> & <universal ID (ST)> & <universal ID
Definition: This field contains the identity of the individual who assists in the identification of the patient
and verification of the product information prior to transfusion of the blood product. The identity for the
verifier is recorded as a XCN data type. If the ID Number is sent as a local code, it should be unique and
unambiguous when combined with BPX-250-producer ID. This field can be free text to permit capture
without table update. In this case, the verifier’s name must be recorded as the second through fourth
components of the field.
This field is optional.
BTX-16 BT Start Date/time of status (TS)
Definition: This field indicates the date and time that the verifier started the transfusion of the blood
component or commercial product.
This is an optional field.
BTX-17 BT End Date/time of status (TS)
Definition: This field indicates the date and time that the transfusion of the blood component or
commercial product was completed or stopped.
October 2001
O&O Minutes
Page 91
This is an optional field.
BTX-18 BT Adverse Reaction Indicator (ID)
This field indicates whether the recipient of the blood product experienced an adverse reaction.
This is an optional yes/no field.
BTX-19 BT Adverse Reaction Type (CE)
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 type of adverse reaction that the recipient of the blood product
experienced. Locally defined codes for this value can be used. This is an optional field. User-defined
table #### –Transfusion adverse reaction type is used as the HL7 identifier for the user-defined table of
values for this field.
User-defined Table #### – Transfusion adverse reaction
Value
Description
No suggested values
BTX-20 BT Transfusion Interrupted (ID)
This field indicates whether the transfusion of the blood product was interrupted or stopped prior to the
completion of the transfusion.
This is an optional yes/no field.
BTX-21 BT Transfusion Interrupted Reason (CWE)
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 reason that the transfusion of the blood product was interrupted. Locally
defined codes for this value can be used. This is an optional field. User-defined table #### – Transfusion
interrupted reason is used as the HL7 identifier for the user-defined table of values for this field.
User-defined Table #### – Transfusion interrupted reason
Value
Description
No suggested values
October 2001
O&O Minutes
Page 92
Attachment B – Version 3 Ballot Response Summary
Highlighted items are ones we recommend be discussed in Salt Lake City by the relevant committee(s).
Items in Green are those we need to make sure we have a response for, since they didn’t come up directly in discussion (that I'm aware of).
Practice & Operations
ID #
Section
Vote
Type
Existing Wording
Proposed Wording
Comments
DM
General
N
Mj
See comment
See comment
The current documentary form contains
insufficient usage notes about individual
attributes in particular RMIM refined classes
(or in the common HMD) to allow any
certainty of interoperability. Numerous
specific examples can be offered for each of
the individual messages where the RIM
description of the attribute is too general to
be sure of the intended usage in a specific
message.
A revised documentary form is needed with
usage notes available for each attribute of
each class in the RMIM. This could most
elegantly be provided in an extended version
of the common HMD. Until this is available a
really informed affirmative vote on this
document is not possible. Even though it is
possible that the usage intended by the
authors is entirely appropriate to the
proposed interactions. This usage needs to be
made explicit.
An example of the problem …
Substance_admin_order.max_dose_qty in
HMPO_RX_RM01000. What does this
maximum dose mean in the order? Is it an
instruction that the recipient of the order
limits the supply OR indicates on the
supplied medication the maximum? The
answer may seem self-evident to the
authors of the RMIM but it needs to be
stated explicitly in relation to these
October 2001
O&O Minutes
Disposition
Page 93
Identif
ier
ID #
Section
Vote
Type
Existing Wording
Proposed Wording
Comments
Disposition
Identif
ier
MnM Issue
1
Description
issue. LAPOCT
2
LAPOCT.
misundertstood
process.
3
LAPOCT
Not lab
Description
issue. LAPOCT
4
Description
issue. LAPOCT
LAPOCT&OO
Combine with
discussion of
#16.
OO
6
MnM issue.
Description
issue.
9
Description
issue. OO,
LAPOCT
10
messages to ensure safety and
interoperability.
Note that this is only example, the primary
problem is the restriction of the documentary
form.
AK
2
N
Mi
AK
2.1
N
Mi
AK
2.2
A
S
AK
2.2
N
Mi
AK
2.2
N
Mi
AK
2.3
N
Mi
AK
2.4
N
Mi
AK
2.5
N
Ma
AK
3
N
Mi
AK
3
N
Mi
October 2001
O&O Minutes
All the CMET names in this section need to be reviewed
in light of the CMET naming standard that emerged
from the Indianapolis Publishing meeting in July 2001.
I think the description of this CMET needs to be beefed
up. To just say that it describes the specimen and the
container simplifies it to much. It's obvious from the RMIM diagram that a lot of things about specimens,
containers, observations about specimens, etc. are
included in the CMET.
OrderOptions RMIM. There are constraints on the value
data type give in the RMIM. The appropriate way to
indicate the data type for a given attribute is to place the
data type restriction directly in the class, for example:
O_ReflexPermission.value: BL
Since the value attribute is associated with each Act
clone in this CMET, shouldn't the mood be EVN?
The description of the Order Options CMET needs to be
enhanced to describe what options it provides. Also
needs to describe how it should be used.
The description of the Reagent CMET needs to be more
descriptive. It's currently a circular definition.
Since there may be a charge for a transport service, the
Financial_txn CMET should be associated with the
Transport_clin CMET.
The Supporting Clinical Information CMET does not
contain any allergy information. Although an allergy is a
form of observation, it is not a simple observation, so
it's not really supported by the Clinical_observation
cloned class in the R-MIM.
Scattered throughout the Lab Domain are comments,
descriptions, etc. that contain information relating a
Version 3 component with something from version 2.x.
In general these comments need to re-written to explain
the 2.x jargon, so that people not familiar with 2.x can
still understand what's been written.
In general, the descriptions provided in the Lab Domain
are sketchy. They need to be elaborated more, so they
better describe the artifact in question.
Page 94
5
7
8
ID #
Section
Vote
Type
AK
3.1
5.1
N
Ma
AK
3.1
N
Ma
AK
3.1.1.1.2
3.1.2.1.2
3.1.3.1.2
N
Mi
AK
3.1.1.1.2.3
3.1.1.2.2.3
N
Mi
AK
3.2
N
Ma
AK
3.3.1
3.3.2
3.3.3
N
Mi
October 2001
O&O Minutes
Existing Wording
Proposed Wording
Comments
Disposition
As part of Indianapolis Harmonization meeting, the Act
state machine was revised. This has considerable impact
on the types and names of interactions used in Lab
Orders, Intents, Events and Shared Interactions. In
addition, there has been considerable debate on how to
name the various individual interactions, such that they
uniquely identify the interaction, yet are readable. A
naming convention for interactions needs to be worked
out amongst the various groups building interaction
models. The same issue's occur with Trigger events,
since we have derived them from the Act state machine.
Most of the Ladder diagrams used for the Storyboards
within the Lab Orders Interaction category show a
notification message from the filler to a tracker, where
the filler is notifying the tracker of the relevant event.
This notification should be using the placer application
role as the originating application role, not the filler
application role.
Although the Lab Domain is intended to support
LAPOCT, none of the storyboards reflect any LAPOCT
messaging. I believe it is critical that LAPOCT supply
storyboard examples for the Lab Domain.
The Infrastructure part of the ballot current states that an
application acknowledgement can't itself require an
application acknowledgement, and yet this complex set
of interactions appears to require just that.
OO, Rx
Identif
ier
11
OO, LAPOCT
12
OO, LAPOCT
13
OO, Control.
Multiple
negatives on
Infrastructure
ballot on this
issue. Need to
resolve with
Control.
MnM issue
Austin: MnM
has resolved
this issue to
allow App roles
to contain other
app roles.
14
OO. Combine
with discussion
of transport
CMET (#7)
16
The application Roles for Lab as they are now set up are
hierarchical in nature. This means that a child
application role can have a single parent application
role. In reality they need to be more flexible than that.
Instead of a parent/child (or tree) model for application
roles, we need to use a more open model, where an
application role can fall into several groups of different
application roles.
The 2.x order message included a BLG segment so the
placer could communicate to the filler when to bill for
the service being ordered. We need to include the
Financial_txn CMET into the Lab RMIM's so we can
continue to communicate this information. We will need
to submit a vocabulary for the TimingEvent table
(which is used with the EIVL data type) to support this
addition.
Page 95
15
ID #
Section
Vote
Type
AK
3.3.1
3.3.2
3.3.3
N
Mi
AK
3.3.1
3.3.2
3.3.3
N
Mi
DY
Throughout RX
P&O
N
Mi
DY
4.1.1.1,
4.1.1.2,
4.1.2.2,
4.1.2.4,
4.1.3.1
N
Ma
Existing Wording
Administration Instance Order
Pharmacy Administration
Intent
DY
4.1.1.1.3 &
Throughout entire
RX P&O
4.1.3.1.2
N
Ma
N
Ma
DY
4.2.25
4.2.24
N
Ma
DY
4.2.24
4.2.25
N
Mj
DY
October 2001
O&O Minutes
Proposed Wording
Pharmacy Give (order) The
appropriate mood could be added to
the end.
Pharmacy Administration Order
Acknowledgement (Intent).
Pharmacy Administration
Instance Intent
Pharmacy Give Acknowledgement
(intent)
Pharmacy Administration
Event
Pharmacy Administration (event)
Comments
Disposition
We need to include the Detailed_diagnosis CMET to the
Lab Order, Intent and Event RMIM's. This will allow us
to associate the order/intent/event to the diagnosis that
required the order in the first place.
Act.priority_cd vocabulary is missing. USAM included
a vocabulary for priority_cd, but it's never made it into
the Vocabulary model. We will need to submit the
vocabulary for the next Harmonization.
Need interactions for nullified and obsolete states.
OO, LAPOCT
Identif
ier
17
OO, Vocab
18
OO, LAPOCT,
Rx. Same as
State Machine,
#11
MnM issue.
Austin: MnM is
working on a
standard for
naming app
roles, trigger
events, and
interactions.
There will also
be the ability to
add 2.x
comments for
most of the
artifacts.
19
Rx
21
Rx
22
Rx
23
OO, Rx,
LAPOCT
24
The pharmacy interaction naming standards and
Descriptions need to be more informative. The term
Administration is used too broadly to represent different
concepts. The term ‘Administration’ is used for orders,
gives/schedules as well as administrations. I understand
the need to correlate the names to the mood but the noun
part should describe what the object is. The
descriptions use the term administration in a general
way. It would help if there was a legend relating the
current 3.0 concepts to existing 2.x concepts(or a
translation next to the categories and descriptions) This
is like learning a new language. For people who already
have a primary language they have to translate what
they know to the new language. For those who have no
language they need the definitions without translation
but the definitions need to make sense.
We are missing interaction diagrams for all but one
interaction, the simple outpatient prescription.
All of the administration event storyboard scenarios I
submitted are missing. The only storyboard present is
for a simple outpatient prescription.
Missing sending role interactions for communicating the
administration event to order fillers. The pharmacy or
filler may need to further act based on the admin event (
charge for a dose, reschedule future schedules, cancel
future schedules) based on what is in the admin record.
By only communicating to Trackers who only store the
data and do not interact or react based on it is
unacceptable. There seem to be similar missing
interactions throughout the document.
Missing receiver request and sender notify role
interactions for abort, resume, cancel, hold.
Page 96
20
ID #
Section
Vote
Type
DY
4.2.33
4.2.34
4.2.33
4.2.34
N
Mj
N
Mi
DY
4.3.1.1.1
& Throughout RX
HMD
N
Ma
DY
4.3.8
N
Mi
DY
5
N
Ma
AK
5
N
Mi
AK
5
N
Mi
AK
5.1
N
Ma
DY
October 2001
O&O Minutes
Existing Wording
Proposed Wording
A loosely coupled version of a
Pharmacy Order Filler that is
only capable of filling orders
consisting of single occurrence
substance administrations. This
type of application relies on the
placer application to break
complex orders into a series of
instance orders. (A looselycoupled application is one
where the assumption is there
is no shared repository
containing information on
providers, patients, etc.)
Contains the classes, attributes
and associations necessary for
communicating dispense
events
Contains the classes, attributes and
associations necessary for
communicating therapy
administration events
Comments
Disposition
Identif
ier
Missing sender and receiver interactions for cancel,
abort, resume, hold and notify activate, notify supercede
The Placer may not be able to break the request into
single instance orders and the filler may not ONLY
handle single instance orders. Is it a different Category
(s) responsible when it is a combination of these or do
we just need to improve the language here?
OO, Rx,
LAPOCT
Rx
25
In pharmacy order HMDs, the cd attribute domain is
listed as ACT_CODE. There is no reference within
ACT_CODE to the more granular and required Clinical
Drug. This implies that any act code is acceptable for
pharmacy orders.
The RMIM Admin Event Descriptions all define the
event as being for pharmacy dispense events. It should
describe it as being for therapy administration events.
Rx, Vocab
27
Rx. Description
issue.
28
The descriptions provided in the Shared Interactions
Domain are insufficient.
Scattered throughout the Shared Interactions Domain
are comments, descriptions, etc. that contain
information relating a Version 3 component with
something from version 2.x. In general these comments
need to be re-written to explain the 2.x jargon, so that
people not familiar with 2.x can still understand what's
been written.
In general, the descriptions provided in the Shared
Interactions Domain are sketchy. They need to be
elaborated more, so they better describe the artifact in
question.
Many of the Ladder diagrams used for the Storyboards
within the Shared Interaction domain show a
notification message from the filler to a tracker, where
the filler is notifying the tracker of the relevant event.
This notification should be using the placer application
role as the originating application role, not the filler
application role.
MnM issue.
Same as #30.
MnM issue.
Same as #29.
29
MnM issue.
31
OO, Rx,
LAPOCT
Same as #12.
32
Page 97
26
30
ID #
Section
Vote
Type
AK
5.1.1.1.2
5.1.2.1.2
5.1.3.1.2
N
Ma
AK
5.3.2
N
Mi
HB
All
N
Mj
HB
All
N
Mj
HB
N
Mj
HB
2.1, 2.2,
2.3, 2.4,
2.5, 2.6,
2.7, 2.8,
2.9, 3.3.1,
3.3.2, 3.3.3,
4.3.1, 4.3.2,
4.3.3, 4.3.4,
4.3.5, 4.3.6,
4.3.7, 4.3.8,
4.3.9
All
N
Mi
HB
2.6
N
Mj
HB
2.8.,2.9
N
Mi
October 2001
O&O Minutes
Existing Wording
Proposed Wording
Comments
Disposition
None of the Storyboards for Shared Interactions have
Storyboard examples. Although the narrative for the
examples aren't normative, it is critical to understanding
the interactions.
We need to iron out with Control what and application
Accept/Reject message payload should look like.
OO, Rx,
LAPOCT
Control, OO,
Rx. This was
negatively
balloted on
infrastructure.
Need to
harmonize the
approach to
using
accept/rejects.
Description
issue.
34
OO &
LAPOCT
36
MnM issue.
37
References to vocabulary are largely missing,
compounding the difficulty to read the diagrams and
subsequent text.
The application focused implementation suggestion is
inappropriate for HL7 to document as part of normative
material.
Publications
38
OO, LAPOCT
39
The distinction between Packaged Medication and
Rx
40
Significant work has taken place to move V3 forward.
As the document shows, much has been put in place,
but more is necessary to make the scope implementable.
Descriptions should contain examples as use cases don't
really provide concrete examples on how things work.
They provide reasonable context on why messages must
exist in a particular area, but not how messages are
ultimately derived on.
Changes have occurred since the initial ballot issue
without substantial committee review, forcing reviewers
to work with a moving target. Extension of the review
does not adequately address this issue.
The respective RMIMs are difficult to read and
understand without comprehensive narrative to enable
the reader to map their data sets into the HL7 V3 data
set, and do that unambigously. Even if one participated
in all discussions, this is not clear.
Implementation Suggestion: If
note_txt is present, an
application should display an
indicator, and allow the user to
view the full text on request.
Implementation Suggestion: If
note_txt is present, an application
should display an indicator, and
allow the user to view the full text
on request.
Identif
ier
33
Page 98
35
ID #
Section
Vote
Type
Existing Wording
HB
3
N
Mi
Medicinal Product is not clear.
The reference to Common Clinical Domain is unclear as
it is not clear where that is documented.
HB
3.1.1
S
The description is not clear on who is doing what.
HB
3.1.1.1
N
Mi
HB
3.1.1.1.1
A
S
We need to figure out a way to tie these closer to the
story boards.
HB
All
A
S
The document structure (sequencing) does not feel
comfortable yet. It is difficult to easily jump between
trigger events, interactions, application roles, etc., and
tie it easily together to understand whether it all fits.
We recognize that there are issues with different
sequences as well. We need to be open to adjust
sequencing as we go until we settle on the most
comfortable one.
The number of trigger events and messages has been
greatly expanded by the specification of both closely
and loosely coupled versions.
This differentiation should not be specified at the trigger
event/storyboard/interaction level.
Universal use of closely vs loosely coupled CMETs will
improve this situation.
Also are there more than two states ‘closely’ and
‘loosely’ ???
The storyboard examples used by HL7 were considered
to be too simple – we found some transitions were
missing (e.g. a set of messages in prescriptions).
We suggest that consistent use of state transition
diagrams linked to storyboards and interaction cascades
would be a useful documentation and educative tool.
We will provide an example for this (e.g. a pathology
example)
Systems that are closelycoupled assume that a shared
repository of provider, patient,
protocol, and other “masterfile” type information exists
between sender and receiver.
MB
Mj
Closely vs loosely coupled
system interactions
MB
Mj
State transition diagrams &
storyboards
October 2001
O&O Minutes
Proposed Wording
Systems that are closely-coupled
assume that a shared repository
vocabulary of provider, patient,
protocol, and other “master-file”
type information exists between
sender and receiver.
Comments
We need a definition of what a "shared repository"
means. It does not have to be a physically shared
repository, but rather a virtually shared set of
vocabulary.
Page 99
Disposition
Identif
ier
OO
Common
Clinical is now
known as
Shared
Interactions.
OO, LAPOCT.
Documentation
Issue.
OO, Rx,
LAPOCT
41
Publications,
Desrciption
issue.
Publication
44
OO, Rx,
LAPOCT
46
Description
issue.
Publications
47
42
43
45
ID #
Section
Type
Existing Wording
MB
Mj
State transition diagrams &
storyboards
MB
Mi
Shared care and community
health support
MB
Mi
Clinical content
MB
Mj
Context sensitive description
of classes in an R-MIM
MB
Mj
More context-sensitive
explanatory/descriptive
information needs to be
included for every attribute
in an HMD (as is currently
the case for every field of an
HL7 2.x message).
MB
Mj
Navigation of documentation
is time-consuming and
laborious.
October 2001
O&O Minutes
Vote
Proposed Wording
Comments
Disposition
The storyboard examples used by HL7 were considered
to be too simple – we found some transitions were
missing (e.g. a set of messages in prescriptions).
We suggest that consistent use of state transition
diagrams linked to storyboards and interaction cascades
would be a useful documentation and educative tool.
We will provide an example for this (e.g. a pathology
example)
Would like to see use cases developed through to
CMETs and messages by the Community Health and
Patient Care TC We would like to see the timetable for
the inclusion of more clinical domains.
Description
issue.
Publications
Clinical referral is not represented – we would like to
see continuation of this as a joint work item for Patient
Care and Orders/ Observations TCs as begun in January
2001.
While we could come to a "theoretical" resolve on where
some data could fit using the classes available for
Pathology, we were also not completely certain that our
findings were correct.
In the Lab Filler Event Super R-MIM there are 5 classes
derived from the observation act. The usage of some of
these classes is hard to determine.
Eg ObservationEvent,
Obs_order_intent,
Observation_event_master.
A commentary explanation of the usage of each of the
classes in each R-MIM would be helpful.
Identifiers used in the HMDs are abstract.
E.g. In the HMD for the Lab Filler Event some attributes
require further description such as, ‘cd’, ‘id’ and ‘txt’.
E.g. Multiple usage (interval or discrete time) of the
attribute ‘activity_time’.
Automatic Linking from an HMD to a specification for
a referenced CMET would be helpful.
Indexing of individual CMETs would help in navigation
of the document.
Page 100
Identif
ier
48
MnM issue.
Patient Care,
Community
Health need to
answer question
about their
timetables for
content.
OO, Referrals..
Expansion in
scope.
49
MnM issue. OO
51
Publication,
MnM issue.
52
Publications
53
50
ID #
Section
Comments
Disposition
Pathology order/results
grouping (and numbering of
groups) – not well defined
Could be represented using the AR_component or
AR_fulfills
Will provide detailed storyboards
How do I relate that a single specimen and colony
count can have multiple organisms which in turn can
have multiple test results (sensitivities)
OO, LAPOCT.
Is Pathology in
our current
scope?
Mj
Multiple addresses for receipt
of pathology results
Does not handle multiple addresses.
Will provide detailed storyboards
55
MB
Q
Result copies to multiple
recipients
How do you do OBR-28 ??
MB
Q
MB
MB
Q
Q
Radiology (handling link
reports)
Allergies
Vaccination
What is the status of consultation with North American
College of Radiologists and DICOM?
It is not clear how reaction nor severity are represented.
It is not clear how this is managed.
OO, LAPOCT.
Associated with
#56. Is
Pathology in
our current
scope.
OO, LAPOCT.
Associated with
#55.
Imaging
Integration
Duplicate of #8.
Rx
MB
Q
Print supression in
microbiology report messages`
Where is this information included in a message, how is
it transmitted?
OO, LAPOCT.
Application
issue to
determine, not
an interface
standard issue.
60
Mi
Inconsistencies
Mi
*HMPO_LB_TE20011:
Supersede Complete Lab
Event, Loosely-coupled
HMPO_LB_TE20012:
Complete Lab Event, Looselycoupled
*HMPO_LB_ST20011:
Complete Lab Event, looselycoupled
HMPO_LB_ST20012:
Supersede Complete Lab
Event, loosely-coupled
Numbering of trigger events and Storyboards
inconsistent for Supercede and Complete lab events
Similar for Closely coupled equivalents
OO. Needs
research, and
will be
addressed
during general
clean up.
MB
MB
infrastructu
re
MB
MB
3.1.3.2.1
3.1.3.2.2
October 2001
O&O Minutes
Vote
Type
Existing Wording
Mj
Proposed Wording
Identif
ier
54
56
57
58
59
61
Page 101
62
ID #
Section
MB
3.1.3.2.1.1
3.1.3.2.2.1
Vote
Type
Existing Wording
Mi
Trigger Event: Activate Lab
Event, Loosely-coupled
(HMPO_LB_TE20007)
“The closest 2.x equivalent is a
result status of I … or S ...”
MB
3.1.3.2.1.2
3.1.3.2.2.2
Mi
MB
3.1.3.2.1.3
3.1.3.2.2.3
Mi
Story Board: Activate Lab
Event, loosely-coupled
(HMPO_LB_ST20007)
“This would be the equivalent
of … a result status of "I" ...”
*Trigger Event: Preliminary
Lab Event, Loosely-coupled
(HMPO_LB_TE20008)
“This would be the equivalent
of … a result status of P”
Storyboard: Preliminary Lab
Event, loosely-coupled
(HMPO_LB_ST20008)
“This would be the equivalent
of … a result status of
"A" … or "P"
Trigger Event: Revise Active
Lab Event, Loosely-coupled
(HMPO_LB_TE20009)
“This would be the equivalent
of … a result status of P”
Proposed Wording
Comments
Disposition
OO. Needs
research, and
will be
addressed
during general
clean up.
Identif
ier
63
Trigger event and Story board descriptions inconsistent
Only the P case is considered in the first instance, both
A and P are discussed in the second.
OO. Needs
research, and
will be
addressed
during general
clean up.
64
Trigger event and Story board descriptions inconsistent
Note that while only the P case is considered in the first
instance, both A and P are discussed in the second.
OO. Needs
research, and
will be
addressed
during general
clean up.
65
MnM issue
66
Storyboard: Revise Active Lab
Event, loosely-coupled
(HMPO_LB_ST20009)
“This would be the
equivalent of … a result
status of "A" … or "P" ...”
BD
General
October 2001
O&O Minutes
N
Mj
We need some type of
narrative description of the
clones. Often times I can’t fully
understand their intent just by
looking at the name of the
clone. (It may be that if I
studied the interactions and
scenarios, these clones would
make sense, but I didn’t have a
chance to study the ballot in
Page 102
ID #
Section
Vote
Type
BD
2.1
Specimen
CMET
N
Mj
BD
2.1
Specimen
CMET
2.2 Order
Options
CMET
2.3
Reagents
CMET
N
Mj
N
Mj
A
Q
BD
2.5
Supporting
Clinical
Information
CMET
N
Mj
BD
2.6
Detailed
diagnosis
CMET
A
Q
BD
BD
October 2001
O&O Minutes
Existing Wording
Proposed Wording
Comments
that much detail. Still, I think a
narrative blurb about each
clone would be useful.)
Don’t understand the purpose
of the SA_DurgInterference
clone. I imagine this means
some drug interferes somehow
with the specimen?
Don’t understand the
A_Registration clone or why
you’d register a container.
Don’t understand
O_DiluentEndoConc clone
How come there’s no little cd
attribute in MM_Reagent?
How do you know what the
reagent is?
method_cd should be CE
rather than CV. In general, all
attributes with a CWE domain
need to be CE rather than CV.
CWE domains allow local
implementations to create their
own vocabulary terms. Even
after some of these terms
become standardized,
institutions will need to
transmit their local values (in
addition to the standard
values). All CWE domains that
are of type CV should be
carefully reviewed. (The same
holds true for all R-MIMs
where this attribute is used).
neither this CMET nor the
Supporting Clinical
Information CMET use the
Act_relationship class. Does
that mean that ALL complex
diagnoses are supposed to use
the Act.value? For example, we
were recently asked guidance
on how to represent things like
“persistent neutropenic fever
despite amphotericin”,
“chronic, recurrent sinusitis
Page 103
Disposition
Identif
ier
Description
issue. LAPOCT
67
Description
issue.
LAPOCT.
Description
issue. LAPOCT
68
LAPOCT
70
OO. Bob Dolin
has a general
issue with CE's
vs. CV's. We
need to come
up with a
general answer
for this.
71
OO.
72
69
ID #
Section
Vote
Type
BD
2.6
Detailed
diagnosis
CMET
N
Mj
BD
2.9
Medicinal
Product
CMET
N
Mj
BD
3.1.1
Scenario
N
Mi
BD
3.3.1 Lab
Order
Super RMIM
N
Mj
October 2001
O&O Minutes
Existing Wording
Proposed Wording
Comments
with frontal sinus mucous
retention cyst”.
The lower cardinality of
P_responsible_parties should
be 0 instead of 1. We don’t
usually record this information
when simply filling in the
“indications” box when
submitting an order.
form_cd should be CE rather
than CV. In general, all
attributes with a CWE domain
need to be CE rather than CV.
CWE domains allow local
implementations to create their
own vocabulary terms. Even
after some of these terms
become standardized,
institutions will need to
transmit their local values (in
addition to the standard
values). All CWE domains that
are of type CV should be
carefully reviewed. (The same
holds true for all R-MIMs
where this attribute is used).
The scenario is not medically
accurate. Would not typically
order a PSA (especially STAT)
in the setting of suspected
prostatitis, as it might be
elevated due to inflammation.
A renal ultrasound looking for
the cause of a urinary tract
infection in a male wouldn’t
show the prostrate – you’d
need a rectal ultrasound, which
wouldn’t be indicated. You
need a biopsy to diagnosis
prostate cancer – not just a
PSA, sono, and DRE.
The ObservationOrder does not
have a “cd” attribute, nor does
the Observation_order_master
clone. How will the lab know
what is ordered? I’m not sure I
agree with making the lower
Page 104
Disposition
Identif
ier
O/O
73
OO. Bob Dolin
has a general
issue with CE's
vs. CV's. We
need to come
up with a
general answer
for this.
74
OO. Storyboard
narrative not
medically
accurate. In
general, the Lab
Order
storyboards did
not receive
clinical review.
75
OO &
LAPOCT
76
ID #
Section
Vote
Type
BD
3.3.1 Lab
Order
Super RMIM
N
Mj
BD
3.3.3 Lab
Event
A
Q
October 2001
O&O Minutes
Existing Wording
Proposed Wording
Comments
cardinality to AR_instantiates
be a 1. Are you sure people
ONLY order off a service
master? Can’t a simply order a
LOINC observation? I would
have thought that you need a
“cd” attribute in both the
ObservationOrder and the
Observation_order_master
clones, and the link to
AR_instantiates should not be
mandatory. Note that while we
typically DO order off a service
master, when necessary we can
order stuff that is not on the
service master – such as
special send-out tests that have
to go to the CDC or state
public health department. So I
don’t think it’s correct to
require that every orderable be
required to be drawn from the
service master. (The same
holds true for the Lab Filler
Intent Super R-MIM in 3.3.2).
priorty_cd should be CE rather
than CV. In general, all
attributes with a CWE domain
need to be CE rather than CV.
CWE domains allow local
implementations to create their
own vocabulary terms. Even
after some of these terms
become standardized,
institutions will need to
transmit their local values (in
addition to the standard
values). All CWE domains that
are of type CV should be
carefully reviewed. (The same
holds true for the Lab Filler
Intent Super R-MIM in 3.3.2
and Lab Event Super R-MIM
in 3.3.3 and for all other RMIMs).
Why does ObservationEvent.cd
show “(LOINC code)” in the
Page 105
Disposition
Identif
ier
OO. Bob Dolin
has a general
issue with CE's
vs. CV's. We
need to come
up with a
general answer
for this.
77
Descritption
issue. Need to
78
ID #
Section
Vote
Type
Super RMIM
Existing Wording
Proposed Wording
Comments
Disposition
VISIO diagram? If this is just
meant as an example, than ok.
BD
4.3.1
Pharmacy
Order RMIM
A
Q
SR
Practice &
Observatio
ns
N
S
SR
Practice &
Observatio
ns
3
N
Mj
LM
General
N
Ma
LM
General
N
LM
General
LM
LM
add e.g. to front
of LOINC to
make t clear it's
an example.
Rx
Why is the cardinality to
P_subject 1 to many rather
than just 1 to 1? Wouldn’t you
need to specify a distinct order
for each subject?
Identif
ier
79
For those portions of the document that were reviewed,
the general consensus within Kaiser was that additional
editing would be useful to improve the understandability
of the document. At this time, we have only one
specific example to offer, but we are willing to work
with the editors and submit suggestions and additional
storyboards as they can be defined.
While Observation.interpretation_cd is of data type
SET<CS>, the domain is
ObservationInterpretation(CWE). But
the description of CS states " the designation of the
domain qualifier will always be CNE." This appears to
be a conflict within the standard.
We need to incorporate the pharmacy storyboards
that were submitted into the ballot framework.
OO, LAPOCT,
Rx.
80
OO, LAPOCT
81
Rx
82
Ma
We need substantially stronger descriptions
83
N
Ma
General
N
Ma
Rx
85
General
N
Ma
We need a way to handle the identification of
contraindications associated with a particular order, as
well as an optional indication of the management
actions taken.
We need a means to request an event. For example:
Physician sends request to community pharmacy to
dispense against an existing order.
We need to do substantial work on vocabulary,
particularly the various Act.cd domains.
We need to align our use of Accept vs. Notify messages
with the approach of Lab. (I believe both have the same
trigger event, and message type, but will have different
message wrappers and different receiving roles.)
Description
issue.
Rx
OO, LAPOCT,
Rx, Vocab.
Duplicate of
#34.
86
LM
October 2001
O&O Minutes
3.1.3 Parent category: Lab
Event (HMPO_LB_IC20001)
Page 106
84
87
DM – David Markwell
AK - Austin Kreisler
DY - Daphne Young
HB - Hans Buitendijk
MB - Maree Bellamy
BD - Bob Dolin
SR - Scott Robertson
LM - Lloyd McKenzie
October 2001
O&O Minutes
Page 107