Scope: What include and exclude in 3
January 2002 Minutes
Orders/Observations Worksession
Table of Contents
Table of Contents 1
Attendees 3
Monday - Version 2.x Review 4
Proposal 240 – Clarify Reference Range Type 4
Proposal 245 – CM Data Type Replacement for OO – Part A 6
Proposal 214 – CM Data Type Replacement for OO – Part B 19
Proposal 241 – Move Message Constituent Definitions 30
Proposal 180 – Segment Grouping 32
Proposal 198 Resolving the ambiguity of SAC segment occurrence in the OML and ORL messages 33
Proposal 249 – Specimen Segment 36
Proposal 190 65
Proposal – Blood Bank 66
Tuesday through Thursday - V3 86
Thursday PM – Joint with Clinical Trials SIG 87
Friday 88
Proposal 214/245 88
Proposal 241 – 88
Proposal 181 – 89
Proposal 190 – Inventory Master File for Chapter 8 92
Proposal 189 – Inventory Master File Amendment 98
Proposal 246 – 99
Proposal 248 – Add film handling to OBR and IPC 107
Proposal - Point-of-Care Observation messages for Version 2.x for Laboratory and Point-of-Care Domains 109
Proposal – Specimen 113
Proposal 249 – Specimen Segment Proposal 113
Chapter 13 changes relative to SPM 113
Attachment A: Introduction 115
Attachment B: Pharmacy Domain Introduction 116
Attachment C: Pharmacy DMIM Narratives 117
Pharmacy Substance Administration Order Focal Class 117
Pharmacy Substance Administration Intent Focal Class 120
Pharmacy Substance Administration Focal Class 123
Pharmacy Supply Order Focal Class 125
Pharmacy Supply Event Focal Class 126
Pharmacy Supply Intent Focal Class 128
Attachment D: Pharmacy Storyboards 131
Change Order – 24 131
Dispense Event Activate – 6 131
Dispense Event Complete – 132
Inpatient Pharmacy Story: Using the pharmacy system for clinical monitoring 133
Inpatient Pharmacy Story: patient is discharged from the hospital and transferred to the OP IV Infusion Program 133
A simple story: An outpatient prescription that is filled only one time and is then complete. 133
A little more complicated story: An outpatient prescription that is filled multiple times. 134
Newborn 135
Community Prescription for UK order 135
Inpatient Order Request 135
Inpatient Order Status Change Request 135
Inpatient Order Status Change Request 136
Inpatient Order Status Change Request 136
Inpatient Order Status Change Request 136
Inpatient Order Status Change Request 137
Inpatient Order Status Change Request 137
Inpatient Order Activate order request through pharmacy verification 137
Inpatient verified Order revision request 138
Inpatient verified Order revision accept 138
Community Pharmacy - Prescription nullified 138
Community Pharmacy - Prescription aborted 138
Inpatient Pharmacy - Dispensing—supply requested 138
Inpatient Pharmacy - Dispensing—supply fulfilled 139
Inpatient Pharmacy - Dispensing—supply refused 139
Inpatient Pharmacy - Dispensing—supply Obsolete/New and Revised 139
Inpatient Pharmacy - Dispensing—supply suspended 140
Inpatient Pharmacy - Dispensing—supply resumed 140
Inpatient Pharmacy - Dispensing—supply abort 140
Community Pharmacy - Prescription nullified 140
Community Pharmacy - Prescription aborted 141
Inpatient Pharmacy - Dispensing—supply requested 141
Inpatient Pharmacy - Dispensing—supply fulfilled 141
Inpatient Pharmacy - Dispensing—supply refused 141
Inpatient Pharmacy - Dispensing—supply Obsolete/New and Revised 141
Inpatient Pharmacy - Dispensing—supply suspended 142
Inpatient Pharmacy - Dispensing—supply resumed 142
Inpatient Pharmacy - Dispensing—supply abort 143
Community Pharmacy order with state changes to completion 143
Scenario #1 144
Scenario #2 146
Scenario #3 147
Various Other Storyboards 148
Attachment E: Lab Storyboards 155
Simple Lab Order with Results, Closely Coupled Systems 155
Bone Marrow Biopsy 157
Automated Microbiology Reflex tests, loosely/closely coupled 159
Laboratory Automation with closely-coupled order/results 162
Food Safety Outbreak Investigation 165
General Laboratory with Reflex Order 167
General Laboratory with Frequency, Interrupted and Resumed 169
Attendees
|Attendee |Company/E-Mail |Mon AM |Mon PM |Tue AM |
|CCD |BLG-1 – When to charge | ^ |4.5.2.1 | |
|Charge code & date| | | | |
|EIP |OBR-29 – Parent Number | ^ | | |
|pair | | | | |
|EIP |ORC-8 – Parent | ^ | | |
|MOC |OBR-23 – Charge to Practice| ^ |4.5.3.23 / 7.4.1.23 | |
|Money & charge | | | | |
|code | | | | |
|NDL |OBR-32 – Principle Result | ^ ^ ^ ^ | |data type “CN” that cannot be|
| | | ^ ^ ^ | |fully expressed. Historical |
| | | ^ ^ ^ | | |
|NDL |OBR-33 – Assistant Result | ^ ^ ^ ^ | |subcomponent model given for |
| | | ^ ^ ^ | |CN. |
| | | ^ ^ ^ | |data type “CN” that cannot be|
| | | | |fully expressed. Historical |
| | | | |CN restored as CNH. |
|NDL |OBR-34 – Technician | ^ ^ ^ ^ | |subcomponent model given for |
| | | ^ ^ ^ | |CN. |
| | | ^ ^ ^ | |data type “CN” that cannot be|
| | | | |fully expressed. Historical |
| | | | |CN restored as CNH. |
|NDL |OBR-35 –Transcriptionist | ^ ^ ^ ^ | |subcomponent model given for |
| | | ^ ^ ^ | |CN. |
| | | ^ ^ ^ | |data type “CN” that cannot be|
| | | | |fully expressed. Historical |
| | | | |CN restored as CNH. |
|PRL |OBR-26 – Parent Result | ^ ^ | | |
|OSD |OBR-27.10– Order Sequencing| & & < Placer |7.4.1.27.10 |comp 10, defined 4.3.10. |
| | |Order Number: Namespace ID (IS)> & < Filler | |Errata identified: 3 |
| | |Order Number: Entity Identifier (ST)> & < | |subcomponents (1, 6 and 7) |
| | |Filler Order Number: Namespace ID (IS)> & < | |have missing data types. |
| | |Sequence Condition Value (ST)>& < Maximum | |These have now been |
| | |Number of Repeats (NM)> & < Placer Order | |corrected. |
| | |Number: Universal ID (ST)> & < Placer Order | | |
| | |Number: Universal ID Type (ID)> & < Filler | | |
| | |Order Number: Universal ID (ST)> & < Filler | | |
| | |Order Number: Universal ID Type (ID)> | | |
|OSD |ORC-7.10– Order Sequencing | & & < Placer | |comp 10, defined 4.3.10. |
| | |Order Number: Namespace ID (IS)> & < Filler | |Erratum identified: 3 |
| | |Order Number: Entity Identifier (ST)> & < | |subcomponents (1, 6 and 7) |
| | |Filler Order Number: Namespace ID (IS)> & < | |have missing data types. |
| | |Sequence Condition Value (ST)>& < Maximum | |These have now been |
| | |Number of Repeats (NM)> & < Placer Order | |corrected. |
| | |Number: Universal ID (ST)> & < Placer Order | | |
| | |Number: Universal ID Type (ID)> & < Filler | | |
| | |Order Number: Universal ID (ST)> & < Filler | | |
| | |Order Number: Universal ID Type (ID)> | | |
|OSD |RXE-1.10– Order Sequencing | & & < Placer | |comp 10, defined 4.3.10. |
| | |Order Number: Namespace ID (IS)> & < Filler | |Erratum identified: 3 |
| | |Order Number: Entity Identifier (ST)> & < | |subcomponents (1, 6 and 7) |
| | |Filler Order Number: Namespace ID (IS)> & < | |have missing data types. |
| | |Sequence Condition Value (ST)>& < Maximum | |These have now been |
| | |Number of Repeats (NM)> & < Placer Order | |corrected. |
| | |Number: Universal ID (ST)> & < Placer Order | | |
| | |Number: Universal ID Type (ID)> & < Filler | | |
| | |Order Number: Universal ID (ST)> & < Filler | | |
| | |Order Number: Universal ID Type (ID)> | | |
CCD- charge code and date
Components: ^
HL7 Component Table - CCD – charge code and date
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |26 |TS |O | |Date/time | | |
Definition: This field specifies when to charge for the ordered service. Specifies whether a charge action is based on an invocation event or is time-based.
Issue: Sentiment was expressed in an OO subcommittee meeting that charge information be moved to chapter 6. This would include the entire BLG segment.
Maximum Length: 28
Note: Replaces the CM data type used in section 4.5.2.1 BLG-1, as of version 2.5.
When to charge code (ID)
Definition: Specifies the code for the event precipitating/triggering the charge activity. Refer to HL7 Table 0100 – Invocation Event for valid values.
HL7 Table 0100 - When to charge Invocation 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.
Issue: Do we want to remove the constraint that this is related to charge activity? We already have ways to communicate when a service is ordered, when it should be/was performed and when it was recorded. Are there other events this would be used for other than charge activity?
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.
Resolution
We accepted the proposal with 14 for, 0 against, and 3 abstain.
EIP- entity identifier pair
Components:
Subcomponents of parent’s placer order number: & & &
Subcomponents of parent’s filler order number: & & &
HL7 Component Table - EIP – entity identifier pair
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 | |EI | | |Filler Assigned Identifier | | |
Definition: Specifies an identifier assigned to an entity by either the placer or the filler system. If both components are populated the identifiers must refer to the same entity.
Maximum Length: 267
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.
Placer Assigned Identifier (EI)
Definition: Specifies an identifier assigned to an entity by the placer system.
For example, the component might be used to convey the following:
a) placer order number of the parent order
b) the specimen identifier as assigned by the placer.
c) A location identifier assigned (or used by) the placer.
Filler Assigned Identifier (EI)
Definition: Specifies an identifier assigned to an entity by the filler system.
For example, the component might convey the following:
a) filler order number of the parent order
b) the specimen identifier as assigned by the filler.
c) A location identifier assigned (or used by) the filler.
Resolution
After incorporating minor changes as documented above (clarified that the use of the data type within a particular field can lead to specific restrictions, e.g., uniqueness) we accepted the proposal with 13 for, 0 against, and 4 abstain.
MOC- money and charge code
Components: ^
Subcomponents of monetary amount: &
Subcomponents of charge code: & & & & &
HL7 Component Table - MOC – Money and code
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |250 |CE |O | |Charge code | | |
Definition: This field is data type contains/specifies the charge to the ordering entity for the studies performed when applicable. Transmits monetary information and the associated charge code for services performed.
Maximum Length: 267
Note: 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.
Dollar Monetary Amount (MO)
Definition: The first component is a dollar amount when known by the filler.b The amount and denomination of money associated with the charge code.
Charge code (CE)
Definition: The second is a charge code when known by the filler (results only). The code identifying the charge to the ordering entity for the services performed. when applicable.
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.
Editor’s note: Does anyone know what the intention is? Seems safest to declare a new user-defined table. Might also allow use of table 0132 as noted above.
OO subcommittee response 01/02/02: Refer issue to PAFM. OO does not know if this is context sensitive or if existing table 0132 could be used.
Resolution
After incorporating minor changes as documented above (change the name of the first component in MOC from dollar amount to monetary amount), we accepted the proposal 14 for, 0 against, and 3 abstain.
NDL – name with date and location
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & &
Subcomponents of facility: & &
HL7 Component Table - NDL – name with date and location
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |26 |TS |O | |Start date/time | | |
|3 |26 |TS |O | |End date/time | | |
|4 |20 |IS |O |302 |Point of care | | |
|5 |20 |IS |O |303 |Room | | |
|6 |20 |IS |O |304 |Bed | | |
|7 | |HD |O |362 |Facility | | |
|8 |20 |IS |O |306 |Location status | | |
|9 |20 |IS |O |305 |Patient location type | | |
|10 |20 |IS |O |307 |Building | | |
|11 |20 |IS |O |308 |Floor | | |
Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service.
Maximum Length: 267
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 - ( OBR-33) 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.
Suggested Solution:
The components below are the current components in the current order.
Name (CNS)
Definition: Name of person performing a service.
Start date/time (TS)
Definition: The starting date and time for when the person is performing the service.
End date/time (TS)
Definition: The ending date and time for when the person is performing the service.
Point of Care (IS)
Definition: Conditional on location type (e.g., nursing unit or department or clinic). After floor, most general patient location designation. User-defined Table 0302 - Point of care is used as the HL7 identifier for the user-defined table of values for this component.
Room (IS)
Definition: Patient room. After point of care, most general location designation. User-defined Table 0303 - Room is used as the HL7 identifier for the user-defined table of values for this component.
Bed (IS)
Definition: Patient bed. After room, most general location designation. User-defined Table 0304 - Bed is used as the HL7 identifier for the user-defined table of values for this component.
Facility (HD)
Subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. Most general location designation.
Location Status (IS)
Definition: Location (e.g., Bed) status. User-defined Table 0306 - Location status is used as the HL7 identifier for the user-defined table of values for this component.
Location Type (IS)
Definition: Location type is the categorization of the location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. Usually includes values such as nursing unit, department, clinic, SNF, physician’s office. User-defined Table 0305 - Person location type is used as the HL7 identifier for the user-defined table of values for this component.
Building (IS)
After facility, most general location designation. User-defined Table 0307 - Building is used as the HL7 identifier for the user-defined table of values for this component.
Floor (IS)
After building, most general location designation. User-defined Table 0308 - Floor is used as the HL7 identifier for the user-defined table of values for this component.
Location description (ST)
Definition: An unstructured textual description of the location used to support or substitute for the structured location information.
Resolution
We agreed to remove a proposal to add a Comprehensive Identifier and a XCN flattened list. This may be revisited on Friday if argument can be made to reconsider.
We accepted a modification to rename CNH (composite name historical) to CNS (composite name simple) to indicate that the name structure is a simplified version of name and does not support the complex name structure with 15 for, 0 against, and 2 abstain. Action: Scott to take to CQ and Joann
We accepted a suggestion to add Location Description with 14 for, 0 against, and 2 abstain.
An issue was raised that we require the definition and data types for the components of the CNS prior to making a decision on this data type. Concern that the CNS will not support international requirements introduced in the XCN.
Note: description from 2.2 CN. All components are ST data type. A field identifying a person both as a coded value and with a text name. The first component is the coded ID according to a site-specific table. The second through the seventh components are the person's name as a PN field. The eighth component specifies the source table used for the first component. For specific fields, individual sites may elect to omit the ID or the name.
We agreed to change R to O and make all components optional. Let the field that uses the data type drive optionality of specific components.
We pushed the discussion on extending XCN to Friday if somebody has compelling case for one or more components 9 thru 18. Key issue is internationalization of the family name and maintaining backwards compatibility.
We accepted a decision to defer resolution on the NDL data type until Friday when a full review of the CNS can be included. In the interim, we will ask CQ to address the internationalization requirements in the CNS with 14 for, 0 against, and 3 abstain.
PRL- parent result link
Components: ^ ^
Subcomponents of OBX-3-observation identifier of parent result: & & & & &
HL7 Component Table - PRL – Parent result link
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 | |ST | | |OBX-4-sub-ID of parent result Parent |defined in the OBX-4| |
| | | | | |Observation Sub-identifier |of the parent | |
| | | | | | |result. | |
|3 | |TX | | |Part of OBX-5 observation result from |Taken from the OBX-5| |
| | | | | |parent Parent Observation Value Descriptor|of the parent | |
| | | | | | |result. | |
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.
We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by OBR-29-parent and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.)
A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.
Definition: Uniquely identifies the parent result’s OBX segment related to the current order, together with the information in OBR-29-parent.
Usage Note: This data type is applied only to OBR-26 – Parent Result where it serves to make information 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.
We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by OBR-29-parent and the parent spawns child orders for each of many results. (See Chapter 7 for more details about this linkage.)
A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.
Maximum Length: ??
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.
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.
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.
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.
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.
Editor’s note: Field notes have been restored. Looks like it still needs some smoothing out.
Response from OO subcommittee on 01/02/02: Time did not permit adequate discussion. This needs to be looked at by Lab Auto in San Diego next week.
Resolution
We accepted the proposal with 14 for, 0 against, and 1 abstain.
OSD - order sequence definition
components: ^ ^ ^ ^ ^ ^ < Maximum Number of Repeats (NM)> ^ ^ ^ ^
HL7 Component Table - OSD – order sequence definition
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |15 |ST |R | |Placer Order Number: Entity Identifier | | |
|3 |6 |IS |O |0363 |Placer Order Number: Namespace ID | | |
|4 |15 |ST |R | |Filler Order Number: Entity Identifier | | |
|5 |6 |IS |O |0363 |Filler Order Number: Namespace ID | | |
|6 |12 |ST |O | |Sequence Condition Value | | |
|7 |3 |NM |O | |Maximum Number of Repeats | | |
|8 |15 |ST |R | |Placer Order Number: Universal ID | | |
|9 |6 |ID |O |0301 |Placer Order Number: Universal ID Type | | |
|10 |15 |ST |R | |Filler Order Number: Universal ID | | |
|11 |6 |ID |O |0301 |Filler Order Number: Universal ID Type | | |
Decision: Editor to reconcile lengths of components 2-5 and 8-11 to match with EI in chapter 2.
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 (especially as it is applied to the ORC-7?). Retained for backwards compatibility only as of v 2.5. The reader is advised to consider the TQ1 and TQ2 segments rather than this data type if sequencing levels or cyclical patterns need to be transmitted.
Maximum Length: 864?
Note: Replaces the CM data type used in the TQ data type, component 10, as of version 2.5.
Issue: Can we strike most of the following introductory narrative since the TQ is being deprecated? No, required to support 2.4 considerations.
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.
Editor’s note: If the following 3 paragraphs are to be retained it seems like they should be under the “Usage Notes”, perhaps new point “a”, point “b” would then address “cyclical patterns”. This approach would appear to be consistent with the definition above. The current point “b” “Inheritance of order status “ does not appear to be a parallel concept with Sequencing and Cyclical Patterns.
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:
• 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.
• 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.
Editor’s Note: The following paragraphs regarding order status should be deleted from the OSD data type definition. The data type does not include any order status component. Does this discussion belong in the field notes for ORC-5 – Order Status? No – retain with OSD definitions.
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:
• 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.
b) 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).
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 |
Placer Order Number: Entity Identifier (ST)
Definition: Required component that cContains the first component of the placer order number, entity identifier .
Placer Order Number: Namespace ID (IS)
Definition: Optional component that cContains the second component of the placer order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority for suggested values.
Filler Order Number: Entity Identifier (ST)
Definition: Required component that cContains the first component of the filler order number, entity identifier .
Filler Order Number: Namespace ID (IS)>
Definition: Optional component that cContains the second component of the filler order number, namespace ID. Refer to user-defined table 0363 - Assigning Authority
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 : +/-
Motion: (Helen/Harry) Editor to ensure that the field note is the same as the 2.4 field note for this component. (abstain 6, for 13)
| |
| |
|The first letter stands for start (S) or end (E) of predecessor order, where the |
|predecessor is defined by the placer or filler order number in subcomponents 1,2 or |
|subcomponents 3,4. |
|The second letter stands for the start (S) or end (E) of the successor order, where the|
|successor order is the order containing this quantity/timing specification. |
|The time specifies the interval between the predecessor and successor starts or ends |
|(see following examples). |
|Where is defined as: |
|S do for seconds |
|M do for minutes |
|H do for hours |
|D do for days |
|W do for weeks |
|L do for months |
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.
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.
Placer Order Number: Universal ID (ST)>
Definition: Required component that cContains the next to the last component of the placer order number, universal ID
Placer Order Number: Universal ID Type(ID)>
Definition: Optional component that cContains the last component of the placer order number. Refer to HL7 table 0301 - Universal ID Type for valid values.
Filler Order Number: Universal ID (ST)>
Definition: Required component that cContains the next to the last component of the filler order number, universal ID .
Filler Order Number: Universal ID Type(ID)>
Definition: Optional component that cContains the last component of the placer order number. Refer to HL7 table 0301 - Universal ID Type for valid values.
Resolution
We accepted to proposal with 10 for, 0 against, and 9 abstain.
Proposal 214 – CM Data Type Replacement for OO – Part B
Short Description:
Continue to define new data types to replace existing CM data types.
Justification:
Replaces proposal # 172. Continuation of proposal # 155 and 213.
Apply new data types as follows:
|Data Type |Segment Field |Component Model |Section |Comment |
| | | |Reference | |
|LA1 |RXE-8 – Deliver-to Location| ^ ^ ^ ^ ^ ^ | | |
| | | ^ ^ | | |
|LA1 |RXO-8 – Deliver-to Location| ^ ^ ^ ^ ^ ^ | | |
| | | ^ ^ | | |
|LA2 |RXA-11 – Administered-at | ^ ^ ^ ^ ^ ^ | | |
| | | ^ ^ ^ ^ | | |
| | | ^ ^ | | |
| | | ^ ^ | | |
| | | ^ | | |
|LA2 |RXD-13 – Dispense-to | ^ ^ ^ ^ ^ ^ | | |
| | | ^ ^ ^ ^ | | |
| | | ^ ^ | | |
| | | ^ ^ | | |
| | | ^ | | |
|LA2 |RXG-11 – Dispense-To | ^ ^ ^ ^ ^ ^ | | |
| | | ^ ^ ^ ^ | | |
| | | ^ ^ | | |
| | | ^ ^ | | |
| | | ^ | | |
|WVI |OBX-5.1 - Channel | & |7.14.1.3.1 |Where OBX.5 - Observation |
| |identifier | | |value (*) is data type |
| | | | |"CD". |
|WVS |OBX-5.2- waveform source | & |7.14.1.4 |Where OBX.5 - Observation |
| | | | |value (*) is data type |
| | | | |"CD". |
|CCP |OBX-5.4 - channel |< channel calibration sensitivity correction |7.14.1.6 |Where OBX.5 - Observation |
| |calibration parameters |factor (NM)> & < channel calibration baseline| |value (*) is data type |
| | |(NM)> & < channel calibration time skew (NM)>| |"CD". |
|CSU |OBX-5.3 - channel | & < unit of |7.14.1.5 |Where OBX.5 - Observation |
| |sensitivity and units |measure identifier (ST)> & < unit of Measure | |value (*) is data type |
| | |Description (ST)> & < unit of Measure Coding | |"CD". |
| | |System (IS)> & & & | | |
|PLN |CTD-7 – Contact Identifiers| ^ ^|11.6.4.7 |New 4th component added to be|
| | | ^ | |consistent with PRA-6 |
| | | | | |
|PLN |PRD-7 – Provider | ^ ^|11.6.3.7 |New 4th component added to be|
| |Identifiers | ^ | |consistent with PRA-6 |
| | | | | |
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. |
|2 |20 |IS |O |303 |Room | |2.9.29.2 |
|3 |20 |IS |O |304 |Bed | |2.9.29.3 |
|4 | |HD |O | |Facility | |2.9.29.4 |
|5 |20 |IS |O |306 |Location Status | |2.9.29.5 |
|6 |20 |IS |O |305 |Patient Location Type | |2.9.29.6 |
|7 |20 |IS |O |307 |Building | |2.9.29.7 |
|8 |20 |IS |O |308 |Floor | |2.9.29.8 |
|9 | |AD |O | |Address | |2.9.29.9 |
Definition: Specifies a location and its address. This data type is maintained for backward compatibility only for use in the fields where the CM data type was used. This data type will not be applied to any new fields post version 2.5.
Maximum Length: ??
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.
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.
Point of Care (IS)
Definition: Conditional on person location type (e.g., nursing unit or department or clinic). After floor, most general patient location designation. User-defined Table 0302 - Point of care is used as the HL7 identifier for the user-defined table of values for this component.
Room (IS)
Definition: Patient room. After point of care, most general person location designation. User-defined Table 0303 - Room is used as the HL7 identifier for the user-defined table of values for this component.
Bed (IS)
Definition: Patient bed. After room, most general person location designation. User-defined Table 0304 - Bed is used as the HL7 identifier for the user-defined table of values for this component.
Facility (HD)
Subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. Most general person location designation.
Location Status (IS)
Definition: Location (e.g., Bed) status. User-defined Table 0306 - Location status is used as the HL7 identifier for the user-defined table of values for this component.
Patient Location Type (IS)
Definition: Person location type is the categorization of the person’s location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. Usually includes values such as nursing unit, department, clinic, SNF, physician’s office. User-defined Table 0305 - Person location type is used as the HL7 identifier for the user-defined table of values for this component.
Building (IS)
After facility, most general person location designation. User-defined Table 0307 - Building is used as the HL7 identifier for the user-defined table of values for this component.
Floor (IS)
After building, most general person location designation. User-defined Table 0308 - Floor is used as the HL7 identifier for the user-defined table of values for this component.
Location description (ST)
A free text description of the location.
Address (AD)
Definition: (Not defined in AD data type)
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.
Resolution
We accepted a proposal for O/O to request that CQ add a definition for AD to chapter 2 and clarify that AD is not deprecated but may only be used as a component of another data type where a flat address is required and XAD cannot be used with 19 for, 0 against and 0 abstain. Action: Scott to give to Joann to do.
We accepted the proposal with the addition of a clarification not to use this data type with new fields with 19 for, 0 against, and 0 abstain.
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. |
|2 |20 |IS |O |303 |Room | |2.9.29.2 |
|3 |20 |IS |O |304 |Bed | |2.9.29.3 |
|4 | |HD |O | |Facility | |2.9.29.4 |
|5 |20 |IS |O |306 |Location Status | |2.9.29.5 |
|6 |20 |IS |O |305 |Patient Location Type | |2.9.29.6 |
|7 |20 |IS |O |307 |Building | |2.9.29.7 |
|8 |20 |IS |O |308 |Floor | |2.9.29.8 |
|9 | |ST |O | |Street Address | |2.9.1.1 |
|10 | |ST |O | |Other Designation | |2.9.1.2 |
|11 | |ST |O | |City | |2.9.1.3 |
|12 | |ST |O | |State or Province | |2.9.1.4 |
|13 | |ST |O | |Zip or Postal Code | |2.9.1.5 |
|14 |3 |ID |O |399 |Country | |2.9.1.6 |
|15 | |ID |O |190 |Address Type | |2.9.1.7 |
|16 | |ST |O | |Other Geographic Designation | | |
Definition: Specifies a location and its address. This data type is maintained for backward compatibility only for use in the fields where the CM data type was used. This data type will not be applied to any new fields.
Maximum Length: ??
Note: 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 2.5.
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
Point of Care (IS)
Definition: Conditional on person location type (e.g., nursing unit or department or clinic). After floor, most general patient location designation. User-defined Table 0302 - Point of care is used as the HL7 identifier for the user-defined table of values for this component.
Room (IS)
Definition: Patient room. After point of care, most general person location designation. User-defined Table 0303 - Room is used as the HL7 identifier for the user-defined table of values for this component.
Bed (IS)
Definition: Patient bed. After room, most general person location designation. User-defined Table 0304 - Bed is used as the HL7 identifier for the user-defined table of values for this component.
Facility (HD)
Definition: Subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. Most general person location designation.
Location Status (IS)
Definition: Location (e.g., Bed) status. User-defined Table 0306 - Location status is used as the HL7 identifier for the user-defined table of values for this component.
Patient Location Type (IS)
Definition: Person location type is the categorization of the person’s location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. Usually includes values such as nursing unit, department, clinic, SNF, physician’s office. User-defined Table 0305 - Person location type is used as the HL7 identifier for the user-defined table of values for this component.
Building (IS)
Definition: After facility, most general person location designation. User-defined Table 0307 - Building is used as the HL7 identifier for the user-defined table of values for this component.
Floor (IS)
Definition: After building, most general person location designation. User-defined Table 0308 - Floor is used as the HL7 identifier for the user-defined table of values for this component.
Street Address (ST)
Definition: The street or mailing address of a person or institution. When referencing an institution, this first component is used to specify the institution name. When used in connection with a person, this component specifies the first line of the address.
Other designation (ST)
Definition: Second line of address. In general, it qualifies address. Examples: Suite 555 or Fourth Floor. When referencing an institution, this component specifies the street address.
City (ST)
Definition: ??? Editor to insert.
State or province (ST)
Definition: State or province should be represented by the official postal service codes for that country.
Zip or postal code (ST)
Definition: Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9.
Country (ID)
Definition: Defines the country of the address. ISO 3166 provides a list of country codes that may be used.[1] This ISO table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code. Refer to HL7 Table 0399 – Country code for valid values.
Address type (ID)
Definition: Type is optional and defined by HL7 Table 0190 - Address type.
Other geographic designation (ST)
Definition: Other geographic designation includes county, bioregion, SMSA, etc.
Resolution
We accepted the proposal with the addition of a clarification that this data type not be used for new fields with 19 for, 0 against, and 0 abstain.
WVI - channel identifier
HL7 Component Table – Channel Identifier
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |17 |ST |O | |Channel Name | | |
Definition: This data type specifies the number and name of the recording channel where waveform data is transmitted.
Maximum Length: ??
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.
Channel number (NM)
Definition: This component specifies the number of the recording channel.
Channel name (ST)
Definition: This component specifies the name of the recording channel.
Resolution
We accepted the proposal with 16 for, 0 against, and 3 abstain.
WVS - waveform source
HL7 Component Table – Waveform Source
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |20 |ST |O | |Source two Name | | |
Definition: This data type identifies the source of the waveform connected to a channel.
Maximum Length: ??
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.
Source one name (ST)
Definition: This component identifies the first input for the waveform source.
Source two name (ST)
Definition: This component identifies the second input for the waveform source if a differential input is used.
Resolution
We accepted the proposal with 12 for, 0 against, and 7 abstain.
CSU - channel sensitivity
HL7 Component Table – Channel Sensitivity
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |TBD |ST |C | |Unit of Measure Identifier | | |
|3 |TBD |ST |C | |Unit of Measure Description | | |
|4 | |ID |C |396 |Unit of Measure Coding System | | |
|5 |TBD |ST |O | |Alternate Unit of Measure Identifier | | |
|6 |TBD |ST |O | |Alternate Unit of Measure Description | | |
|7 | |ID |O |396 |Alternate Unit of Measure Coding System | | |
Definition: This data type defines the channel sensitivity (gain) and the units in which it is measured in a waveform result.
Editor to insert lengths from the CE definitions.
Maximum Length: ??
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.
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.
Unit of measure identifier (ST)
Definition: The unit designation for the channel sensitivity. This field is required if the unit of measure description is not present.
Unit of measure description (ST)
Definition: The full text name of the unit of measure identifier. This field is required if the unit of measure identifier is not present.
Unit of measure coding system (ID)
Definition: Specifies the coding system for the unit of measure. This field is required if the unit of measure identifier is present.
Alternate unit of measure identifier (ST)
Definition: An alternate units designation for the channel sensitivity.
Alternate unit of measure description (ST)
Definition: The full text name of the alternate unit of measure identifier.
Alternate unit of measure coding system (ID)
Definition: Specifies the coding system for the alternate unit of measure.
Resolution
We accepted the proposal with 13 for, 0 against, and 6 abstain.
CCP - channel calibration parameters VOTE: abstain 7, for 12
HL7 Component Table – Channel Calibration Parameters
|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |20 |NM |O | |Channel Calibration Baseline | | |
|3 |20 |NM |O | |Channel Calibration Time Skew | | |
Definition: This data type identifies the corrections to channel sensitivity, the baseline, and the channel time skew when transmitting waveform results.
Maximum Length: 62
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.
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.
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.
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).
Resolution
We accepted the proposal with 12 for, 0 against and 7 abstain.
PLN – practitioner license or other ID number
Components: ^ ^ ^
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 |TBL# |COMPONENT NAME |COMMENTS |SEC.REF. |
|2 |8 |IS |R |0338 |Type of ID number | | |
|3 |62 |ST |O | |State/other qualifying info | | |
|4 |8 |DT |O | |Expiration date | | |
Definition: This data type specifies a practitioner’s license number, or other ID number such as UPIN, Medicare and Medicaid number, and associated detail.
Maximum Length: 101
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 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.
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
ID number (ST)
Definition: Specifies the license number or other ID number such as UPIN, Medicare and Medicaid number.
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 |Description |
|CY |County number |
|DEA |Drug Enforcement Agency no. |
|GL |General ledger number |
|L&I |Labor and industries number |
|MCD |Medicaid number |
|MCR |Medicare number |
|QA |QA number |
|SL |State license number |
|TAX |Tax ID number |
|TRL |Training license number |
|UPIN |Unique physician ID no. |
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.
Expiration date (DT)
Definition: Specifies the date when the license or ID is no longer valid..
Resolution
We discussed two options:
Option 1 – deprecate PRD-7 and CDT-7 and create new fields using CX data type (CX has different structure, but same components and more).
Option 2 – apply the PLN data type (as documented here) to the PRD-7 and CDT-7 fields essentially adding the Expiration Date to these fields.
We accepted a motion for Option 2 with modifications to PLN as documented by Friday as it will cause minimal disruption to existing implementations with 19 for, 0 against, and 0 abstain. Action: Scott & Martin to write proposal including cleanup of chapter 11 and bring to OO on Friday. Proposal will include clarification of licensing and identifiers.
Proposal 241 – Move Message Constituent Definitions
Short Description:
Remove message constituent definitions from chapter 7.
Justification:
Chapter 7, section 7.2.2, contains definitions for “Segment”, “Field”, “Repeated Value” and “Field Components”. Chapter 2 also defines these concepts, but in slightly defferent language. It would be better if the definitions appeared in only 1 place, preferably chapter 2.
Solution:
Move content (yellow highlight) from chapter 7 to chapter 2 as follows:
Message Definition
Segments
A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the ADT message may contain the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1).
Each segment is identified by a unique three-character code known as the Segment ID. Although the actual segments are defined in various chapters, the ID codes assigned to the various segments are listed in Appendix A.
All segment ID codes beginning with the letter Z are reserved for locally-defined messages. No such codes will be defined within the HL7 Standard.
A typed aggregate of fields (fields) describing one complete aspect of a message. For example, the information about one order is sent as type of segment (OBR), the information related to an observation is sent as another segment (OBX).
The segment in a message is analogous to a record in a database, and in previous versions of the Standard we used record in place of the word segment. We have changed the nomenclature to be consistent with HL7 and other standards organizations in this version.
Fields
Definition: A field is a string of characters.
One specific attribute of a segment, for example, patient diagnosis, which may contain aggregates of fields further refining the basic attribute.
A field entry may also have discernible parts or components. For example, the patient’s name is recorded as last name, first name, and middle initial, each of which is a distinct entity separated by a component delimiter (sub-subfield in ASTM E1238-94).
Some fields may contain many repeat fields. For example, the diagnoses field may contain many different diagnoses.
HL7 does not care how systems actually store data within an application. When fields are transmitted, they are sent as character strings. Except where noted, HL7 data fields may take on the null value. Sending the null value, which is transmitted as two double quote marks (“”), is different from omitting an optional data field. The difference appears when the contents of a message will be used to update a record in a database rather than create a new one. If no value is sent, (i.e., it is omitted) the old value should remain unchanged. If the null value is sent, the old value should be changed to null. (For further details, see Section Error! Reference source not found., “Error! Reference source not found.,” - step 2d.)
The various chapters of the Standard contain segment attribute tables. These tables list and describe the data fields in the segment and characteristics of their usage. A comprehensive data dictionary of all HL7 fields is provided in Appendix A. In defining a segment, the following information is specified about each field:
7. Observations
Purpose
Glossary
Segment (record):
A typed aggregate of fields (fields) describing one complete aspect of a message. For example, the information about one order is sent as type of segment (OBR), the information related to an observation is sent as another segment (OBX).
The segment in a message is analogous to a record in a database, and in previous versions of the Standard we used record in place of the word segment. We have changed the nomenclature to be consistent with HL7 and other standards organizations in this version.
Field:
One specific attribute of a segment, for example, patient diagnosis, which may contain aggregates of fields further refining the basic attribute.
Repeated value:
Some fields may contain many repeat fields. For example, the diagnoses field may contain many different diagnoses.
Field components:
A field entry may also have discernible parts or components. For example, the patient’s name is recorded as last name, first name, and middle initial, each of which is a distinct entity separated by a component delimiter (sub-subfield in ASTM E1238-94).
Resolution
We accepted the proposal with 19 for, 0 against, and 0 abstain.
Proposal 180 – Segment Grouping
The proposal suggests to add groupings to the different messages as illustrated below for, e.g., ORM.
|ORM^O01^ORM_O01 |General Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit- Additional Info |3 |
| ] | | |
| [{ | |6 |
| IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| | | |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [CTD] |Contact Data |11 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| ] | | |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
|} | | |
Concern was expressed over use of certain labels. For example‘observation’ in both order and result messages. Do we need ‘supporting observation’, result observation etc…
We accepted a motion agreeing to the concept of adding labels; but recognize requirement for editors & publications committee to work with OO to ensure that the labels are appropriate and will not introduce confusion in naming with 19 for, 0 against, and 0 abstain. Action: Editors to add labels during editing.
Proposal 198 Resolving the ambiguity of SAC segment occurrence in the OML and ORL messages
Problem description:
The SAC segment in the OML could be at different hierarchical levels: [I] - one specimen which can have multiple tests ordered vs. [II] one ordered test which requires multiple specimens. This could lead to an ambiguity, if the 2nd occurrence of the SAC is for the case [II] or is a start of new order sequence for a next specimen container (case [I]).
Justification:
This problem was discussed within LAPOCT and O&O at meetings in January and May 2001. From 3 proposed solution one was chosen and accepted by the O&O committee (see minutes from May 2001). The corrections to chapter 4 and chapter 13 result from this decision.
Change:
Remove first occurrence of [SAC [{OBX}] ] from the OML and ORL messages in chapter 4. Correct corresponding examples in chapter 13.
Correct text follows:
OML - laboratory order message (event O21)
The following message structure may be used for the communication of laboratory and other order messages and must be used for lab automation messages. While the ORM message with the OBR segment can be used for backwards compatibility for general lab messages, only the OML message should be used to take advantage of the specimen and container extensions required in laboratory automation.
Note: The additional patient information (the segments PID, PD1, PV1, PV2, etc, which are sent after the OBR with the current order – indicated below with words “previous result”), could have been transferred with the previous result, because the patient demographics related to the previous result can differ from the demographics related to the current order. The current intent is to only allow references to the same patient as in the header PID.
The SAC segment included in the message allows the transfer of, e.g.: a laboratory order with multiple containers and multiple test orders related to each container, or laboratory orders with test order requiring multiple containers. For multiple orders related to one container the SAC segment describing this container must be repeated for each order.
Refer to Chapter 13 Laboratory Automation for examples of usage, particularly to clarify the use of two references to SAC segments in this one message.
The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.
|OML^O21^OML_O21 |Laboratory Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit- Additional Info |3 |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| OBR |Observation Request |4 |
| [{ | | |
| SAC |Specimen Container Details |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| }] | | |
| [TCD] |Test Code Details |13 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [TCD] |Test Code Detail |13 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| [{ | | |
| [PID |Patient Identification – previous result |3 |
| [PD1]] |Additional Demographics – previous result |3 |
| [PV1 |Patient Visit – previous result |3 |
| [PV2]] |Patient Visit Add. Info – previous result |3 |
| [{AL1}] |Allergy Information - previous result |3 |
| { | | |
| [ORC] |Common Order - previous result |4 |
| OBR |Order Detail - previous result |4 |
| {[NTE]} |Notes and Comments - previous result |2 |
| { | | |
| OBX |Observation/Result - previous result |7 |
| [{NTE}] |Notes and Comments - previous result |2 |
| } | | |
| } | | |
| }] | | |
| ] | | |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| } | | |
| | | |
ORL - general laboratory order response message to any OML (event O22)
The function of this message is to respond to an OML message. An ORL message is the application acknowledgment to an OML message. See Chapter 2 for a description of the acknowledgment paradigm.
|ORL^O22^ORL_O22 |General Laboratory Order Acknowledgment Message |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [OBR |Observation Request |4 |
| [{SAC}] |Specimen Container Details |13 |
| ] | | |
| }] | | |
| | | |
| ] | | |
|] | | |
13.5.6 Laboratory order message
Laboratory order with multiple containers and multiple test orders related to each container.
MSH|^~\&|INSTPROG|AUTINST|LASPROG|LASSYS|19980630080040|SECURITY |OML^O21|MSG00001|P|2.4|
PID|1||28514753||Joan^Howard^J||196303241225|F
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||2951-2^SODIUM^LN|||199808101444||||A||||SER
SAC|991912376^EXTLAB|01039421^THISLAB|092321A^LAS|092321^LAS||SER |19980620080037|U^UNKNOWN
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||2000-8^CALCIUM.TOTAL^LN|||199808101444||||A||||XXX
SAC|991912376^EXTLAB|01039421^THISLAB|092321A^LAS|092321^LAS||SER |19980620080037|U^UNKNOWN
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||4064-2^TRAZODONE^LN|||199808101444||||A||||SER
SAC|991912376^EXTLAB|01039421^THISLAB|092321B^LAS|092321^LAS||SER |19980620080037|U^UNKNOWN
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||3042-9^TRICHLOROETHANOL^LN|||199808101444||||A||||SER
SAC|991912376^EXTLAB|01039421^THISLAB|092321B^LAS|092321^LAS||SER |19980620080037|U^UNKNOWN
Laboratory order with test order requiring multiple containers (1st with special treatment, 2nd without).
MSH|^~\&|INSTPROG|AUTINST|LASPROG|LASSYS|19980630080040|SECURITY |OML^O21|MSG00001|P|2.4|
PID|1||28514753||Joan^Howard^J||196303241225|F
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||11054-4^CHOLESTEROL.LDL/CHOLESTEROL.HDL^LN|| |199808101444||||A||||XXX
SAC|991912376^EXTLAB|01039421^THISLAB|092321T^LAS|092321^LAS||ORH |19980620080037|I^IDENTIFIED|R5^5_HOLE_RACK|120|1||||BUF1^IN BUFFER 1 ||||||||||||||^1^:^1|LDLP
SAC|991912376^EXTLAB|01039421^THISLAB|092321A^LAS|092321^LAS||SER |19980620080037|I^IDENTIFIED|R5^5_HOLE_RACK|732|3||||BUF1^IN BUFFER 1 ||||||||||||||^1^:^1
Laboratory order with test order with previous result, where patient data did not change.
MSH|^~\&|INSTPROG|AUTINST|LASPROG|LASSYS|19980630080040|SECURITY |OML^O21|MSG00001|P|2.4|
PID|1||28514753||Joan^Howard^J||196303241225|F
ORC|NW|5212400021A|||||^^^^^R
OBR|1|5212400021A||2951-2^SODIUM^LN|||199808101444||||A||||SER
SAC|991912376^EXTLAB|01039421^THISLAB|092321A^LAS|092321^LAS||BLDV |19980620080037|U^UNKNOWN
ORC|RE|5212498721A|||||^^^^^R
OBR|1|5212498721A||2951-2^SODIUM^LN|||199807240826||||||||SER
OBX|1|NM|2951-2^SODIUM^LN||24.3|ug/g||N
Resolution
We accepted the proposed changes with 13 for, 0 against, and 2 abstain.
Proposal 249 – Specimen Segment
Note: The separate proposals regarding table modifications have now been incorporated into this proposal.
Problem 1:
OBR-15 Specimen Source is an over-loaded field defined using the old style data type CM. A new data type, SPS – Specimen Source, has been accepted as a temporary solution to the CM data type. It is clear that the SPS data type does not fully meet the needs for specimen information as well as the need to be able to characterize multiple specimens. Specimen information looks a lot like it should be its own segment.
Problem 2:
The Specimen and Container (SAC) segment provides attributes that relate primarily to the container. It suffers from the same problem as OBR in that it uses the CM (SPS) data type in SAC-6. The primary function of the SAC segment is to describe the specimen container (Section 13.4.3. “The container detail segment is the data necessary to maintain the containers that are being used throughout the laboratory automation system”). The SAC segment does not address the additional attributes required to describe the specimen.
Problem 3
The current table 0163 Body Site is inadequate for the new segment both in terms of inclusions and omissions. In the course of evaluating specimen source information data for table 0070, the OO Specimen Task Force identified a number of items that were anatomical locations. The task force will be recommending that these be moved from table 0070 to a new Body Parts table. Also, a number of new items appropriate for a Body Parts table have been identified. This new table would not include modifiers such as right or left such as were used in table 0163 Body Site. A Body Parts Modifier table proposal will be submitted under separate cover.
The task force investigated making changes to the existing HL7 Table 0163- Body Site. Most of the current entries would need to be deprecated because they contain a body site modifier such as right or left. This prospect gave rise to concerns about backwards compatibility especially in regard to fields like RXR-2 Administration Site that use table 0163. This was included in proposal # 42, which is now incorporated in this proposal.
Problem 4
In the course of evaluating table 0163 – Body Site, the OO Specimen Task Force discovered that a vast number of the entries were duplicated to accommodate modifiers such as right and left. The task force is recommending that these modifiers be defined in a new Body Parts Modifier table. Also, a number of new items appropriate for a Body Parts Modifier table have been identified. This was included in proposal # 42, which is now incorporated in this proposal.
Open Questions & Issues:
Proposal foundation: All items pertaining to specimen should be representable in the specimen segment as opposed to observations. (9/20 Jim) This means to me all things that are directly pertinent to the instance of the specimen described by the segment. It should not include treatments post-collection (except as a preservative or stabilizer), pre-test or post-test. The segment should describe the specimen as it is presented to the analyzing laboratory or as it is to be stored.
1) Diego Kaminker : how will we handle this scenario: (i.e., which messages will be exchanged - HL7 v.2.4) This is a very common scenario in some customers
1-A) The physician sends an order to the lab. Since the sample is drawn by the nurse, data about the specimen and container are sent to the lab.
Response: 9/20 – This is actually two services (using the concepts from version 3). The first order is the one that results in the sample being requested and collected. The second service would be submitting it to the lab. The information about the specimen is actually a result of the first order.
1-B) The same physician reviews the results and issues a new order, but the sample should be the same used in the previous process (they won't draw a new sample from the patient).
Response: 9/20 – This is where separating the collection service form the lab order works out well. You can reference the collection order on both the first and second lab orders, maintaining unique lab order instances without having to repeat the collection service.
1-C) What if the sample is not longer available in the lab? (it was disposed). There should be a message with this information for the placer?
Response: 9/20 – The response to the order would be something in the specimen availability attribute that would come back as an ORG (Some folks in the early discussions suggested another OMG message, but I disagree with that) to the ordering physician. The ORG message would need to be modified to include the SPM segment so that the specimen availability field could be sent.
4) Workflow Issues (proposal implications?)
[Jim Case] Lab flow: specimen obtained . . . sent to lab . . . incoming processing . . . (possible branching for multiple tests) . . . local determination of “appropriateness” of sample . . . test performed
[Patti Larson] BB Flow: specimen obtained . . . sent to BB . . . incoming processing determines appropriateness . . . (possible branching for multiple tests) . . . test(s) performed.
5) [Dave Eide] Chain of evidence considerations for legal specimen testing. This is an administrative function that does not pertain to the specimen directly, but is essential to track in a forensic laboratory. I don’t think it belongs in the SPM, but there does need to be a way to transmit the chain of custody of a specimen in such a way that the history of the specimen can be tracked.
Proposed Solution:
The objective of this proposal is to provide a unified representation of specimen that will appear in a single segment within messages that require specimen information.
The subcommittee considered the following options:
Expand the OBR. This approach does not solve the problem of multiple specimens associated with 1 order. Example: 24-hour creatinine clearance.
Expand the SAC. The specimen attributes under consideration do not appear to be within the confines of the stated intent of the SAC, which is to communicate “data necessary to maintain the containers that are being used throughout the laboratory automation system”. The SAC segment in chapter 13 is focused on what is going on with the container and, like the OBR, appears to provide only a subset of specimen characteristics. The SAC segment focuses primarily on the management of the container that holds the specimen. Container and specimen need to be distinguished, since not all specimens are in a container that requires detailed management information. This strongly supports the argument that the existing SAC segment does not already handle the data to be transmitted or be expanded to meet new needs.
Develop a new segment and deprecate OBR-15 Specimen Source and the SAC-6 Specimen Source. The proposed SPM – Specimen Segment will incorporate the attribute concepts of OBR-15 and SAC-6 as well as other relevant attributes of OBR and SAC. The intent is to define a segment that describes the specimen in clearly labeled fields that are usable in traditional syntax and in XML messaging. Order-specific information will remain in OBR and specimen container attributes will be described in SAC. In addition, a substantial number of new specimen attributes have been identified and incorporated into the new segment. An advantage afforded by a separate specimen segment is the multiple relationships that will be able to exist between order(s), specimen(s) and specimen container(s).
The OO TC approved this approach in September 2000 at St. Louis. Development continued through teleconferences and January 2001 and May 2001 Working Group Meetings with requested participation from the following TCs and SIGs: Orders/Observations, Blood Bank, Microbiology, Lab Automation and Government.
Order Messages
General Trigger Events & Message Definitions
OMG - general clinical order message (event O19)
|OMG^O19^OMG_O19 |General Clinical Order Message |Chapter |
|… | | |
| { | | |
| ORC |Common Order |4 |
| OBR |Observation |4 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [CTD] |Contact Data |11 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| {[ | | |
| [ | | |
| PID |Patient Identification – previous result |3 |
| [PD1] |Additional Demographics – previous result |3 |
| ] | | |
| [ | | |
| PV1 |Patient Visit – previous result |3 |
| [PV2] |Patient Visit Add. Info – previous result |3 |
| ] | | |
| [{AL1}] |Allergy Information - previous result |3 |
| { | | |
| [ORC] |Common Order - previous result |4 |
| OBR |Order Detail - previous result |4 |
| {[NTE]} |Notes and Comments - previous result |2 |
| [CTD] |Contact Data - previous result |10 |
| { | | |
| OBX |Observation/Result - previous result |7 |
| [{NTE}] |Notes and Comments - previous result |2 |
| } | | |
| } | | |
| }] | | |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| [{ | | |
| SPM |Specimen |4 |
| [{OBX}] |Observation related to Specimen |7 |
| }] | | |
| } | | |
ORG - general clinical order acknowledgement message (event O20)
|ORG^O20^ORG_O20 |General Clinical Order Acknowledgment Message |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| ] | | |
| { | | |
| ORC |Common Order |4 |
| [OBR] |Observation |4 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [{CTI}] |Clinical Trial Identification |7 |
| [{SPM}] |Specimen |4 |
| } | | |
|] | | |
OML - laboratory order message (event O21)
|OML^O21^OML_O21 |Laboratory Order Message |Chapter |
|… | | |
|{ | | |
| [ | | |
| SAC |Specimen Container Details |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| ] | | |
| { | | |
| ORC |Common Order |4 |
| [ | | |
| OBR |Observation Request |4 |
| [{ | | |
| SAC |Specimen Container Details |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| }] | | |
| [TCD] |Test Code Details |13 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [TCD] |Test Code Detail |13 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| [{ | | |
| [PID |Patient Identification – previous result |3 |
| [PD1]] |Additional Demographics – previous result |3 |
| [PV1 |Patient Visit – previous result |3 |
| [PV2]] |Patient Visit Add. Info – previous result |3 |
| [{AL1}] |Allergy Information - previous result |3 |
| { | | |
| [ORC] |Common Order - previous result |4 |
| OBR |Order Detail - previous result |4 |
| {[NTE]} |Notes and Comments - previous result |2 |
| { | | |
| OBX |Observation/Result - previous result |7 |
| [{NTE}] |Notes and Comments - previous result |2 |
| } | | |
| } | | |
| }] | | |
| ] | | |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| } | | |
|] | | |
ORL - general laboratory order response message to any OML (event O22)
|ORL^O22^ORL_O22 |General Laboratory Order Acknowledgment Message |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| { | | |
| [SAC |Specimen Container Details |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| ] | | |
| [{ | | |
| ORC |Common Order |4 |
| [OBR |Observation Request |4 |
| [{SAC}] |Specimen Container Details |13 |
| ] | | |
| }] | | |
| } | | |
| ] | | |
|] | | |
7.3 TRIGGER EVENTS & MESSAGE DEFINITIONS
7.3.1 ORU – unsolicited observation message (event R01)
|ORU^R01 |Unsolicited Observation Message |Chapter |
|MSH |Message Header |2 |
|{ | | |
| [ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NK1}] |Next of Kin/Associated Parties |3 |
| [{NTE}] |Notes and Comments |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit - Additional Info |3 |
| ] | | |
| ] | | |
| { | | |
| [ORC] |Order common |4 |
| OBR |Observations Report ID |7 |
| {[NTE]} |Notes and comments |2 |
| [CTD] |Contact Data |11 |
| { | | |
| [OBX] |Observation/Result |7 |
| {[NTE]} |Notes and comments |2 |
| } | | |
| [{FT1}] |Financial Transaction |6 |
| {[CTI]} |Clinical Trial Identification |7 |
| [{ | | |
| SPM |Specimen | |
| [{OBX}] |Observation related to Specimen | |
| }] | | |
| | | |
| | | |
| } | | |
|} | | |
|[DSC] |Continuation Pointer |2 |
7.3.2 OUL – unsolicited laboratory observation message (R21)
|OUL^R21^OUL_R21 |Unsolicited Laboratory Observation Message |Chapter |
|MSH |Message Header |2 |
|[NTE] |Notes and Comments |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
|] | | |
|[ | | |
| PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit – Additional Information |3 |
|] | | |
|{ | | |
| [ | | |
| SAC |Specimen Container Details |13 |
| [SID] |Substance Identifier |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| ] | | |
| [ORC] |Common Order |4 |
| OBR |Observation |7 |
| [{ | | |
| SAC |Specimen Container Details |13 |
| [{OBX}] |Additional Specimen Characteristics |7 |
| }] | | |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| { | | |
| [OBX] |Observation Result |7 |
| [TCD] |Test Code Detail |13 |
| {[SID]} |Substance Identifier |13 |
| [{NTE}] |Notes and Comments |2 |
| } | | |
| [{CTI}] |Clinical Trial Identification |7 |
|} | | |
|[DSC] |Continuation Pointer |2 |
Observation Request Segment
4.5 General Segments
4.5.3 OBR - observation request segment
Issues, Notes, Comments & Discussion
6/20/01 Agreed: if the attribute is specific to the specimen, then it belongs in SPM, otherwise is should remain in OBR and be removed from this proposal.
HL7 Attribute Table – OBR – Observation Request
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|14 |26 |TS |O | | |00248 |Specimen Received Date/Time * |
|15 |300 |CM |O | |0070 |00249 |Specimen Source * |
| | | | | | | | |
4.5.3.14 OBR-14 Specimen received date/time (TS) 00248
Definition: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.
As of version 2.5, in messages where the SPM segment is present then the use of SPM-xx Specimen Received Date/Time would be favored over this field.
4.5.3.15 Specimen source (CM) 00249
Components: ^ ^ ^ ^ ^
Subcomponents of specimen source name or doe: & & & & &
Subcomponents of body site: & & & & &
Subcomponents of site modifier: & & & & &
Subcomponents of collection method modifier code: & & & & &
Definition: This field identifies the site where the specimen should be obtained or where the service should be performed.
This field is retained for backwards compatibility only. The reader is referred to the SPM segment.
As of version 2.5, in messages where the SPM segment is present then the use of SPM Segment would be favored over this field.
[…]
The fifth sixth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.
OBR-15.6 (and SAC-6.6) is not a required component. Can assumptions be made about what it really means when it is not populated? Recommendation to strike reference to room temp.
Specimen Segment
SPM - Specimen Segment
The intent of this segment is to describe the characteristics of a specimen. It differs from the intent of the OBR in that the OBR addresses order-specific information. It differs from the SAC segment in that the SAC addresses specimen container attributes. An advantage afforded by a separate specimen segment is that it generalizes the multiple relationships among order(s), results, specimen(s) and specimen container(s).
A specimen is defined as “A physical entity that is an individual, a group, an item, or a part representative of a larger group, class or whole that is the target of an observation or analysis for the purpose of drawing conclusions about the group, class, or whole.” Note that any physical entity in the universe has the potential to become a specimen
A specimen is collected or obtained from a source and may be representative of the source, or may represent a deviation within the source. A specimen may be wholly or partially consumed during an observation and any remaining portion of the specimen is persistent and can be stored.
This segment may also be used in limited cases to describe a "virtual" specimen. In particular, to identify the characteristics required for a specimen in the context of a specific observation or test.
In summary, SPM represents the attributes specific and unique to a specimen.
Need to add: narrative noting relationship to SAC and OBR segments. (To address discussion points.) (9/20 Jim) The relationship of OBR and SAC to SPM can be described as below:
[pic]
• SPM-SAC relationship
Can a container contain more than one specimen? Examples: A single jar (container) may contain a number of formalin fixed tissues that may be processed separately and have different tests performed.
Can a specimen exist across multiple containers? Examples: A single phlebotomy service where multiple tubes of the same type are taken at the same time.
Issue: To construct the messages we need to know if SPM is dependent on SAC or is SAC dependent on SPM. (See my relationships diagram above. Can there be more than on specimen (SPM) in a container (SAC) or can there be more than one container (SAC) for a specimen (SPM). Examples of both discussed, but we may not be using SAC in the proper context. We must remember that the SAC was developed out of a need by lab automation. While this is an absolute necessity for lab auto, the need for container information is not universal in laboratories. This may require the development of new message constructs that address the unique needs of labauto, but still retain the relationship of OBR-SPM-SAC for other uses.
Response from Greg Forbes:
• Since the SAC contains the Container Identifier I would think that this makes it universally required, if only to transmit this value. Would this be true if the container ID is only a proxy for the specimen identifier? ( Legal and audit trail requirements)
• A specimen may indeed apply to multiple containers.
• I would argue that there is not such thing as a 'box' of specimens unless it is subdivided into sub-containers within the box. See jar of tissues example above.
• As per a single container having multiple 'specimens', within accepted Laboratory practices, their must be a single descriptor that can describe the contents of any single container. - ie water and soil = mud - Any other interpretation of this seems a bit absurd, yes blood separates during transport, but to the lab, the description 'Whole blood' covers that. If the lab requires only the serum, then they will separate it. The extreme of this is sending Blood and Urine in the same container for a creatinine clearance test. (9/20 Jim Case) Again, in pathology we often receive containers from the field that consist of “tissue(s)”. These are often then subdivided for the purpose of different tests, or they may be tested together. There will be a single description for the gemish of stuff in the container. I can provide a number of other examples if necessary. However, the point is we need to be able to both split a specimen into additional component parts (such as an animal sent for necropsy as the primary specimen and pieces of tissue resulting from that analysis as child specimens). Conversely, we will want to be able to pool specimens together into a new specimen, keeping the identities of the original independent specimens intact.
• The collector can only send what the Lab can use. Since the Lab dictates the collection requirements for test performance, they can supply a single descriptor of the contents of any container. (9/20 Jim) I am not sure I understand this. The collector can send whatever they want for analysis. Whether the specimen is appropriate or suitable for analysis is an observation made by the laboratory. While the lab dictates what the appropriate specimens are, these guidelines are often not followed. This should result in an acknowledgement message that states the inappropriateness of the sample, if necessary.
Implications for message construction:
Issue: Do SPM and SAC exist independently or in a dependent relationship? (9/20 Jim Case) IMHO, we need to separate out the characteristics of the specimen and the container. Thus, the SAC is dependent on the SPM. This does however, bring up another question. Is it necessary in lab automation to know what the specimen is that is in the container? Or do they only care about whether the container has enough of whatever it is to do the analysis? If labautomation needs to know the content characteristics, then my initial statement is true. If not, then there is the possibility that SPM and SAC are independent. Depends on the context. There is definitely a relationship, but in many cases the need for detailed information about the container is neither necessary nor desired by the filler. We do not care much about the characteristics of the container as long as it doesn’t leak…
Issue: Is it necessary to be able to link SPMs and/or SACs across multiple messages?
[smr 8/28] While a specimen must exist within a container (9/20 Jim - this is not always true, specimens can and do exist without a container. In veterinary pathology, an animal carcass, which is a specimen, does not come packaged in any type of container, it is simply delivered to the lab), a container does not always contain a specimen. A specimen exists within some space, which is defined by the container. Prior to the introduction of the specimen into the container, the container exists but is not significant from a clinical perspective. The container may be a simple device (a plastic bag) or may be a complex device with multiple attributes significant to the observation to be performed (a blood sample tube with additives and specific dimensions for use in automated processing). This discussion would suggest that, in regards to Orders and Observations, the segment relationship would be an OBR relates to SPM, which relates to SAC. SPM and SAC would both be optional, but SAC would require that SPM be present. ( OBR {[ SPM [ SAC ] ]} ) This differs from Lab Automation messages, where the container can be the operative unit and the SPM segment may not be necessary. (9/20 Jim) I agree, unless the deprecation of SAC-6 would move the specimen information to the SPM, in which case the SPM would be required (however, see my discussion above about whether labauto really needs to know what the specimen is, or just the ID)
OO 10/01/01 – optionality repetition formatting approved as suggested . ( OBR {[ SPM [ SAC ] ]} )
Lab 10/03?/01 – noted that Specimen (Container) Status Update/Request (SSU & SSR) and other Lab Automation messages the relations should be expressed as { SAC [SPM] [OBX] }.
10/14/01 – smr – Lab brings up a good point, placement of SPM in the message structure may not be the same in all cases. Need to pull every message structure that uses into this proposal and explicitly define SPM placement and optionality.
HL7 Attribute Table – SPM – Specimen
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|2 |80 |EIP |O | | | |Specimen ID |
|3 |80 |EIP |O |Y | | |Specimen Parent IDs |
|4 |250 |CWE |R | |???? |00249 |Specimen Type |
|5 |250 |CWE |O |Y |???? | |Specimen Type Modifier |
|6 |250 |CWE |O |Y |0371 | |Specimen Additives |
|7 |250 |CWE |O | |???? | |Specimen Collection Method |
|8 |250 |CWE |O | |???? |00310 |Specimen Source Site |
|9 |250 |CWE |O |Y |???? | |Specimen Source Site Modifier |
|10 |250 |CWE |O | |???? | |Specimen collection site |
|11 |250 |CWE |R O |Y |0369 | |Specimen Role |
|12 |20 |CQ |O | | |00243 |Specimen Collection Amount |
|13 |6 |NM |C | | | |Grouped Specimen Count |
|14 |250 |ST |O |Y | | |Specimen Description |
|15 |250 |CWE |O |Y |0376 |01370 |Specimen Handling Code |
|16 |250 |CWE |O |Y |???? |00246 |Specimen Risk Code |
|17 |26 |TS DR |O | | | |Specimen Collection Date/time |
|18 |26 |TS |O | | | |Specimen Receive Date/time |
|19 |26 |TS |O | | |00241 |Specimen Expiration Date/time |
|20 |1 |ID |O | |0136 | |Specimen Availability |
|21 |250 |CWE |O |Y |???? | |Specimen Reject Reason |
|22 |250 |CWE |O | |???? | |Specimen Quality |
|23 |250 |CWE |O | |???? | |Specimen Appropriateness |
|24 |250 |CWE |O |Y |???? | |Specimen Condition |
|25 |20 |CQ |O | | | |Specimen Current Quantity |
|26 |4 |NM |O | | | |Number of Specimen Containers |
|27 |250 |CWE |O | | | |Container Type |
|28 |250 |CWE |O | |???? | |Container Condition |
|29 |250 |CWE |O | | | |Specimen Child Role |
SPM field definitions
SPM -1 Set ID - SPM (SI) nnnnn
Definition: This field contains the sequence number. This field is used to identify SPM segment instances in message structures where the SPM segment repeats.
Specimen ID (EIP) nnnnn
Components: ^
Components for filler assigned identifier: ^ ^ ^ < universal ID type (ID)>
Definition: This field contains a unique identifier for the specimen as referenced by the Placer application, the Filler application, or both.
This field is not required, as there are use cases in which a unique specimen identifier may not exist. In the first scenario, a placer application may initiate an observation request against an existing specimen without uniquely identifying the specimen. Additionally, in the case of the TCU_U10 message structure, used in Automated equipment test code settings messages, the SPM segment is used to define required characteristics of the specimen. As such, TCU_U10 uses SPM to define a virtual specimen, and a specific specimen ID would not exist. Filler applications would be expected to assign a Specimen ID and populate this field accordingly.
OBR:
SAC: SAC-3 Container ID
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggest different definition: " This field contains an identifier for the specimen unique within the service filling the order. This attribute is required except for use in conjunction with the TCC segment (messages TCU and TCR)."
10/14/01 smr – The first sentence brings up an interesting point, that there may be a different identifier for a specimen in different systems. Rather than specifying that this is the identifier for the filling system, maybe we should have this field repeat so that each system can populate this field with all known identifiers.
I don't agree with the second sentence. SPM should/will be optionally associated with TCC in the TCU and TCR messages. As such, if a specimen is significant and to be identifier, it must have an identifier.
10/25/01 JTC The change in the definition above will result in Specimen ID being a conditional field. I do not agree that something as essential as the ID of the specimen can be conditional in any circumstance. This is especially true since TCC.3 (specimen source) is optional. Thus a conditional with an optional will be very hard to negotiate conformance. Since the TCR and TCU messages will have the SPM as an optional segment, the “conditionality” of the definition above is not really needed.
10/31/01 OO call – If there are other identifiers allowed, then the expectation on what will be done with the identifiers must be explicit. In the context of a message, there are only two systems and two significant IDs – placer and filler. Group agreement to limit to only two IDs and to place them in separate fields. Scott will revise definition and add another field (Placer … and Filler …), referring to ORC/OBR for consistent placer/filler usage.
11/14/01 OO call - e-mail from Jim Case questioning the need for two fields and associated optionality. With a single repeating field, an application can determine the appropriate IDs based upon the "assigning authority" in EI. Also, the repetitions can be used to support chain of custody requirements. Discussion: identification of each ID requires knowledge of the role of each "assigning authority." These roles may not be consistent – a filler can become a placer when sending an order to a reference lab. Chain of custody may not be satisfied by a simple list of IDs, another means should be found to properly deal with chain of custody.
Outcome: will maintain two non-repeating ID fields
12/12/01 the CM replacement project has defined a new data type that may be useful in this case. EIP is a paired EI, one as Placer and the other as Filler. Eliminates need for two fields while maintaining placer/filler distinction. Noted that field cannot be required. There are at least 2 situations where the ID may not exist: (1) placer creates order with specimen but does not assign identifier, (2) in the TCM_U10 message. Added narrative to explain.
Specimen Parent IDs (EIP) nnnnn
Components: ^
Subcomponents of filler assigned identifier: & & & < universal ID type (ID)>
Definition: This field contains the identifiers for the specimen or specimens that contributed to the specimen that is described by the segment instance. .
If this field repeats, then SPM-xx Specimen Role should be valued with "L" (pooled). The repetitions of this field then carry the specimen IDs of the contributing parent specimens to the pool.
OBR:
SAC:
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
10/17/01- dsc - Group expressed issues with the “Each repetition” line and suggests that we utilize the assigning authority as the identifier.
10/21/01 JTC Issue: If we make the Parent Specimen ID repeatable, it accomplishes the same thing as this field. As noted above (in my comment) there is no need to have both of these fields since the notion of pooled specimen is subsumed in the repeating Parent ID attribute.
10/25/01 I have edited this definition so that it can handle either the specimen ID of the parent specimen for a single unique specimen or for a pooled specimen. Typically grouped specimens will not be identified so this will not apply. If accepted this means we can delete the newly proposed SPM-45, Parent Specimen ID.
11/14/01 OO Call - Narrative needs work. Attempting to consolidate the child-of (one parent) and member-of (multiple parents) concepts may pose difficulties for current applications. Also, will repeatability be only for multiple parents or will this allow for synonym IDs (IDs from other authorities) – this could further complicate application handling. Scott will work on examples to illustrate the different concepts. Group will need to decide whether this will be maintained as one field or to revert to multiple fields.
12/4/01 moved from 7.4.3 introduction, part of initial development " (note that multiple specimens can be pooled to create a new specimen) [Dave Eide] [8/29] is this necessary here? Pooled specimen needs to be tracked back to the original specimens. Sounds like a new field? Issue: how do we handle pooled specimens and track back. (9/20 Jim) I do not think we need to address pooled specimens except by example. The fact that we can create derivative specimens (can we???) from a specimen leads to the conclusion that the converse should be possible. This needs to be worked out in more detail, but probably after this first draft gets reviewed. Those of use that are concerned with pooled specimens needs to work this out." Option/question: (SMR) can we add specific examples as was done with interfering products?
12/12/01 changed data type to EIP
Specimen type (CWE) nnnnn
Components: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
Definition: This field describes the precise nature of the entity that will be the source material for the observation.
Any physical entity that may have observations made about it may qualify as a specimen. The entry in this attribute describes the specific entity as precisely as possible, whether that is a complex organism (e.g., an ostrich) or a specific cellular mass (e.g., a specific muscle biopsy).
This attribute corresponds to OBR.15 – Specimen Source and SAC.6 – Specimen Source component 1 – Specimen source name or code. These components, and the SPS data type, were deprecated upon the development of this segment.
A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
• HL7 table nnnn – specimen type (replaces HL7 table 0070 – Specimen source codes)
• SNOMED, etc.
• Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.
OBR: OBR.15.1 Specimen Source / Specimen source name or code
SAC: SAC.6.1 Specimen Source / Specimen source name or code
v3 Specimen CMET:
Issues, Notes, Comments & Discussion:
We need to determine whether we will be proposing a new table for types or do we want to state that external vocabularies will be used. (9/20 Jim - I think the definition for the field above does a good job of defining what is applicable for this field. The table above has met the needs of folks in the past. If people have specific issues with this, then they will need to tell us what they are in detail for us to address the concern.)
Since anything can be a specimen, any physical entity that may have observations made about it qualifies for this field. While anything can be a specimen, the specific type of thing is a more restricted set than “everything in the world”.
Some v3 stuff . . . anything can be a specimen. As precise as possible (ostrich, specific muscle, etc.)
Use CWE to support both coded and uncodeable entries
8/1/01 note that table 0070 has been replaced in proposal 133, points from proposal 133 include:
Criteria for inclusion in Specimen Type table:
1. Common specimen substances (aka types)
2. Entries that accommodate unidentified substances, substances known but not appearing in the table, illegible source, substance not specified would be retained or added. These items are necessary to facilitate entry into a user system.
3. Clinical nomenclature in common usage (body part or collection method is an integral part of the commonly used descriptor) (How you commonly say what you see) Urine, Clean Catch was our gold standard.
Excluded Items (except as noted above):
1. Diagnoses
2. Procedures
3. Ambiguous entries
4. Anatomical locations
5. Collection methods
Definitions:
Specimen substances can include the following:
1. A general type that does not identify a specific body part, e.g., tissue or fluid.
2. An entity that has specific meaning to the Lab, e.g., “Tissue, acne” or “spinal fluid”.
3. A particular situation or condition that caused the creation of the specimen e.g., “cat bite”.
4. A product or byproduct of a biological process e.g., mucus.
5. A product or byproduct of a pathological process e.g., pus.
6. A substance that is contained in a transport container and/or inoculated onto a transport media e.g., “skin scraping” or “discharge” or “nail clippings” Transport media and containers should be included in the OBR^15.3 (Collection Method) [SPM^?].
7. Procedure result e.g., “brushing” or “washing”.
8. A device e.g., “catheter” or “IUD” or “implant” or “pacemaker”
[8/29] would need to propose as v3 vocab. Austin and Jim don’t think it would pass Vocab. Will need to take to vocab, get response and direction.
11/14/01 OO Call - Still need to harmonize vocabulary with v3. Consider creating additional example to illustrate simple and complex type/modifier
Specimen Type Modifier (CWE) nnnnn
Definition: This field contains modifying or qualifying description(s) about the specimen type
The use of this attribute is to modify, qualify or further specify, the entity described by SPM.5 – Specimen Type. This is particularly useful when the code set used in SPM.5 does not provide the precision required to fully describe the specimen. For example, if the specimen was precisely described as ‘capillary venous blood’ but the code set employed only provided ‘venous blood,’ this attribute could be employed to add the modifier ‘capillary.’
OBR: Currently not represented in OBR-15
SAC: Currently not represented in SAC-6
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This may state something about the nature of the specimen. For example, the specimen type may be blood, but the modifier could be a smear (on a slide). It does not indicate the method by which the specimen was collected. In the case of a smear the original blood sample may have been collected via venapuncture or capillary stick. This is more important when we deal with specimens that are not related to patients. For the general specimen this might also include the values in Table 0372 – Specimen component. I have called it a string data type due to the huge variety of modifiers that can occur. In food safety testing for instance we might get a specimen type of “Yogurt” but then have a modifier of “1% milkfat, blackberry flavored”. (9/20 Jim) This information can be reworded such that is can provide additional information about non-human and non-clinical specimens and the added as a paragraph under the current explanatory paragraph.
Further information on the specimen. (ground , ground irradiated , capillary , grilled )
Change to CWE to support both coded and uncodable entries, likely that there may be a preponderance on exceptions in some disciplines.
Consider moving after SPM.3
11/14/01 OO Call - Consider creating additional examples to illustrate simple and complex type/modifier
Specimen additives (CWE) nnnnn
Definition: This field identifies any additives introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. Refer to HL7 Table 0371 – Additive for valid values.
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
See also SPM.37 (proposed by Jim Case)
8/7/01 SMR – merged with SPM.37, SPM.37 will be removed. Note SAC.27 as duplication, will we need to address SAC.27? (9/20 Jim) This needs to be discussed with Labauto. The itention of this field is to describe the state of the specimen as it comes from the collection service. Any additional additives that are needed after receipt by the laboratory should not be included in the SPM.
SAC.27 Definition: This field identifies any additives introduced to the specimen before or at the time of collection. It is a repetitive field. Refer to HL7 Table 0371 – Additive for valid values. The table’s values are taken from NCCLS AUTO4. The value set can be extended with user specific values. (9/20 Jim) As this is written, it is redundant with the SPM attribute and should be deprecated.
8/20 – inserted latest version of Proposal 39 revising Table 0371. Outstanding issue: (JCase: Is there any reason why we have some codes that are 3 and some that are 6 long? If we are going to have those that are 6 long, then we can make some of the others less obscure.)
[8/29] need to f/u to make sure that v3 vocab has been submitted. (9/20 Jim) This will be done when there is closure on this proposal.
Lab 10/3/01 – suggested wording to address situations where additives might exist in both the SPM and SAC segments.
Should table 0371 be in chap 7, chap 13 or both?
10/14/01 smr – rephrased Lab wording and added to both SPM-7 and SAC-27. In this proposal, we currently have table 0371 in both chap 7 and chap 13.
10/14/01 OO Call - Jim Case concern regarding narrative stating a priority between SPM and SAC additives. Discussion: agreement that stating a priority in the narrative is not appropriate. Have to consider both SPM and SAC additives, would expect to be the same but if not then would have to consider both fields. Outcome: revise narrative, add example to illustrate specimen/container additives (specimen with C32 -> aliquot still has C32, -> aliquot added to tube with 6NHCl then message needs to indicate both C32 and 6NHCl).
Specimen Collection Method (CWE) nnnnn
Components: ^ (ST)> ^ ^ ^ ^
Definition: Describes the procedure or process by which the specimen was collected.
A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
• SNOMED, etc.
• Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.
OBR: OBR.15.3 Specimen Source / freetext (collection method)
SAC: SAC.6.3 Specimen Source / freetext (collection method)
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Examples of this include: capillary puncture, venapunture, laparoscopy, punch biopsy, autopsy/necropsy
See also SPM.5
[Scott R 7/23/01]While the names are the same/very similar to OBR.15.6, the intent appears to be different and would warrant maintaining this attribute.
8/1/01 Group – relates to OBR.15.3 (smr – I missed the narrative description) rather than OBR.15.6. Some work has been done on this code set in a proposal, find and incorporate in this proposal. Suggest that should CWE.
8/20 deleted old SPM.x Specimen collection method. Added Table from Proposal 40, note that this is still work in progress.
9/20 Jim - Once we get out of clinical medicine the collection procedures will be hard to enumerate in and HL7 table. The existing table is an eclectic mix of culture type, collection methods and procedures.
Specimen source site (CWE) nnnnn
Components: ^ ^ ^ ^ ^
Definition: specifies the source from which the specimen was obtained. For example, in the case where a liver biopsy is obtained via a percutaneous needle, the source would be ‘liver.’
A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
• SNOMED, etc.
• Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.
OBR: OBR.15.4 Specimen Source / body site
SAC: SAC.6.4 Specimen Source / body site
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Jim – suggest name change to Specimen Source Site and revision of narrative
Issue: We keep referring to this data as Body Parts. Would Anatomical Location be a better name? (9/20 Jim) Needs to be generalized beyond anatomy. Remember that specimens can be anything.
Issue: Should these entries be turned into nouns for consistency? (9/20 Jim) Yes.
Issue: Should we state that the table is not intended to be all-inclusive? There are 454 entries under investigation. See end of proposal.
[8/29] group agrees to remove ‘body’ from attribute name and generalize narrative
10/25/01 JTC: Since the table below would be a new HL7 table and the domain for specimen source is extremely broad, I would suggest that we do not try and include it. Rather than try to redefine table 0163, let’s leave it as a negotiable code set. Most folks will use something like 0163 if they are already using it and new implementers will not want to use it because of its deficiencies, yet might be compelled to try because of the fact that it is an HL7 table. By removing it, it is more consistent with the CWE data type and the notes above (nationally accepted coding system).
Specimen source site modifier (CWE) nnnnn
Components: ^ ^ ^ ^ ^
Definition: This field contains modifying or qualifying description(s) about the specimen source site
The use of this attribute is to modify, qualify or further specify, the entity described by SPM.12 – Specimen Source Site. This is particularly useful when the code set used in SPM.12 does not provide the precision required to fully describe the site from which the specimen originated. For example, if the specimen source site was precisely described as ‘left radial vein’ but the code set employed only provided ‘radial vein,’ this attribute could be employed to add the modifier ‘left.’
• Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.
OBR: OBR.15.5 Specimen Source / site modifier
SAC: SAC.6.5 Specimen Source / site modifier
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Jim – suggest name change to Specimen Source Site Modifier and revision of narrative
Issue: There are additional entries under investigation for inclusion in this table. Only those that seem to hold the most promise of agreement are included here. See end of proposal for additional values.
Specimen collection site (CWE) nnnnn
Definition: This field differs from SPM-xx Specimen source site in those cases where the source site must be approached via a particular site (e.g., anatomic location). For example, in the case where a liver biopsy is obtained via a percutaneous needle, the collection site would be the point of entry of the needle. For venous blood collected from the left radial vein, the collection site could be “antecubital fossa”.
• Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.
OBR: OBR.15.4 Body site
SAC: SAC.6.4 Body site
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
While this might easily coded for specimens that originate from persons, it does not work out so well when you name all of the people, places and things that a specimen can originate from. In public health and veterinary medicine, for instance, water quality testing (we do that in our lab) can originate from many different sources (city supply, well, lake, stream, puddle…etc). This is analogous to the body site code in the current OBR-15. If this were a coded value, it would be a very long list. For instance, the specimen type might be “Potato Salad” while the collection site would be “The company picnic for XYZ corporation”. In an industrial setting the site code would be “the sink drain in the dishwasher area” or “6 inches under the grate beneath the refrigerator”.
[7/11/01] SR – A replacement or enhancement of SPM.6 Specimen Body Site. Need (?) narrative to clarify that this may include a non-body physical location (with examples).
[8/1/01] JL – yes we should allow for non-body sites. Alternative would be to maintain body site and add another field for non-body sites/non-standardized. Would CWE be better? Group – ST is not codifieable. ST unencumbers the users that they can enter anything, which systems admins will hate. CWE would allow for local extensions or use of or code values with original text allowing for detailed textual description. Note that SPM-6 references table 0163 that is in proposal to be replaced.
Group – collapse SPM.34 and SPM.6 with data type CWE. Add to narrative to clarify that use body/other. Incorporate proposal to replace 0163 with xxxx.
8/22: Group thinks the 2 fields (SPM-10 and SPM-12) should be separate. Should be CWE rather than ST.
[8/29] Jim – noting difference to specimen source: collecting liver percutaneously – site would be abd, source would be liver.
Specimen role (CWE) nnnnn
This field indicates the role of the sample. Refer to User-defined Table 0369 – Specimen role for suggested values. Each of these values is normally identifiable by the systems and its components and can influence processing and data management related to the specimen.
If this field is not populated, then the specimen described has no special, or specific, role other than serving as the focus of the observation. Such specimens include patient, environmental and other specimens that are intended for analysis.
A grouped specimen consists of identical specimen types from multiple individuals that do not have individual identifiers and upon which the same services will be performed. If the specimen role value is “G” then the Grouped Specimen Count (SPM-20) must be valued with the total number of specimens contained in the group.
If the specimen role is “L”, the repetitions of Parent Specimen ID (SPM-4) represent the individual parent specimens that contribute to the pooled specimen.
User-defined Table 0369 - Specimen role
|Value |Description |
|B |Blind Sample |
|C |Calibrator, used for initial setting of calibration |
|E |Electronic QC, used with manufactured reference providing signals |
| |that simulate QC results |
|F |Specimen used for testing proficiency of the organization performing|
| |the testing (Filler) |
|G |Group (where a specimen consists of multiple individual elements |
| |that are not individually identified) |
|L |Pool (aliquantsaliquots of individual specimens combined to form a |
| |single specimen representing all of the components.) |
|O |Specimen used for testing Operator Proficiency |
|P |Patient |
|Q |Control specimen |
|R |Replicate |
|V |Verifying Calibrator, used for periodic calibration checks |
| | |
Micro 10/2/01 – need to improve definition. Added 'G' to table … should an example be added to the narrative? See above.
10/25/01 JTC: I made the field required. In the vast majority of cases the default will be P. However, I do not think we can make the assumption that the value is P when the field is blank. Making it a required field will ensure that we identify deviations from P.
Specimen Collection amount (CQ) nnnnn.
Definition: This field specifies the volume or mass of the collected specimen. For laboratory tests, the collection volume is the volume of a specimen. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 for full details about units.)
OBR: OBR.9 Collection Volume
SAC: ? SAC.23 Initial Specimen Volume
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Similar to SAC.23, but is it the same concept? SAC.23 Definition: This field identifies the draw volume of the container. Group consensus, this is not the same concept as defined in the SAC. The intent of this field is the physical mass/volume of the specimen, not the container capacity.
Use CQ or create separate NM and units (CE) fields?
8/20/01 – separated into two fields per HL7 recommendation to favor NM/CE over CQ.
Issue: should we drop “volume”? what if the quantity is a mass?
8/22/01: Group: can be either volume or mass. Standard should not specify a default. Need to think more about “eachs”
9/20/01: Jim: I am suggesting the name change from "specimen collection quantity" to "specimen collection amount", and a corresponding change to SPM-19, so that it removes confusion with the Specimen quantity field defined below
OO 10/01/01 – change data type to CQ and delete associated units attribute
10/17/01 – dsc- Group agreed to remove the “volume” part of the attribute description. Group questions the field length suggested in table. Joann Larson will bring this item up on the CQ meeting on 10/18/01. Group suggests that length should be 20 like in OBR 9.
10/25/01 JTC: Agree with JL. The change to the data type requires a change to the length. Don’t know if 20 is sufficient for all cases, but it is certainly long enough to handle most quantities.
Grouped Specimen Count (NM) nnnnn
Definition: This field refers to the number of individual specimens of a particular type represented by this instance of a specimen. The use of this field is restricted to specimens upon which all specimen related attributes are identical. This field would only be valued if the specimen role attribute has the value “G”.
OBR: None
SAC: None
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This is used in population health, public health, veterinary medicine where a large number of specimens are collected for a particular purpose, such as a single serology test. They are all of the same type, as identified in SPM-3, come from the same population and may or may not need to be individually identified.
See also SPM.26
8/15 teleconference discussion: This is not the same as OBR-9, SAC-22 or SAC-23.. It is unclear how this would be used. Why would there not be 2 or more segments? Presumably the date/time of collection would not be the same; other characteristics could vary; how would volume be handled if not separate segments?
At first it seemed that it might have been appropriate for a creatinine clearance where perhaps 2 serums were drawn plus a urine was obtained. The 2 serums could be described in 1 segment since they would be 2 instances of the same type for the same test. However, upon further reflection this was rejected, based on the reasoning above – different collect times etc. Use Cases involving 1) Glucose Tolerance testing with 9 draws and 2) CSF exams with multiple samples were also considered with the same conclusion drawn.
8/20 – is this any different that SPM.nn Specimen Collection Volume?
9/20 Jim Case Use case: A rancher collects blood samples from 150 adult cattle for trace mineral analysis. These are submitted to a laboratory without individual identifiers. Since they are all going to be subjected to the same test (and in reality, individual identification of samples is unnecessary since it will be the population parameters that are important to the clinician) there is only the need to describe how many serum samples are represented by this particular “specimen”. The samples are all drawn on the same date and the time is irrelevant. There are no characteristics of interest that vary from sample to sample. The results that would come back would include the number of samples within this specimen that had a particular result, or a list of observations on each sample, without meaningful identifiers (just number 1 through 150).
10/17/01- dsc- Group agrees there is an issue with the name because it is misleading. The phrase “Specimen Quantity” in the past referred to a numeric amount (100cc) now it is depicting the number of specimens (see Jim Case’s explanation on 9/20). Group suggests the name be changed to something like “Pooled Specimen Quantity” or use “Population” or “Number of Specimens in Pool”.
10/21/01 JTC: This is NOT a pooled specimen. A pooled specimen means that multiple individual specimens contribute to a combined sample that is analyzed as a unit. Since we have defined specimen role with a new code “G”, why don’t we called this “Grouped Specimen Sum”, “Grouped Specimen Total”, “Grouped Specimen Quantity”, since it really is only valid for grouped specimens.
Specimen Description (ST) nnnnn
Definition: This is a text field that allows additional information specifically about the specimen to be sent in the message
OBR: OBR.46 Placer Supplemental Service Information, OBR.47 Filler Supplemental Service Information, ? OBR.39 Collector’s Comment,
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Self explanatory
[smr] would there be different descriptions by the placer and filler (and performer)?
8/15 teleconference: Discussion as to whether this might be redundant with OBR-39 Collector’s Comment and whether OBR-39 should be deprecated. Decision was that OBR-39 should not be deprecated since use of the OBR is widespread. Also the intent may be different; the OBR-39 might be a comment about the procedure rather than the specimen itself.
8/20 need to be specific how this differs from SPM.nn Collectors Comment.
9/20 Jim: This could be used to describe more information on the nature of the specimen that is not adequately handled by the structured fields. It might include more information on the source or the site. For instance “sludge from 12” inside the waste water outlet of a cheese processing unit”. This could also go into the collector’s comment field, so we need to determine whether we need both. Probably don’t.
Specimen Handling Code (CWE) nnnnn
Definition: This describes how the specimen needs to be stored during collection, in transit, and upon receipt. As this field is not required, no assumptions can be made as to meaning when this field is not populated.
OBR: OBR.15.6 Specimen Source / collection method modifier code
SAC: SAC.6.6 Specimen Source / collection method modifier code, SAC-43 Special Handling Codes
SAC: SAC.43 Special Handling Considerations
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
The starting set for values would be table 0376 from chapter 13 (the modified version developed by Charlie Hawker et al.). This is called handling code in version 3
8/8/01 – question: how to differentiate between transport, storage and archive conditions. Jim: what is intended or needed for the message. Intent is the version 3 concept of handling code. Change name from “storage condition” to v3’s “handling code” and import v3 material. Jim will send current v3 vocab for handling code.
10/21/01 JTC An issue was brought up at the LABAUTO meeting where a good use case was given for having handling code in both the SPM and the SAC. However, these could easily be distinguished by changing the name to Specimen Handling Code (an conversely to Container Handling Code in SAC)
Table from V3 below
Shake before use SBU Shake thoroughly before using
Body Temperature C37 Critical to keep at body temperature 36-38C
Ambient Temperature AMB Keep at ambient temperature, 22 +/- 2C
Refrigerated temperature REF Keep at refrigerated temperature:4-8C Accidental warming or freezing is of little consequence.
Deep Frozen DFRZ Deep Frozen -16 to -20C.
Protect from Light PRTL Protect from light (eg. Wrap in aluminum foil.)
Critical Ambient temperature CAMB Critical ambient - must not be refrigerated or frozen.
Critical refrigerated temperature CREF Critical refrigerated - must not be allowed to freeze or warm until immediately prior to testing.
Critical frozen CFRZ Critical frozen. Specimen must not be allowed to thaw until immediately prior to testing.
Ultra frozen UFRZ Ultra cold frozen -75 to -85C. Ultra cold freezer is typically at temperature of dry ice.
Protect from Air CATM Critical. Do not expose to atmosphere. Do not uncap.
Metal Free MTLF Container is free of heavy metals, including lead.
Do not shake DNS Do not shake.
Frozen FRZ Keep below 0C.
8/15: Same as SPM-8 and SPM-14. All use table 0376. SPM-42 has better definition. Strike SPM-8 and SPM -14. SPM-14 was discovered following the teleconference and is an editorial correction.
Incorporates concepts from proposal 134 (which replaced 38).
User-defined Table 0376 - Special handling considerations
|Code |Description |Comment/Usage Note/Definition |
|C37 |Body temperature |Critical to keep specimen at body temperature: 36 - 38( C. |
|AMB |Ambient temperature |Keep specimen at ambient (room) temperature, approximately 22 ( 2 °C. |
| | |Accidental refrigeration or freezing is of little consequence |
|CAMB |Critical ambient temperature |Critical ambient – specimen must not be refrigerated or frozen. |
|REF |Refrigerated temperature |Keep specimen at refrigerated temperature: 4-8( C. Accidental warming or |
| | |freezing is of little consequence |
|CREF |Critical refrigerated |Critical refrigerated – specimen must not be allowed to freeze or warm |
| |temperature |until immediately prior to testing |
|FRZ |Frozen temperature |Keep specimen at frozen temperature: -4( C. Accidental thawing is of little|
| | |consequence |
|CFRZ |Critical frozen temperature |Critical frozen – specimen must not be allowed to thaw until immediately |
| | |prior to testing |
|DFRZ |Deep frozen |Deep frozen: -16 to -20( C. |
|UFRZ |Ultra frozen |Ultra cold frozen: ~ -75 to -85( C. (ultra cold freezer is typically at |
| | |temperature of dry ice). |
|NTR |Liquid nitrogen |Keep specimen in liquid nitrogen. |
|PRTL |Protect from light |Protect specimen from light (e.g., wrap in aluminum foil). |
|CATM |Protect from air |Critical. Do not expose specimen to atmosphere. Do not uncap. |
|DRY |Dry |Keep specimen in a dry environment. |
|PSO |No shock |Protect specimen from shock. |
|PSA |Do not shake |Do not shake specimen. |
|UPR |Upright |Keep specimen upright. Do not turn upside down. |
|MTLF |Metal Free |Specimen container is free of heavy metals including lead. |
The following narrative is taken from proposal # 134 which was a replacement of proposal # 38.
Justification:
This is a replace of proposal # 38. Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis.
The OO TC directed the specimen source subcommittee to update table 0376 with values that will be supported in v 3.0. Additionally, any new values uncovered during this subcommittee’s analysis should be submitted to Vocab for 3.0 inclusion.
Note: This is in-progress work submitted for a direction check.
Subcommittee Findings:
According to the Lab automation SIG the intent OBR-15.6 (and SAC-6.6) - collection method modifier code and SAC-43 Special handling consideration are the same. Both are related to specimen state (frozen, refrigerated etc.) The SAC-43 has a table assigned; the OBR-15.6 and SAC-6.6 do not.
Issue 2: OBR-15.6 (and SAC-6.6) is not a required field. Can assumptions be made about what it really means when it is not populated? – Added to definition of SPM-42 that no assumptions possible if not populated.
Issue 3: If table 0376 were to be assigned to OBR-15.6 (and SAC-6.6), would there be a backwards compatibility problem? – Need to move into OBR and SAC, if appropriate…we are already asking for OBR-15 and SAC-6 to be deprecated.
Issue 6: Is the new or expanded table an HL7 or user-defined table? (v2.4 is user-defined, proposals show as HL7)
Issue 7: Are the changes to the new or expanded table sufficient to warrant definition of a new table to replace 0376?
Issue 8: Use of the word critical in the table is questioned by Frank Howard (KP) – resolved by the precise definitions added to the table
Specimen Risk Code (CWE) 00246
Definition: This field contains any known or suspected specimen hazards, e.g., exceptionally infectious agent or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, a component delimiter must precede free text without a code. . Refer to User-defined Table ???? – Risk Codes for suggested entries
User-defined Table ???? – Risk Code
|Code |Description |Comment/Usage Note/Definition |
|BIO |Biological |The dangers associated with normal biological materials. I.e. potential |
| | |risk of unknown infections. Routine biological materials from living |
| | |subjects. |
|COR |Corrosive |Material is corrosive and may cause severe injury to skin, mucous membranes|
| | |and eyes. Avoid any unprotected contact. |
|ESC |Escape Risk |The entity is at risk for escaping from containment or control. |
|AGG |Aggressive |A danger that can be associated with certain living subjects, including |
| | |humans. |
|IFL |MaterialDangerInflammable |Material is highly inflammable and in certain mixtures (with air) may lead |
| | |to explosions. Keep away from fire, sparks and excessive heat. |
|EXP |Explosive |Material is an explosive mixture. Keep away from fire, sparks, and heat. |
|INF |MaterialDangerInfectious |Material known to be infectious with human pathogenic microorganisms. |
| | |Those who handle this material must take precautions for their protection. |
|BHZ |Biohazard |Material contains microorganisms that is an environmental hazard. Must be |
| | |handled with special care. |
|INJ |Injury Hazard |Material is solid and sharp (e.g., cannulas.) Dispose in hard container. |
|POI |Poison |Material is poisonous to humans and/or animals. Special care must be taken|
| | |to avoid incorporation, even of small amounts. |
|RAD |Radioactive |Material is a source for ionizing radiation and must be handled with |
| | |special care to avoid injury of those who handle it and to avoid |
| | |environmental hazards. |
OBR: OBR.12 Danger Code
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Copied directly from OBR.12. If maintained here, should OBR.12 be deprecated?
10/25/01 JTC: No. This field conveys the hazard of the specimen following collection to the receiving facility. This differs from the hazard that exists during the collection of the specimen.12/12/01 OO call – revised name to "Risk Code" as the vocabulary is taken from version 3 EntityRisk
12/19/01 OO Call – no other open issues
Specimen Collection date/time (DR) nnnnn
Definition: The date and time when the specimen was acquired from the source. The use of the Date Range data type allows for description of specimens collected over a period of time, for example, 24-hour urine collection. For specimens collected at a point in time, only the first component (start date/time) will be populated.
OBR: OBR.7 Observation Date/Time
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This is very important when specimens have been shipped from one laboratory to another or when there has been a delay in the delivery of a specimen to a laboratory. The specimen expiration dttm is directly affected by this datum.
See also SPM.20
8/1/01 consolidate with SPM.20, use TS to support date and time
8/7/01 SMR – use SPM.37 (with TS data type) over SPM.20 (better name and narrative).
12/12/01 OO Call – no open issues.
Specimen Receive Date/Time (TS) 00248
Definition: The specimen received date/time is the time that the specimen is received at the diagnostic service. The actual time that is recorded is based on how specimen receipt is managed and may correspond to the time the sample is logged in. This is fundamentally different from SPM-xx Specimen Collection date/time.
OBR: OBR.14 Specimen Received Date/Time
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Copied directly from OBR.14. definition is incongruous in this context, needs revision. If maintained here, should OBR.14 be deprecated?
Specimen Expiration Date/time (TS) 00241
Definition: This field is the date and time the specimen can no longer be used. For example, in the Blood Banking environment the specimen can no longer be used for pretransfusion compatibility testing. Messages instances for a specimen created after this date and time the specimen will include an SPM-xx Specimen Unavailability Reason of 'EX' indicating ‘Expired’.
OBR: not present in OBR
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
6/20/01 A specimen may have more than one expiration date/time based upon the test(s) to be performed. Some test may have tighter time constraints than others. Discussion of date assignments, who should populate what dates. Generally, expiration dates are assigned by the Filler system relative to the collection date/time and the type and nature of the test to be performed. Agreed: Modify attribute description to indicate this attribute is generally populated by the filler system. Also note that this may require/imply a business rule that the collection d/t is required.
12/12/01 OO Call – noted that reference to specimen status is inaccurate. Changed to Specimen Reject Reason. No other open issues.
Specimen Availability (ID) nnnnn
Definition: This describes whether the specimen, as it exists, is currently available to use in an analysis. Refer to HL7 Table 0136 Yes/No Indicator for valid values
OBR: not present in OBR
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This is my interpretation of what blood bank is looking for, but I may be wrong. It seems to me that for a particular specimen, it is either available for use or unavailable for use. A use case in toxicology is where a specimen exists, it is available for use in assays up to the point where all of the volume of the specimen is committed to analyses, but not all of the analyses have been performed. Thus the specimen is physically present and of the proper type, but it is no longer available for further analyses, unless one of the prior assigned tests is cancelled, then it would again become available. In the case of blood bank, this may be that a specimen is available for certain types of tests at different times, but may be too old for other tests.
[smr] “a specimen is available for certain types of tests at different times, but may be too old for other tests” sounds like the note on SPM.28 Expiration date that there may be multiple exp dates based upon multiple criteria of expiration.
8/8/01- Scott – is this a y/n attribute? Jim – relates back to BB
8/15: Teleconference discussion: Patti L states that for blood bank the rules are very strict. Once a specimen has expired its expired for all uses. Should this be renamed “Administrative Status”?
BB 10/02/01 – did this replace Specimen Action Code … no, the action code is an attribute of the order and exists (and will remain) in OBR-11
12/5/01 Patti Larson - it appears that Specimen Status was totally removed and I do not see that it was moved to another location. Blood Bank came up with those statuses and we feel that those reasons need to be in there. Even, if it is under a new name, such as Rejection Reason. I see you now have a flag for specimen availability, which is fine. Response SMR Specimen Status was removed in favor of Specimen Availability, but no table is defined for this field. I have brought forward the Blood Bank status values for consideration as availability.
12/12/01 OO call – Jim Case holds that this field is a simple Y/N, is the specimen available for testing or not. The BB values describe rejection reasons and either should be in a different field or should exist in BB segment(s). Scott will contact Patti to follow up.
12/18/01 – moved reject reasons to a separate field based upon feedback from Patti Larson. Do we need to consider this as an ID pointed to table 0136 (yes/no)?
12/19/01 OO Call – agreed in principle to ID data type, but will leave open for further comment.
Specimen Reject Reason (CWE) nnnnn
Definition: This describes one or more reasons the specimen is rejected for the specified observation/result/analysis. Refer to HL7 Table ???? – Specimen Reject Reason for valid values.
HL7 Table ???? – Specimen Reject Reason
|Value |Description |
|AV |Specimen available |
|EX |Expired, resubmit new specimen if additional testing is needed |
|NR |Specimen not required |
|QS |Quantity not sufficient, resubmit new specimen if additional testing is needed |
|RB |Rejected due to broken container, resubmit new specimen |
|RC |Rejected due to Clotting, resubmit new specimen |
|RD |Rejected due to missing collection date, resubmit new specimen |
|RDA |Rejected due to missing patient ID number, resubmit new specimen |
|RE |Rejected due to missing patient name, resubmit new specimen |
|RG |Rejected due to illegible label, resubmit new specimen |
|RH |Rejected due to Hemolysis, resubmit new specimen |
|RI |Rejected due to Identification problem, resubmit new specimen |
|RL |Rejected due to Improper labeling, resubmit new specimen |
|RM |Rejected due to labeling, resubmit new specimen |
|RN |Rejected due to contamination, resubmit new specimen |
|RP |Rejected due to missing phlebotomist ID, resubmit new specimen |
|RQ |Rejected due to insufficient quantity, resubmit new specimen if additional |
| |testing is needed |
|RR |Rejected due to improper storage, resubmit new specimen |
|RS |Rejected due to name misspelling, resubmit new specimen |
|RT |Rejected due to label truncation, resubmit new specimen |
|RZ |Rejected due to missing label, resubmit new specimen |
OBR: not present in OBR
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
12/18/01 – Created separate attribute based upon response from Patti Larson.
12/19/01 OO Call – agreed in principle, but value AV does not appear to fit here. Scott will contact BB on removing value AV.
Specimen Quality (CWE) nnnnn
Definition: The degree or grade of excellence of the specimen at receipt. The filler populates this attribute.
User-defined Table nnnn - Specimen Quality
|Value |Description |
|E |Excellent |
|G |Good |
|F |Fair |
|P |Poor |
OBR: not present in OBR
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This might be constrained to something as simple as poor, fair, good, excellent.
[smr] is this an observation? By the placer, filler, both? Any relationship to SPM.27 Specimen Status? Need to differentiate in narrative.
8/8/01 – Jim – specific observation to this instance of a specimen as it relates to the specimen as received rather than one of several observations that may be made on the specimen – Filler Specific. Joann – agreed, this should be maintained as a specific attribute. Jim – SPM.27 may be overloaded, this is one part of the concept. Discussing these separate components may eliminate the need for the nebulous SPM.27. Need to define code table, and use data type CWE.
We may want to add language to further differentiate from Specimen Status and usage notes.
10/25/01 JTC: The removal of specimen status will remove this ambiguity.
12/19/01 OO Call – Ben S noted that there are specific ISO quality criteria. He will look into these criteria for inclusion as specific code values
Specimen Appropriateness (CWE) nnnnn
Definition: The suitability of the specimen for the particular planned use as determined by the filler.
User-defined Table nnnn - Specimen Appropriateness
|Value |Description |
|P |Preferred |
|A |Appropriate |
|I |Inappropriate |
|?? |Inappropriate due to … |
OBR: not present in OBR
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This can be either a simple code set of something like preferred, appropriate, inappropriate. An example of this would be the clotted blood for a CBC (inappropriate). The appropriateness of a specimen may be a cause for rejection and the specific cause could be listed here (see the Blood bank code table for specimen status for examples of these). However, I am concerned about the mixing of appropriateness of the specimen versus insufficient information to allow processing (administrative information). These are really different concepts. I would see rejection of a sample for admin reasons (ie. no ID, no patient name, etc.) as being another field, yet I do not include it here.
[smr] any relationship to SPM.27 Specimen Status? Need to clearly differentiate in narrative.
8/8/01 – Jim – components of status: quality, appropriateness, condition, availability (concepts from v3). The Status table mixes these concepts. Still may need additional language to differentiate form other “status” elements.
OPEN ISSUE: do we want to expand the the table to include the reason for appropriate/inappropriateness? If not, and simplified to two terms, then a Y/N may be more appropriate.
Specimen Condition (CWE) nnnnn
Definition: A mode or state of being that describes the nature of the specimen
User-defined Table nnnn - Specimen Condition
|Value |Description |
|AUT |Autolyzed |
|CLH |Clotted and hemolyzed |
|CLOT |Clotted |
|CON |Contaminated |
|COOL |Cool |
|FROZ |Frozen |
|HEM |Hemolyzed |
|LIVE |Live |
|ROOM |Room temperature |
|SNR |Sample not received |
SAC: SAC.6.6 Specimen Source / collection method modifier code
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
This would include descriptions of the sample itself, such as hemolyzed, autolyzed, contaminated, lipemic, etc.
• Are there use cases for distinguishing between condition and status?
Example :RH – Rejected due to Hemolysis”. In a lab setting this may not be a rejection, hemolysis is okay for glucose but not for potassium tests. [Bruce Wood]
This is another example of “status” versus “condition
• Is condition an observation?
[Jim Case] May also need to consider “condition” at time received and condition at time of test – not as an observation but as a descriptor of the specimen. “Conditions” may also be use/needed as a cancel reason in an Order Cancel message.
• Is appropriateness different from “condition” (as in available for use).? Very important for Micro. Appropriate means is this the right sample for the test requested. Condition means is it in good enough shape to use for the test (given that it is appropriate)
• Does Condition have to do with quality characteristics of the specimen? Yes, it is one of many quality characteristics
• Is specimen condition a specimen attribute or an observation?
6/13 - Specimen Condition Starter Set [Jim Case] this is the condition of the specimen as received, different from handling and storage although the terms overlap
Code Description
AUT AUTOLYZED
BROKE BROKEN CONTAINER (container condition
CLH CLOTTED AND HEMOLYZED
CLOT CLOTTED
CON CONTAMINATED
COOL COOL
FAIR FAIR (Appropriateness)
FROZ FROZEN
GOOD GOOD CONDITION (Appropriateness)
HEM HEMOLYZED
INA INAPPROPRIATE SAMPLE (Appropriateness)
LEAK LEAKING (container condition
LIVE LIVE
QNS QUANTITY NOT SUFFICIENT (specimen availablitiy or appropriateness)
ROOM ROOM TEMPERATURE
SNR SAMPLE NOT RECEIVED
TOX TOXIC
6/13: Continued discussion of specimen status/availability and specimen condition. It appears that these could be either attributes of a specimen and hence fields in a Specimen segment or observations appearing in an OBX segment. In either case these could be transmitted in an Acknowledgement message to an order or in a response to a query. Will proceed with segment filed.
8/8/01 – Jim – starter set is a current code set from an active system and is an example of mixed concepts (a poor example for this attribute). Specific entries should be deleted, possibly incorporated into other attributes.
10/25/01 JTC: This table needs to be thoroughly reviewed and updated.
Specimen Current Quantity (CQ) nnnnn
Definition: This attributes contains the amount of specimen that currently exists or is available for use in further testing.
OBR: not present in OBR
SAC: SAC.22 Available Volume
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
Is this an attribute or an observation?
See also SPM.44 (Proposed by Jim Case)
SAC.22 uses NM data type with units in SAC.24. Definition: This field identifies the current volume available for use in the container in the units specified below.
OO 10/01/01 – change data type to CQ and delete associated units attribute
10/17/01 – dsc- Group agreed that the data type should be changed to CQ.
Number of Specimen Containers (NM) nnnnn
Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples that accompany the order.
OBR: OBR.37 Number of Sample Containers
SAC: not present in SAC
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
6/20/01 Different from number of specimens, thus probably not the same as in OBR. Need better understanding/definition of container from LabAuto (Action Item – Scott). A specimen may need to be contained in multiple containers due to volume – Jim has suggested a Quantity attribute that may address this problem. Agree: until more information is available, keep this attribute in SPM but we may want to consider changing the name.
Unknown date: Number of specimen containers – [Jim Case] my intent on quantity was not the number of specimen containers, but the number of specimens. This may be the same in the majority of cases, but it is not the same where multiple specimens are transported in a single container, or a single specimen is in multiple containers (eg. Multiple clot tubes)
Container Type (CWE) nnnnn
Definition: The container in or on which a specimen is transported
OBR: not present in OBR
SAC: many specific container attributes in SAC, not this generalized term.
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
These would include tubes, vials, buckets, slides, swabs, plates, etc.
Would (could) this be part of SAC?
[smr] may need this if SAC is not required. Is a code table available?
8/8/01 – Dave – relates to in-house project, over 300 container types.
Container Condition (CWE) nnnnn
Definition:
OBR:,
SAC:
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
8/8/01 added to support concepts like broken, leaking, etc.
8/15 teleconference: Use case unclear. Seems like an observation although it might be useful to collect this information for reasons other than reporting. Some questioned that it seemed unnecessary to separate from specimen condition since the container condition affects the specimen condition.
Move to the bottom … may delete if no clear use case found
10/25/01: In chain of custody cases where specimens are moved from lab to lab, the status of the container that the specimen is shipped in must be recorded at each receipt. Thus if the container is compromised in any way (seal broken, container cracked or leaking, etc) then this needs to be recorded for legal reasons.
Specimen Child Role (CWE) nnnnn
Definition: For child specimens, this field identifies the relationship between this specimen and the parent specimen. If this field is populated, then SPM-45 Parent Specimen ID must be populated. Refer to User Defined Table NNNN – Specimen Child Roles for suggested values.
This field differs from SPM-15 Specimen Role in that this field refers to the role of this specimen relative to a parent role rather than the role of this specimen to the ordered service.
HL7 Table NNNN – Specimen Child Role
|Value |Description |
|A |Aliquot |
|C |Component |
|M |Modified from original specimen |
OBR: not present in OBR
SAC: SAC.28 Specimen Component
v3 Specimen CMET: ? a role-role relationship rather than a role of a specimen participating in an act (smr)?
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested to support the identification of parent-child relationships between specimens. This field would describe the role of this specimen to the parent and to is siblings.
10/14/01 smr – I added "child" to the attribute name to differentiate from SPM-15 Specimen Role. In v3, this would be a role-role association, not a role of one specimen to the ordered act.
From other Lab comments, it appears that this field will supplant SPM-28. If is this the case, do we create a new table of values or re-use table 0372?
10/17/01 – dsc - The groups suggestion is that the Parent and Child roles switch spots, so the Child would be 7.4.3.45 and the Parent be 7.4.3.36. This is still an open issue.
10/25/01 JTC: I am unclear how this would be used. I get the concept of the Aliquot role, but would like a concrete example of how it would be used in a message.
Interfering compounds example
4.6.3 Specimens with interfering compounds
In the case where a specimen is obtained from a source and one or more potentially interfering compounds or factors are known to exist in the source, those compounds/factors need to be communicated. The SPM – Specimen Segment does not include attributes for such compounds/factors as these compounds/factors are considered observations on the source rather than specific attributes of the specimen. Such compounds/factors are communicated in OBX – Observation Result segments, as can be seen in the following examples.
Was SPM-nn Drug/Potential Interfering Products
OBR: not present in OBR
SAC: SAC.41 Drug Interference
v3 Specimen CMET:
Issues, Notes, Comments & Discussion
SAC.41 Definition: This field describes the drug interference identifier that is associated with the specimen. Refer to User-defined Table 0382 – Drug interference for suggested values.
If maintained in SPM, should this be deprecated from SAC?
8/22: Group –m remains unclear if this is an observation or an attribute.
9/20 Jim - This is a poorly defined field in the SAC with no table values to give it context. It appears to fall in the same category as system-induced contaminant and I propose we remove it from the SPM and let the SAC handle it.
10/3 LAPOCT – this is specimen characteristics and should be included in the SPM ⋄ The definition should be improved by stating, that:
This field identifies the presence of drugs that patient has taken and that may interfere with the analysis of the specimen.
It could be combined with the artificial blood attribute, as “Potential Interferences”.
10/17/01 – dsc - Ben Schoenprun will follow up with Andre on this item to see if it should be removed. Ben to email the list server with details.
10/21/01 – This is still poorly defined and in 99% of cases will never be known by the orderer let alone captured in any way at the time of order. If this is of critical interest to the testing laboratory, then the medication observations shold be sent with the lab order message so that the determination can be made from actual records as opposed to spurious information captured (or not) at order entry. What is even more disconcerting about this field is the use of the term “potential”. This lends little credibility to the data. I still recommend removing it.
OO 10/31/01: Prior discussion that various interfering compounds could be rolled together into OBXs rather than maintained as attributes of SPM. Discussion on the need for narrative to direct the user to use OBXs for interfering compounds. Such narrative will be developed and forwarded to LabAuto to see how this has implications for them.
11/6/01 JTC Interference as far as I know is still in the SAC (SAC-41, drug interference). The reason this was placed in the SPM to begin with was to accomodate the needs of lab automation. Thus, exclusion of it from the SPM should have no effect on its current status and therefore no expalnation of why it is not in the SPM is needed...correct? If it had never been proposed, it would still have been in the SAC, so there is no functional change. So why do we need an explanatory narrative?
Table Listings
4.20.3 HL7 Table nnnn – Specimen Type
HL7 table nnnn – specimen type
|CD Value |CD Description |Category |Comment |
|ABS |Abscess | | |
|PELVA |Abscess, Pelvic |Condition | |
|PERIA |Abscess, Perianal |Condition |Abscess & Body Part |
|RECTA |Abscess, Rectal |Condition | |
|SCROA |Abscess, Scrotal |Condition | |
|SUBMA |Abscess, Submandibular |Condition | |
|SUBMX |Abscess, Submaxillary |Condition | |
|TSTES |Abscess, Testicular |Condition | |
|AIRS |Air Sample |Environment | |
|ALL |Allograft |Tissue | |
|AMP |Amputation |Tissue | |
|GASAN |Antrum, Gastric |Tissue | |
|ASP |Aspirate | | |
|ETA |Aspirate, Endotrach |Aspirate | |
|GASA |Aspirate, Gastric |Aspirate | |
|NGASP |Aspirate, Nasogastric |Aspirate | |
|TASP |Aspirate, Tracheal |Aspirate | |
|TTRA |Aspirate, Transtracheal |Aspirate | |
|AUTP |Autopsy |Tissue | |
|BX |Biopsy |Tissue | |
|GSPEC |Biopsy, Gastric |Tissue | |
|SKBP |Biopsy, Skin |Tissue | |
|CONE |Biospy, Cone |Tissue | |
|BITE |Bite |Conditions | |
|CBITE |Bite, Cat |Conditions | |
| |Bite, Dog |Conditions | |
| |Bite, Human |Conditions | |
| |Bite, Insect |Conditions | |
| |Bite, Reptile |Conditions | |
|BLEB |Bleb |Fluid/Tissue |Condition |
|BLIST |Blister |Fluid/Tissue |Condition |
|BBL |Blood bag |Blood | |
|BPU |Blood product unit |Blood | |
|HBLUD |Blood, Autopsy |Blood | |
|CSVR |Blood, Cell Saver |Transfusion | |
|FBLOOD |Blood, Fetal |Blood | |
|MBLD |Blood, Menstrual |Blood | |
|WB |Blood, Whole |Blood | |
|BOIL |Boil |Condition | |
|BON |Bone | | |
|BOWL |Bowel contents |Condition | |
|BRTH |Breath (use EXHLD) | | |
|BRSH |Brush |Product |Brush or brushing (these may be 2 |
| | | |separate entries as in a physical brush|
| | | |or a portion thereof vs the substance |
| | | |obtained after a surface has been |
| | | |brushed) |
|EBRUSH |Brush, Esophageal |Product | |
| |Brushing |Product | |
|GASBR |Brushing, Gastric |Product | |
|BUB |Bubo |Condition | |
|BULLA |Bulla/Bullae |Condition | |
|BRN |Burn | | |
|CALC |Calculus (=Stone) | | |
|CARBU |Carbuncle |Condition | |
|CAT |Catheter |Device | |
| |Catheter Insertion Site |Device | |
|CTP |Catheter tip |Device | |
|ANGI |Catheter Tip, Angio |Device | |
|ARTC |Catheter Tip, Arterial |Device | |
|CVPT |Catheter Tip, CVP |Device | |
|ETTP |Catheter Tip, Endotracheal |Device | |
|FOLEY |Catheter Tip, Foley |Device | |
|HEMAQ |Catheter Tip, Hemaquit |Device | |
|HEMO |Catheter Tip, Hemovac |Device | |
|IDC |Catheter Tip, Indwelling |Device | |
|INTRD |Catheter Tip, Introducer |Device | |
|IVCAT |Catheter Tip, IV |Device | |
|MAHUR |Catheter Tip, Makurkour |Device | |
|SCLV |Catheter Tip, Subclavian |Device | |
|SPRP |Catheter Tip, Suprapubic |Device | |
|SWGZ |Catheter Tip, Swan Gantz |Device | |
|VASTIP |Catheter Tip, Vas |Device | |
|VENT |Catheter Tip, Ventricular |Device | |
|GROSH |Catheter, Groshong |Device | |
|HIC |Catheter, Hickman |Device | |
|PORTA |Catheter, Porta |Device | |
|SPRPB |Cathether Tip, Suprapubic |Device | |
|TLC |Cathether Tip, Triple Lumen |Device | |
|CLIPP |Clippings |Condition | |
|COL |Colostrum | | |
|CNJT |Conjunctiva | | |
|LENS1 |Contact Lens |Device | |
|LENS2 |Contact Lens Case |Device | |
|CYST |Cyst | | |
|BCYST |Cyst, Baker's |Condition | |
|ICYST |Cyst, Inclusion |Condition | |
|PILOC |Cyst, Pilonidal |Condition | |
|RENALC |Cyst, Renal |Condition | |
| |Dialysate |Condition | |
|DISCHG |Discharge |Condition | |
|DIV |Diverticulum |Condition | |
|DRN |Drain | | |
|DRN |Drain |Device | |
|HEV |Drain, Hemovac |Device | |
|GTUBE |Drainage Tube, Drainage (Gastrostomy) |Condition | |
|GASD |Drainage, Gastric |Condition | |
|ILEO |Drainage, Ileostomy |Condition | |
|JP |Drainage, Jackson Pratt |Condition | |
|JEJU |Drainage, Jejunal |Condition | |
|NASDR |Drainage, Nasal |Condition | |
|NGAST |Drainage, Nasogastric |Condition | |
|PND |Drainage, Penile |Condition | |
|DRNGP |Drainage, Penrose |Condition | |
|RECT |Drainage, Rectal |Condition | |
|SUMP |Drainage, Sump |Condition | |
|DRNG |Drainage, Tube |Device | |
|EARW |Ear wax (cerumen) | | |
|EFFUS |Effusion |Condition | |
|ELT |Electrode | | |
|AUTOC |Environment, Attest |Environment | |
| |Environmental, Autoclave Ampule |Environment | |
|ISL |Environmental, Autoclave Capsule |Environment | |
|EFF |Environmental, Effluent |Environment | |
| |Environmental, Eye Wash |Environment | |
| |Environmental, Food |Environment | |
| |Environmental, Isolette |Environment | |
| |Environmental, Other Substance |Environment | (Substance is Known but not in code |
| | | |Table) |
| |Environmental, Soil |Environment | |
| |Environmental, Solution (Sterile) |Environment | |
|SPS |Environmental, Spore Strip |Environment | |
|STER |Environmental, Sterrad |Environment | |
|ENVIR |Environmental, Unidentified Substance |Environment | |
| |Environmental, Water |Environment | |
|DEION |Environmental, Water (Deionized) |Environment | |
| |Environmental, Water (Tap) |Environment | |
|FAW |Environmental, Water (Well) |Environment | |
| |Environmental, Water (Ocean) |Environment |
| |Environmental, Whirlpool |Environment | |
|EXUDTE |Exudate |Condition | |
|FLT |Filter | | |
|FIST |Fistula | | |
|FLUID |Fluid |Fluid | |
|FGA |Fluid, Abdomen |Fluid | |
|CSMY |Fluid, Cystostomy Tube |Fluid | |
| |Fluid, Acne |Fluid | |
|FLU |Fluid, Body unsp | | |
|CST |Fluid, Cyst |Fluid | |
|HYDC |Fluid, Hydrocele |Fluid | |
|IVFLD |Fluid, IV |Fluid | |
|JNTFLD |Fluid, Joint |Fluid | |
|KIDFLD |Fluid, Kidney |Fluid | |
|LSAC |Fluid, Lumbar Sac |Fluid | |
|FLD |Fluid, Other |Fluid | |
|PCFL |Fluid, Pericardial | | |
|RENC |Fluid, Renal Cyst |Fluid | |
|FRS |Fluid, Respiratory |Fluid | |
|SHUNT |Fluid, Shunt |Fluid | |
|SNV |Fluid, synovial (Joint fluid) | | |
|GAST |Fluid/contents, Gastric | | |
|FUR |Furuncle |Condition | |
|GAS |Gas | | |
|EXG |Gas, exhaled (=breath) | | |
|IHG |Gas, Inhaled | | |
|GENV |Genital vaginal | | |
|GRAFT |Graft |Condition | |
|GRAFT |Graft Site |Condition | |
|POPGS |Graft Site, Popliteal |Condition | |
|POPLG |Graft, Popliteal |Condition | |
|GRANU |Granuloma |Condition | |
|IMP |Implant |Device | |
|INFIL |Infiltrate |Condition | |
| |Insect |Object | |
|IUD |Intrauterine Device |Device |Common Usage |
|IT |Intubation tube | | |
|KELOI |Lavage |Product | |
|LAVG |Lavage, Bronhial |Product | |
|LAVGG |Lavage, Gastric |Product | |
|LAVGP |Lavage, Peritoneal |Product | |
| |Lavage, Pre-Bronch |Product | |
|LESN |Lesion |Condition | |
|ORL |Lesion, Oral |Condition |Common Usage |
|PENIL |Lesion, Penile |Condition |Common Usage |
| |Liquid, Other | | |
| |Liquid, Unspecified | | |
|MASS |Mass |Condition | |
|SMM |Mass, Sub-Mandibular |Condition | |
|MUCOS |Mucosa |Condition | |
|MUCUS |Mucus |Condition | |
|NEDL |Needle |Device | |
|NODUL |Nodule(s) |Condition | |
|CYN |Nodule, Cystic |Condition | |
|ORH |Other | | |
|PACEM |Pacemaker |Device | |
| |Plant Material |Object | |
|PLAS |Plasma |Blood | |
|PLB |Plasma bag |Blood | |
|PPP |Plasma, Platelet poor |Blood | |
|PRP |Plasma, Platelet rich |Blood | |
|POL |Polyps |Condition | |
|PROST |Prosthetic Device |Device | |
| PSC |Pseudocyst |Condition | |
|PUS |Pus | | |
|PUST |Pus |Condition |Might change to Exudates, Pus |
|PUSFR |Pustule |Condition | |
|QC3 |Quality Control |Environment | |
|RES |Respiratory |Condition |Ambiguous |
|SAL |Saliva | | |
|FSCLP |Scalp, Fetal |Condition |Ambiguous |
| |Scratch, Cat |Condition | |
|SECRE |Secretion(s) |Fluid/Secretion | |
|NSECR |Secretion, Nasal |Condition | |
|SER |Serum | | |
|ASERU |Serum, Acute |Blood | |
|CSERU |Serum, Convalescent |Blood | |
|PLEVS |Serum, Peak Level |Blood | |
| |Serum, Trough |Blood | |
|SHUNT |Shunt |Condition | |
|EXS |Shunt, External |Condition | |
|SITE |Site |Site | |
|CVPS |Site, CVP |Site | |
|INCI |Site, Incision/Surgical |Site | |
|NGS |Site, Naso/Gastric |Site | |
|NEPH |Site, Nephrostomy |Site | |
|PIS |Site, Pacemaker Insetion |Site | |
|PDSIT |Site, Peritoneal Dialysis |Site | |
|PDTS |Site, Peritoneal Dialysis Tunnel |Site | |
|PINS |Site, Pin |Site | |
|POPLV |Site, Popliteal Vein |Site | |
|SHU |Site, Shunt |Site | |
|TRAC |Site, Tracheostomy |Site | |
|SKN |Skin | | |
|TZANC |Smear, Tzanck | | |
|GSOL |Solution, Gastrostomy |Product | |
| |Source of Specimen Is Illegible | | |
| |Source, Other | | |
| |Source, Unidentified | | |
| |Source, Unspecified | | |
|SPRM |Spermatozoa | | |
|SPT |Sputum | | |
|SPTC |Sputum - coughed | | |
|SPTT |Sputum - tracheal aspirate | | |
|DCS |Sputum, Deep Cough |Condition | |
|SPUTIN |Sputum, Inducted |Condition | |
|SPUT1 |Sputum, Simulated |Condition | |
|SPUTSP |Sputum, Spontaneous |Condition | |
|STONE |Stone, Kidney |Condition | |
|STL |Stool = Fecal | | |
|SUP |Suprapubic Tap |Product |Additional Discussion |
|SUTUR |Suture |Object | |
|TISS |Tissue | | |
|TISU |Tissue ulcer | | |
|ACNE |Tissue, Acne |Tissue | |
|HERNI |Tissue, Herniated |Tissue | |
| |Tissue, Keloid (Scar) |Tissue | |
|TRANS |Transudate |Condition | |
|ETTUB |Tube, Endotracheal |Device | |
|GT |Tube, Gastric |Device | |
|TUBES |Tubes |Device | |
|IVTIP |Tubing Tip, IV |Device | |
|TUMOR |Tumor |Condition | |
|DEC |Ulcer, Decubitus |Condition | |
|UR |Urine | | |
|URT |Urine catheter | | |
|URC |Urine clean catch | | |
|URINB |Urine, Bladder Washings |Condition | |
| |Urine, Catheterized |Condition | |
|USCOP |Urine, Cystoscopy |Condition | |
|URINM |Urine, Midstream |Condition | |
| |Urine, Nephrostomy |Condition | |
| |Urine, Pedibag |Device | |
|RANDU |Urine, Random |Condition | |
|VITF |Vitreous Fluid | | |
|VOM |Vomitus | | |
|WRT |Wart |Tissue | |
|WASH |Wash |Product | |
| |Washing, e.g. bronchial washing |Product | |
|WAT |Water | | |
|WEN |Wen |Tissue | |
|WICK |Wick | | |
| |Worm |Object | |
|WND |Wound | | |
|WNDA |Wound abscess | | |
|WNDD |Wound drainage | | |
|WNDE |Wound exudate | | |
|PUNCT |Wound, Puncture |Condition | |
| | | | |
4.20.4 HL7 Table 0371 – Additive/Preservative
HL7 Table 0371 – Additive/Preservative
|Value |Description |Comment |
|F10 |10% Formalin |Tissue preservative |
|C32 |3.2% Citrate |Blue top tube |
|C38 |3.8% Citrate |Blue top tube |
|HCL6 |6N HCL |24 HR Urine Additive |
|ACDA |ACD Solution A |Yellow top tube |
|ACDB |ACD Solution B |Yellow top tube |
|ACET |Acetic Acid |Urine preservative |
|AMIES |Amies transport medium |Protozoa |
|HEPA |Ammonium heparin |Green top tube |
|BACTM |Bacterial Transport medium |Microbiological culture |
|BOR |Borate Boric Acid |24HR Urine Additive |
|BOUIN |Bouin's solution |Tissue |
|BF10 |Buffered 10% formalin |Tissue |
|WEST |Buffered Citrate (Westergren Sedimentation Rate) |Black top tube |
|BSKM |Buffered skim milk |Viral isolation |
|CARS |Carson's Modified 10% formalin |Tissue |
|CARY |Cary Blair Medium |Stool Cultures |
|CHLTM |Chlamydia transport medium |Chlamydia culture |
|CTAD |CTAD (this should be spelled out if not universally |Blue top tube |
| |understood) | |
|ENT |Enteric bacteria transport medium |Bacterial culture |
|ENT+ |Enteric plus |Stool Cultures |
|JKM |Jones Kendrick Medium |Bordetella pertussis |
|KARN |Karnovsky's fixative |Tissue |
|LIA |Lithium iodoacetate |Gray top tube |
|HEPL |Lithium/Li Heparin |Green top tube |
|M4 |M4 |Microbiological culture |
|M4RT |M4-RT |Microbiological culture |
|M5 |M5 |Microbiological culture |
|MICHTM |Michel's transport medium |IF tests |
|MMDTM |MMD transport medium |Immunofluorescence |
|HNO3 |Nitric Acid |Urine |
|NONE |None |Red or Pink top tube |
|PAGE |Pages's Saline |Acanthaoemba |
|PHENOL |Phenol |24 Hr Urine Additive |
|KOX |Potassium Oxalate |Gray top tube |
|EDTK |Potassium/K EDTA |Deprecated. Replaced by EDTK15 and EDTK75 |
|EDTK15 |Potassium/K EDTA 15% |Purple top tube |
|EDTK75 |Potassium/K EDTA 7.5% |Purple top tube |
|PVA |PVA (polyvinylalcohol) |O&P |
|RLM |Reagan Lowe Medium |Bordetella pertussis cultures |
|SST |Serum Separator Tube (Polymer Gel) |‘Tiger’ Top tube |
|SILICA |Siliceous earth, 12 mg |Gray top tube |
|NAF |Sodium Fluoride |Gray top tube |
|FL100 |Sodium Fluoride, 100mg |Urine |
|FL10 |Sodium Fluoride, 10mg |Urine |
|NAPS |Sodium polyanethol sulfonate 0.35% in 0.85% sodium |Yellow (Blood Culture) |
| |chloride | |
|HEPN |Sodium/Na Heparin |Green top tube |
|EDTN |Sodium/Na EDTA |Dark Blue top tube |
|SPS |SPS(this should be spelled out if not universally |Anticoagulant w/o bacteriocidal properties |
| |understood) | |
|STUTM |Stuart transport medium |Bacterial culture |
|THROM |Thrombin |Orange or Grey/Yellow (STAT Chem) |
|FDP |Thrombin NIH; soybean trypsin inhibitor (Fibrin |Dark Blue top tube |
| |Degradation Products) | |
|THYMOL |Thymol |24 Hr Urine Additive |
|THYO |Thyoglycollate broth |Bacterial Isolation |
|TOLU |Toluene |24 Hr Urine Additive |
|URETM |Ureaplasma transport medium |Ureaplasma culture |
|VIRTM |Viral Transport medium |Virus cultures |
4.20.5 HL7 Table nnnn – Specimen Collection Method
HL7 table nnnn – Specimen Collection Method
|Value |Description |
|FNA |Aspiration, Fine Needle |
| |Aterial puncture |
| |Biopsy |
| |Blood Culture, Aerobic Bottle |
| |Blood Culture, Anaerobic Bottle |
| |Blood Culture, Pediatric Bottle |
|CAP |Capillary Specimen |
|CATH |Catheterized |
| |Environmental, Plate |
| |Environmental, Swab |
|LNA |Line, Arterial |
|CVP |Line, CVP |
|LNV |Line, Venous |
|MARTL |Martin-Lewis Agar |
|ML11 |Mod. Martin-Lewis Agar |
| |Pace, Gen-Probe |
| |Pinworm Prep |
|KOFFP |Plate, Cough |
| |Plate, Martin-Lewis |
| |Plate, New York City |
| |Plate, Thayer-Martin |
| |Plates, Anaerobic |
| |Plates, Blood Agar |
|PRIME |Pump Prime |
|PUMP |Pump Specimen |
|QC5 |Quality Control For Micro |
|SCLP |Scalp, Fetal Vein |
|SCRAPS |Scrapings |
| |Shaving |
| |Swab |
| |Swab, Dacron tipped |
|WOOD |Swab, Wooden Shaft |
| |Transport Media, |
| |Transport Media, |
| |Transport Media, Anaerobic |
| |Transport Media, Chalamydia |
| |Transport Media, M4 |
| |Transport Media, Mycoplasma |
| |Transport Media, PVA |
| |Transport Media, Stool Culture |
| |Transport Media, Ureaplasma |
| |Transport Media, Viral |
|VENIP |Venipuncture |
4.20.6 HL7 Table nnnn – Body Site Modifier
HL7 table nnnn – Body Site Modifier
|Value |Description |
| |Anterior |
| |Bilateral |
| |Distal |
| |External |
| |Lateral |
|L |Left |
| |Lower |
| |Medial |
| |Posterior |
| |Proximal |
|LLQ |Quadrant, Left Lower |
|LUQ |Quadrant, Left Upper |
|RLQ |Quadrant, Right Lower |
|RUQ |Quadrant, Right Upper |
|R |Right |
| |Upper |
Specimen Container Segment – All deleted, to be handled by LAPOCT
Potential Additions for body parts Under Investigation
The following table has 454 entries under investigation as possible values for the new table. NOTE: This is raw data; work is just beginning on its analysis. For example, duplications and similarities have not been weeded out.
13.3.3 SSU/ACK - specimen status update (event U03)
This message is used to send information concerning the location and status of specimens from one application to another (e.g., automated equipment to a Laboratory Automation System). The OBX segments attached to the SAC should be used for transfer of information not included in the SAC segment.
|SSU^U03^SSU_U03 |Specimen Status Message |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ SAC |Specimen Container Detail |13 |
| { [ OBX ] } |Observation Result |7 |
| { | | |
| [ SPM ] |Specimen |? |
| { [ OBX ] } |Observation Result |7 |
| } | | |
|} | | |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of SSU^U03 to include SPM.
13.3.4 SSR/ACK - specimen status request (event U04)
This message is used to request information concerning the location and status of specimens from one application to another (e.g., Laboratory Automation System to automated equipment). The request can be addressed for a specific container, a specific carrier, a specific tray or a specific location, depending on the arguments set in the SAC segment. The equipment specified in the EQU segment should respond with the “Specimen Status Update.”
|SSR^U04^SSR_U04 |Specimen Status Message |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ SAC |Specimen Container Detail |13 |
| { [ SPM ] } |Specimen |? |
|} | | |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of SSU^U04 to include SPM.
13.3.7 EAC/ACK – automated equipment command (event U07)
This message is used to send equipment commands from one application to another (e.g., a Laboratory Automation System to an automated Equipment).
|EAC^U07^EAC_U07 |Equipment Command Message |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ ECD |Equipment Command Detail |13 |
| [ SAC ] |Specimen Container Detail |13 |
| [ | | |
| SAC |Specimen Container Detail |13 |
| { [ SPM ] } |Specimen Segment |7 |
| ] | | |
| [ CNS ] |Clear Notification |13 |
|} | | |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of SSU^U04 to include SPM.
13.3.8 EAR/ACK – automated equipment response (event U08)
This message is used to send equipment responses to previously issued commands from one application to another (e.g., automated Equipment to a Laboratory Automation System).
|EAR^U08^EAR_U08 |Equipment Command Message |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ ECD |Equipment Command Detail |13 |
| [ SAC ] |Specimen Continer Detail |13 |
| [ | | |
| SAC |Specimen Container Detail |13 |
| { [ SPM ] } |Specimen |? |
| ] | | |
| ECR } |Equipment Command Response |13 |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of EAR^U08 to include SPM.
13.3.10 TCU/ACK - automated equipment test code settings update (event U10)
This message is used to send information concerning test codes and parameters from one application to another (e.g., automated equipment to a Laboratory Automation System). This message transfers the current snapshot of the test parameters of the sending system. The sent parameter sets are supposed to replace the parameter sets existing at the receiver of this message before the trigger (there is no selective “Add” or “Delete”).
|TCU^U10^TCU_U10 |Test Code Settings Update |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ TCC } |Test Code Configuration |13 |
|{ | | |
| TCC |Test Code Configuration |13 |
| [ SPM ] |Specimen Segment |7 |
|} | | |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of TCU^U10 to include SPM.
10/14/01 smr – revised structure from Lab suggestion of { [ SPM ] { TCC } } to { TCC [ SPM ] }. It appears to me that the SPM would be subordinate to TCC if the SPM is present. Also, it is generally preferred to have the anchor segment appear first in a segment group.
13.3.11 TCR/ACK - automated equipment test code settings request (event U11)
This message is used to request information concerning test codes from one application to another (e.g., Laboratory Automation System to automated equipment).
|TCR^U11^TCU_U10 |Test Code Settings Request |Chapter |
|MSH |Message Header |2 |
|EQU |Equipment Detail |13 |
|{ TCC } |Test Code Configuration |13 |
|{ | | |
| TCC |Test Code Configuration |13 |
| [ SPM ] |Specimen Segment |7 |
|} | | |
|[ ROL ] |Role Detail |12 |
Issues, Notes, Comments & Discussion
Lab 10/3/01 – suggested revision of TCR^U11 to include SPM.
10/14/01 smr – revised structure from Lab suggestion of { [ SPM ] { TCC } } to { TCC [ SPM ] }. It appears to me that the SPM would be subordinate to TCC if the SPM is present. Also, it is generally preferred to have the anchor segment appear first in a segment group.
Potential Additions
| Value |Description |
| |Abdomen |
|ACET |Acetabulum |
|ACHIL |Achilles |
|ADE |Adenoids |
|ADR |Adrenal |
|AMN |Amniotic fluid |
|AMS |Amniotic Sac |
|ANAL |Anal |
|ANKL |Ankle |
|ANTEC |Antecubital |
| |Antecubital Fossa |
|ANTR |Antrum |
|ANUS |Anus |
|AORTA |Aorta |
|AR |Aortic Rim |
|AV |Aortic Valve |
|APDX |Appendix |
|AREO |Areola |
|ARM |Arm |
|ARTE |Artery |
|ASCIT |Ascites |
|ASCT |Ascitic Fluid |
|ATR |Atrium |
|AURI |Auricular |
|AXI |Axilla |
|BACK |Back |
|BARTD |Bartholin Duct |
|BARTG |Bartholin Gland |
|BRTGF |Bartholin Gland Fluid |
|BPH |Basophils |
|BID |Bile Duct |
|BIFL |Bile fluid |
|BLAD |Bladder |
|BLOOD |Blood |
|BLDA |Blood, Arterial |
|BLDC |Blood, Capillary |
|BLDV |Blood, Venous |
|CBLD |Blood, Cord |
|BLD |Blood, Whole |
|BDY |Body, Whole |
|BON |Bone |
|BMAR |Bone marrow |
|BOWEL |Bowel |
|BOWLA |Bowel, Large |
|BOWSM |Bowel, Small |
|BRA |Brachial |
|BRAIN |Brain |
|BCYS |Brain Cyst Fluid |
|BRST |Breast |
|BRSTFL |Breast fluid |
|BRO |Bronchial |
|BROCH |Bronchiole/Bronchiolar |
|BRONC |Bronchus/Bronchial |
|BRV |Broviac |
|BUCCA |Buccal |
|BURSA |Bursa |
|BURSF |Bursa Fluid |
|BUTT |Buttocks |
|CALF |Calf |
|CANAL |Canal |
|CANLI |Canaliculis |
|CNL |Cannula |
|CANTH |Canthus |
|CDM |Cardiac Muscle |
|CARO |Carotid |
| |Carpal |
|CAVIT |Cavity |
|CHE |Cavity, Chest |
|CECUM |Cecum/Cecal |
|CSF |Cerebral Spinal Fluid |
|CVX |Cervix |
|CERVUT |Cervix/Uterus |
|CHEEK |Cheek |
| |Chest |
| |Chest Tube |
|CHIN |Chin |
|CIRCU |Circumcision Site |
| |Clavicle |
|CLAVI |Clavicle/Clavicular |
|CLITO |Clitoral |
|CLIT |Clitoris |
|COCCG |Coccygeal |
|COCCY |Coccyx |
|COLON |Colon |
| |Colostomy |
|COS |Colostomy Stoma |
|CDUCT |Common Duct |
|CONJ |Conjunctiva |
|CORAL |Coral |
|COR |Cord |
|CORD |Cord Blood |
|CORN |Cornea |
| |Cranium, ethmoid |
| |Cranium, frontal |
| |Cranium, occipital |
| |Cranium, parietal |
| |Cranium, sphenoid |
| |Cranium, temporal |
|CUBIT |Cubitus |
|CUFF |Cuff |
|CULD |Cul De Sac |
|CULDO |Culdocentesis |
| |Deltoid |
|DENTA |Dental |
|DEN |Dental Gingiva |
|DIAF |Dialysis Fluid |
|DPH |Diaphragm |
|DIGIT |Digit |
|DISC |Disc |
|DORS |Dorsum/Dorsal |
|DUFL |Duodenal Fluid |
|DUODE |Duodenum/Duodenal |
|DUR |Dura |
|EAR |Ear |
| |Ear bone, incus |
| |Ear bone, malleus |
| |Ear bone,stapes |
|EARLO |Ear Lobe |
| |Ear(s) |
|ELBOW |Elbow |
| |Elbow Joint |
|ENDC |Endocardium |
|EC |Endocervical |
| |endolpthamitis |
|ENDM |Endometrium |
|ET |Endotracheal |
|EUR |Endourethral |
|EOS |Eosinophils |
|EPICA |Epicardial |
|EPICM |Epicardium |
|EPD |Epididymis |
|EPIDU |Epidural |
|EPIGL |Epiglottis |
|ESOPG |Esophageal |
|ESO |Esophagus |
|ETHMO |Ethmoid |
| |External Jugular |
|EYE |Eye |
|BROW |Eyebrow |
|EYELI |Eyelid |
|FACE |Face |
| |Facial bone, inferior nasal concha|
| |Facial bone, lacrimal |
| |Facial bone, maxilla |
| |Facial bone, nasal |
| |Facial bone, palatine |
| |Facial bone, vomer |
| |Facial bone, zygomatic |
|FALLT |Fallopian Tube |
|FEMOR |Femoral |
|FMH |Femoral Head |
|FEMUR |Femur |
|FET |Fetus |
|FIBU |Fibula |
|FING |Finger |
| |Finger Nail |
|FOL |Follicle |
|FOOT |Foot |
| |Forearm |
|FOREH |Forehead |
|FORES |Foreskin |
|FOURC |Fourchette |
|GB |Gall Bladder |
|GEN |Genital |
|GVU |Genital - Vulva |
|GENC |Genital Cervix |
|GL |Genital Lesion |
|GENL |Genital Lochia |
|GLAND |Gland |
|GLANS |Glans |
|GLUTE |Gluteal |
|GLUT |Gluteus |
| |Gluteus Medius |
|GROIN |Groin |
|GUM |Gum |
|HAR |Hair |
|HAL |Hallux |
|HAND |Hand |
|HEAD |Head |
|HART |Heart |
|HV |Heart Valve |
|HVB |Heart Valve, Bicuspid |
|HVT |Heart Valve, Tricuspid |
|HEEL |Heel |
|HEM |Hemorrhoid |
|HIP |Hip |
| |Hip Joint |
|HUMER |Humerus |
|HYMEN |Hymen |
|ILC |Ileal Conduit |
|ILE |Ileal Loop |
|ILEOS |Ileostomy |
|ILEUM |Ileum |
|ILIAC |Iliac |
|ILCR |Iliac Crest |
|ILCON |Ilical Conduit |
|INGUI |Inguinal |
| |Internal Jugular |
|INT |Intestine |
|ICX |Intracervical |
|INASA |Intranasal |
|INTRU |Intrauterine |
|INTRO |Introitus |
|ISCHI |Ischium |
|JAW |Jaw |
| |Kidney |
|KNEE |Knee |
|KNEEF |Knee Fluid |
| |Knee Joint |
|LABIA |Labia |
|LABMA |Labia Majora |
|LABMI |Labia Minora |
|LACRI |Lacrimal |
|LAM |Lamella |
| |Large Intestine |
|LARYN |Larynx |
|LEG |Leg |
|LENS |Lens |
|WBC |Leukocytes |
|LING |Lingual |
|LINGU |Lingula |
| |Lip |
|STOOLL |Liquid Stool |
|LIVER |Liver |
|LOBE |Lobe |
|LOCH |Lochia |
|ISH |Loop, Ishial |
|LUMBA |Lumbar |
|LMN |Lumen |
|LUNG |Lung |
|LN |Lymph Node |
|LNG |Lymph Node, Groin |
|LYM |Lymphocytes |
|MAC |Macrophages |
|MALLE |Malleolus |
|MANDI |Mandible/Mandibular |
|MAR |Marrow |
|MAST |Mastoid |
|MAXIL |Maxilla/Maxillary |
|MAXS |Maxillary Sinus |
|MEATU |Meatus |
|MEC |Meconium |
|MEDST |Mediastinum |
|MEDU |Medullary |
|MOU |Membrane |
|MPB |Meninges |
|METAC |Metacarpal |
|METAT |Metatarsal |
|MILK |Milk, Breast |
|MITRL |Mitral Valve |
|MOLAR |Molar |
|MP |Mons Pubis |
|MONSU |Mons Ureteris |
|MONSV |Mons Veneris(Mons Pubis) |
|MOUTH |Mouth |
|MRSA2 |Mrsa: |
|MYO |Myocardium |
|NAIL |Nail |
|NAILB |Nail Bed |
|NAILF |Nail, Finger |
|NAILT |Nail, Toe |
|NARES |Nares |
|NASL |Nasal |
|NSS |Nasal Septum |
|NLACR |Nasolacrimal |
|NP |Nasopharyngeal |
|NP |Nasopharynx |
|NTRAC |Nasotracheal |
|NAVEL |Navel |
|NECK |Neck |
|NERVE |Nerve |
|NIPPL |Nipple |
|NOSE |Nose |
|NOS |Nose (Nasal Passage) |
|NOSE |Nose(Outside) |
|NOSTR |Nostril |
|OCCIP |Occipital |
|OLECR |Olecranon |
|OMEN |Omentum |
|ORBIT |Orbit/Orbital |
|ORO |Oropharynx |
| |Os coxa (pelvic girdle) |
|OVARY |Ovary |
|PALAT |Palate |
|PLATH |Palate, Hard |
|PLATS |Palate, Soft |
|PALM |Palm |
|PANCR |Pancreas |
|PAFL |Pancreatic Fluid |
|PAS |Parasternal |
|PARAT |Paratracheal |
|PARIE |Parietal |
|PARON |Paronychia |
|PAROT |Parotid |
|PAROT |Parotid Gland |
|PATEL |Patella |
|PELV |Pelvis |
|PENSH |Penile Shaft |
|PENIS |Penis |
|PANAL |Perianal/Perirectal |
|PERI |Pericardial Fluid |
|PCARD |Pericardium |
|PCLIT |Periclitoral |
|PERIH |Perihepatic |
|PNEAL |Perineal |
|PERIN |Perineal Abscess |
|PNEPH |Perinephric |
|PNM |Perineum |
|PORBI |Periorbital |
|PERRA |Perirectal |
|PERIS |Perisplenic |
|PER |Peritoneal |
|PERT |Peritoneal Fluid |
|PERIT |Peritoneum |
|PTONS |Peritonsillar |
|PERIU |Periurethal |
|PERIV |Perivesicular |
| |Phalanyx |
|PILO |Pilonidal |
|PINNA |Pinna |
|PLC |Placenta |
|PLACF |Placenta (Fetal Side) |
|PLACM |Placenta (Maternal Side) |
|PLANT |Plantar |
|PLEUR |Pleura |
|PLEU |Pleural Fluid |
|PLR |Pleural Fluid (Thoracentesis Fld) |
|POPLI |Popliteal |
|PREAU |Preauricular |
|PRERE |Prerenal |
|PRST |Prostate Gland |
|PROS |Prostatic Fluid |
|PUBIC |Pubic |
|PUL |Pulmonary Artery |
|RADI |Radial |
|RADIUS |Radius |
|RECTL |Rectal |
|RECTU |Rectum |
|RBC |Red Blood Cells |
|RENL |Renal |
|RNP |Renal Pelvis |
|RPERI |Retroperitoneal |
|RIB |Rib |
|SACRA |Sacral |
|SACRO |Sacrococcygeal |
|SACIL |Sacroiliac |
|SACRU |Sacrum |
|SALGL |Salivary Gland |
|SCALP |Scalp |
| |Scapula |
|SCAPU |Scapula/Scapular |
|SCLER |Sclera |
|SCROT |Scrotal |
|SCROT |Scrotum |
|SEMN |Semen |
|SEM |Seminal Fluid |
|SEPTU |Septum/Septal |
|SEROM |Seroma |
|SHIN |Shin |
| |Sholder Joint |
|SHOL |Shoulder |
|SIGMO |Sigmoid |
|SINUS |Sinus |
|SKM |Skeletal Muscle |
|SKENE |Skene's Gland |
|SKULL |Skull |
| |Small Intestine |
| |Sole |
|SPRM |Spermatozoa |
|SPHEN |Sphenoid |
|SPCOR |Spinal Cord |
|SPLN |Spleen |
|STERN |Sternal |
| |Sternum |
|STER |Sternum/Sternal |
|STOM |Stoma |
| |Stoma |
|USTOM |Stoma, Urinary |
|STOMA |Stomach |
|STUMP |Stump |
|SCLV |Sub Clavian |
|SDP |Subdiaphramatic |
|SUB |Subdural |
|SUBD |Subdural Fluid |
|SGF |Subgaleal Fluid |
|SUBM |Submandibular |
|SUBX |Submaxillary |
|SUBME |Submental |
|SUBPH |Subphrenic |
|SPX |Supra Cervical |
|SCLAV |Supraclavicle/Supraclavicular |
|SUPRA |Suprapubic |
|SUPB |Suprapubic Specimen |
|SWT |Sweat |
| |Sweat Gland |
|SYNOL |Synovial |
|SYN |Synovial Fluid |
|SYNOV |Synovium |
| |Tarsal |
|TDUCT |Tear Duct |
|TEAR |Tears |
|TEMPL |Temple |
|TEMPO |Temporal |
|TML |Temporal Lobe |
|TESTI |Testicle(Testis) |
|THIGH |Thigh |
|THORA |Thoracentesis |
|THORA |Thorax/Thoracic |
|THRB |Throat |
|THUMB |Thumb |
|TNL |Thumbnail |
|THM |Thymus |
|THYRD |Thyroid |
|TIBIA |Tibia |
|TOE |Toe |
| |Toe Nail |
|TONG |Tongue |
|TONS |Tonsil |
|TOOTH |Tooth |
|TSK |Tooth Socket |
|TRCHE |Trachea/Tracheal |
|TBRON |Transbronchial |
|TCN |Transcarina Asp |
|ULNA |Ulna/Ulnar |
|UMB |Umbilical Blood |
|UMBL |Umbilicus |
|UMBL |Umbilicus/Umbilical |
|URET |Ureter |
|URTH |Urethra |
|UTERI |Uterine |
|SAC |Uterine Cul/De/Sac |
|UTER |Uterus |
|VAGIN |Vagina/Vaginal |
|VCUFF |Vaginal Cuff |
|VGV |Vaginal Vault |
|VAL |Valve |
|VAS |Vas Deferens |
| |Vastus Lateralis |
|VAULT |Vault |
|VEIN |Vein |
| |Ventragluteal |
|VCSF |Ventricular CSF |
|VERMI |Vermis Cerebelli |
| |Vertebra, cervical |
| |Vertebra, lumbar |
| |Vertebra, thoracic |
|VESI |Vesicle |
|VESCL |Vesicular |
|VESFLD |Vesicular Fluid |
|VESTI |Vestibule(Genital) |
|VITR |Vitreous Fluid |
|VOC |Vocal Cord |
|VULVA |Vulva |
|WRIST |Wrist |
Potential Additions for body parts Modifier Under Investigation
The following table has 31 entries under investigation as possible values for the new table. NOTE: This is raw data; work is just beginning on its analysis.
HL7 table nnnn – Body Site Modifier
|Value |Description |
| |Anterior |
| |Anterior chamber |
| |Bilateral |
| |Distal |
| |External |
|FOSSA |Fossa |
|HEP |Hepatic |
|IABD |Intra-Abdominal |
|ICAPS |Intracapsular |
| |Lateral |
|L |Left |
| LOBE |Lobe |
| |Lower |
| |Medial |
|MBACK |Mid-Back |
| |Posterior |
| |Proximal |
|LLQ |Quadrant, Left Lower |
|LUQ |Quadrant, Left Upper |
|RLQ |Quadrant, Right Lower |
|RUQ |Quadrant, Right Upper |
|R |Right |
| |Right Lower Lobe |
| |Right Middle Lobe |
| |Right Upper Lobe |
| |Trans |
| |Upper |
Resolution
We started the discussion on the Specimen proposal. The following questions were raised:
1. Should Chapter 13 even reference SPM?
2. Where does the SPM go into Chapter 4/7 message structures?
3. Cross-reference proposed changes between Chapter 4/7 and 13.
4. Augment vs. replace: resolve precedence rules – one SACs with multiple SPMs; one SAC with one SPM; other? Initial proposal: When multiple SPMs used for one SAC, then the SAC fields that also exist in SPM should be blank. If only one SPM with SAC, then if both are valued then they must be the same.
5. Resolve interference representation SAC vs. OBX.
Action: LAPOCT to follow-up with Jim Case and Ken McCaslin. Target for Friday review.
Proposal 190
We agreed for Lloyd to talk with LAPOCT and pick up the discussion on Friday.
Proposal – Blood Bank
Patient Related Blood Product Messages
Transfusion service Transaction flow DIAGRAM
The following diagram depicts the message flow of the blood product messages.
Blood Product Order Message from Placer
(Trigger Event O26)
OMB
Acknowledgement from Filler
(Trigger Event O27)
ORB
Modification to order from placer or filler
(Trigger Event O26)
OMB OMB
Acknowledgement from filler or placer
(Trigger Event O27)
ORB ORB
Blood Product Dispense Status Message - Blood Product Ready to Dispense (RD) from filler
(Trigger Event O28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Blood Product Dispense Message - Blood Product Dispensed (DI)
(Trigger Event 28)
BPD
Acknowledgement by placer
(Trigger Event O29)
BRP
Request to Dispense Blood Product Message (RQ)
(Trigger Event 28)
BPD
Acknowledgement by filler
(Trigger Event O29)
BRP
Complete Transfusion/Disposition by placer
(Trigger Event O30)
BTS
Acknowledgement by filler
(Trigger Event O31)
BRT
Blood Bank trigger events and messages
Usage notes for transfusion service 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 must 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 use the OMB message with the BPO segment for the detail segment and the acknowledgment message, ORB as described below.
|OMB^O26^OMB_O26 |Blood Product Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit – Additional Info |3 |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for Order) |2 |
| [{DG1}] |Diagnosis |6 |
| [{ | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| }] | | |
| [{FT1}] |Financial Transaction |6 |
| [BLG] |Billing Segment |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 |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| }] | | |
| ] | | |
|] | | |
BPD – blood product dispense status message (event O28)
In the pre-transfusion processing of blood products, it is necessary for the transfusion service and the placer system to communicate information that is not included in the current HL7 order/observation model. Examples of pre-transfusion processing include performing a crossmatch test to ensure compatibility with the patient, or irradiation of the blood product due to a special transfusion requirement for the patient. The blood product dispense status messages need to contain additional information regarding the blood products requested, such as the Donation ID, 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, the status messages need to contain additional information, such as the lot number and manufacturer, expiration date and status of the commercial product.
Blood product dispense status messages use the BPS and BRP messages as described below.
|BPS^O28^BPS_O28 |Blood Product dispense status Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for BPO) |2 |
| [{ | | |
| BPX |Blood Product Dispense Status |4 |
| [{NTE}] |Notes and Comments (for BPX) |2 |
| }] | | |
|} | | |
BRP – blood product dispense status acknowledgment (event O29)
|BRP^O29^BRP_O29 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| [{BPX}] |Blood Product dispense status | |
| }] | | |
|] | | |
| | | |
BTS – blood product transfusion/disposition message (event O30)
Blood product transfusion/disposition messages use the BTS and BRT messages as described below.
|BTS^O30^BTS_O30 |Blood Product Transfusion/Disposition Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [PV1 |Patient Visit |3 |
| [PV2]] |Patient Visit - Additional Info |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| BPO |Blood Product Order |4 |
| [{NTE}] |Notes and Comments (for BPO) |2 |
| [{ | | |
| BTX |Blood Product Transfusion/Disposition Status |4 |
| [{NTE}] |Notes and Comments (for BTX) |2 |
| }] | | |
|} | | |
BRT – blood product transfusion/disposition acknowledgment (event O31)
|BRT^O31^BRT_O31 |Description |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Response Header) |2 |
|[ | | |
| [PID] |Patient Identification |3 |
| [{ | | |
| ORC |Common Order |4 |
| [BPO] |Blood Product Order |4 |
| [{BTX}] |Blood Product Transfusion/Disposition Status |4 |
| }] | | |
|] | | |
Blood Bank Segments
BPO – blood product order segment
Blood product order messages require additional information that is not available in other standard HL7 order messages. Blood product 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 presents various use cases surrounding blood product orders.
|Universal Service ID [ISBT-128 Product |Blood Product Processing |Quantity |Blood Product Amount |Units |
|Code] |Requirements | | | |
|002^Red Blood Cells |Leukoreduced |2 | |Ml |
|002^Red Blood Cells |Leukoreduced |1 |60 |Ml |
|002^Red Blood Cells |Irradiated |2 |15 |Ml |
|002^Red Blood Cells |Leukoreduced |1 | | |
|020^Platelets |Leukoreduced |6 | | |
| |Irradiated | | | |
|024^ Apheresis Platelets |Irradiated |1 | | |
|002^Red Blood Cells | |1 | | |
|Factor VIII | |2 |910 |IU |
HL7 Attribute Table – BPO – Blood product order
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|2 |250 |CWE |R | | | |BP Universal Service ID |
|3 |250 |CWE |O |Y |??? | |BP Processing Requirements |
|4 |5 |NM |R | | | |BP Quantity |
|5 |5 |NM |O | | | |BP Amount |
|6 |250 |CE |O | | | |BP Units |
|7 |26 |TS |O | | | |BP Intended Use Date/Time |
|8 |80 |PL |O | | | |BP Intended Dispense From Location |
|9 |250 |XAD |O | | | |BP Intended Dispense From Address |
|10 |26 |TS |O | | | |BP Requested Dispense Date/Time |
|11 |80 |PL |O | | | |BP Requested Dispense To Location |
|12 |250 |XAD |O | | | |BP Requested Dispense To Address |
|13 |250 |CWE |O |Y | | |BP Indication for Use |
|14 |1 |ID |O | |0136 | |BP Informed Consent Indicator |
BPO field definitions
BPO-1 Set ID – BPO (SI)
Definition: This field contains the sequence number for the BPO segment within the message. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
BPO-2 BP Universal service identifier (CWE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the identifier code for the requested blood product. This can be based on local and/or “universal” codes. We recommend the “universal” procedure identifier. The structure of this CWE data type is described in the control section. The preferred coding system is the ISBT 128 Product Code.
Blood Product Orders for commercial products, such as Rh Immune Globulin or Factor VIII concentrate, are not at this time defined in an international or national coding system as are blood products. Therefore, locally defined codes can be used for the Universal Service Identifier for commercial products.
BPO-3 BP Processing requirements (CWE)
Components: ^ ^ ^ ^ ^
Definition: This field contains additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required processing of the blood product that must be completed prior to transfusion to the intended recipient. Examples of blood product processing requirements include CMV Negative, HLA Matched, Irradiated or Leukoreduced. Refer to User-defined Table #### - Blood product processing requirements for suggested values.
User-defined Table #### - Blood product processing requirements
|Value |Description |
|LR |Leukoreduced |
|IR |Irradiated |
|CS |CMV Safe |
|FR |Fresh unit |
|AU |Autologous Unit |
|DI |Directed Unit |
|HL |HLA Matched |
|CM |CMV Negative |
|HB |Hemoglobin S Negative |
|WA |Washed |
|IG |IgA Deficient |
BPO-4 BP Quantity (NM)
Definition: This field contains the number of blood products ordered.
BPO-5 BP Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of blood product.
BPO-6 BP Units (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e. 50 ml) or the units of measure or dosage of a commercial product (i.e. 910 I.U. - International Units - of Factor VIII Concentrate).
BPO-7 BP Intended use date/time (TS)
Definition: This field specifies the date/time that the placer intends to use the blood product that is being ordered.
This is the time when the placer expects the product to be available within the transfusion service. For example, the product should be available for use, but not dispensed on this date/time.
BPO-8 BP Intended dispense from location (PL)
Components: ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of facility: & &
Definition: This field contains the location from which the blood component is to be dispensed.
BPO-9 BP Intended dispense from address (XAD)
Components: ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^ ^
Subcomponents of street address (SAD): & & Subcomponents of address validity range (DR): &
Definition: This field contains the actual address of the location from which the blood component is to be dispensed.
BPO-10 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 time in order to have the blood component ready for transfusion at the scheduled time. The field may also be used to indicate that the placer is now ready to pick up the ordered blood product and is requesting the blood product be ready to dispense at that time.
BPO-11 BP Requested dispense to location (PL)
Components: ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of facility: & &
Definition: This field contains the inpatient or outpatient location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.
BPO-12 BP Requested dispense to address (XAD)
Components: ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^ ^
Subcomponents of street address (SAD): & & Subcomponents of address validity range (DR): &
Definition: This field contains the actual address of the location to which the blood component is to be dispensed. The default dispense to location is the current census location for the patient.
BPO-13 BP Indication for use (CWE)
Components: ^ ^ ^ ^ ^
This is a coded optional field. The value indicates the reason that the blood product was ordered. This information is helpful for prospective review or retrospective studies of blood product ordering practices of the ordering provider by the Quality Assurance Department and/ or Transfusion Committee. Refer to User-defined Table #### - Indication for use for suggested values.
User-defined Table #### – Indication for use
|Value |Description |
| |No suggested values |
BPO-14 BP Informed Consent Indicator (ID)
This field indicates whether consent for the transfusion has been obtained. Refer to HL7 table 0136 -Yes/no indicator as defined in Chapter 2.
BPX – blood product dispense status segment
In the processing of blood products, it is necessary for the transfusion service and the placer system to communicate information. 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.
HL7 Attribute Table – BPX – Blood product dispense status
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|2 |250 |CWE |R | |??? | |BP Dispense Status |
|3 |1 |ID |R | |0085 | |BP Status |
|4 |26 |TS |R | | | |BP Date/Time of Status |
|5 |22 |EI |C | | | |BC Donation ID |
|6 |250 |CNE |C | |? | |BC Component |
|7 |250 |CNE |O | |? | |BC Donation Type / Intended Use |
|8 |250 |CWE |C | |? | |CP Commercial Product |
|9 |250 |XON |C | | | |CP Manufacturer |
|10 |22 |EI |C | | | |CP Lot Number |
|11 |250 |CNE |O | |? | |BP Blood Group |
|12 |250 |CNE |O |Y |? | |BC Special Testing |
|13 |26 |TS |O | | | |BP Expiration Date/Time |
|14 |5 |NM |R | | | |BP Quantity |
|15 |5 |NM |O | | | |BP Amount |
|16 |250 |CE |O | | | |BP Units |
|17 |22 |EI |O | | | |BP Unique ID |
|18 |80 |PL |O | | | |BP Actual Dispensed To Location |
|19 |250 |XAD |O | | | |BP Actual Dispensed To Address |
|20 |250 |XCN |O | | | |BP Dispensed to Receiver |
|21 |250 |XCN |O | | | |BP Dispensing Individual |
BPX field definitions
The BP prefix in the element name indicates that the attribute pertains to any type of blood product. A blood product is defined as any type of blood component or commercially prepared blood product that is prepared and dispensed from the transfusion service.
The BC prefix in the element name indicates that the attribute pertains only to blood components. A blood component is defined as the whole or any part of a blood donation. For example, from one whole blood donation, the unit of whole blood can be fractionated into red blood cells, plasma and platelets with each component contained in separate bags. These types of blood products are assigned a unique donation identification number as well as a product code that indicates the type of component contained in the bag.
The CP prefix in the element name indicates that the attribute pertains only to Commercial Products. A commercial product is defined as a commercially manufactured product, such as blood derivatives ( Rh Immune Globulin, Factor VIII Concentrate or Blood Recipient Sets or Filters). These types of products are tracked by manufacturer and lot number and are not necessarily assigned a unique donation number.
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 Dispense status (CWE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates the current status of the specified blood product as indicated by the filler or placer. For example, the first status change of a product that may trigger a Blood Product Dispense Status Message occurs when it first becomes linked to a patient and is ready to dispense. The placer system may use the Blood Product Dispense Status Message to request the transfusion service to dispense the product. 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.” Refer to HL7 Table #### - Blood product dispense status for valid entries.
HL7 Table #### - Blood product dispense status
|Value |Description |Status determined by Placer(P) |
| | |or Filler (F) |
|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/P |
|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 Status (ID)
Definition: The most commonly used message status 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 (BPX-2) can continue to change and the previous status should be overwritten until it reaches a final status (BPX-3). Refer to HL7 Table #### - BP status codes interpretation for valid entries.
Table #### - BP status codes interpretation
|Value |Description |
|C |Record coming over is a correction and thus replaces a final status |
|D |Deletes the BPX record |
|F |Final status; Can only be changed with a corrected status |
|O |Order detail description only (no status) |
|P |Preliminary status |
|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.
BPX-5 BC Donation ID (EI)
Components: ^ ^ ^
Definition: The Donation ID is the unique identification number assigned to a blood donation. The Donation ID depends upon the bar code labeling system used for the component. There are currently two blood component labeling standards: ABC CODABAR and ISBT 128. The preferred labeling system is ISBT 128. If using ISBT 128, the Donation ID is an internationally unique identifier consisting of the following 13 characters:
Country Code & Collection Facility - 5 characters
Donation Year - 2 characters
Serial Number - 6 characters
This field is required for blood components and is not applicable for commercial product messages.
BPX-6 BC Component (CNE)
Components: ^ ^ ^ ^ ^
Definition: The Component field includes an identifier and description of the specific blood component.
The identifier consists of a numeric or alphanumeric product code that 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 including the component class, donation type/intended use and division indicator.
If using CODABAR product labeling standard, the product code is a 5-digit number.
This field is required for blood components and is not applicable for commercial product messages.
BPX-7 BC Donation type / intended use (CNE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates the type of donation or collection/intended use. This value is populated from Table 5 -Type of Donation in the ISBT 128 Application Specification. The default value is “0”, meaning “Not specified.” Other values indicate whether the blood product (1) is an allogeneic unit from a volunteer donor, (2) is intended for a specific recipient but may be crossed over and used for another recipient, or (3) is an autologous donation intended only for that particular recipient.
This field is optional for blood component messages and is not applicable for commercial product messages.
BPX-8 CP Commercial product (CWE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the code and/or text 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.
Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, a component delimiter must precede free text without a code. Free text can be utilized if no update is to occur. Refer to User-defined Table #### - Commercial product for suggested values.
User-defined Table #### – Commercial product
|Value |Description |
| |No suggested values |
This field is required for commercial blood products and is not applicable for blood component messages.
BPX-9 CP Manufacturer (XON)
Definition: This field identifies the manufacturer of the commercial product. The manufacturer may be different from the supplier of the commercial product.
This field is required for commercial blood products and is not applicable for blood component messages.
BPX-10 CP Lot number (EI)
Components: ^ ^ ^
Definition: This field identifies the lot number for blood derivatives or commercially supplied items used as accessories to transfusion.
This field is required for commercial blood products and is not applicable for blood component messages.
BPX-11 BP Blood group (CNE)
Components: ^ ^ ^ ^ ^
Definition: This field indicates the ABO/Rh blood group of the blood component. The preferred values for the blood group are the specified values in Table 3A - Encodation of ABO/Rh Blood Group in the ISBT 128 Application Specification.
This field is required for blood components and certain commercial products (such as solvent detergent plasma).
BPX-12 BC Special testing (CNE)
Components: ^ ^ ^ ^ ^
Definition: This is a repeating field to allow multiple entries for special testing that was performed on the blood component. The preferred coding system for Special Testing is defined in the ISBT 128 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 I3 - Special Testing Codes of the ISBT 128 Application Specification.
BPX-13 BP Expiration date/time (TS)
Definition: This field 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 transfusion service medical staff.
This field applies to blood components as well as commercial products. There are a few commercial products that have no expiration date. Therefore, the field is not required for those specific products.
BPX-14 BP Quantity (NM)
Definition: This field indicates the number of blood components or commercial products to which this message refers.
BPX-15 BP Amount (NM)
Definition: This field contains the ordered amount (volume) associated with each quantity of a blood component or commercial product to which this message refers.
BPX-16 BP Units (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains the units of measure for the blood product amount. (See Chapter 7 for more details about reporting units.) This field specifies the units of measure for volume of a blood component (i.e. 50 ml) or the units 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: ^ ^ ^
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 Unique ID is the same. If the Blood Product Unique ID is different, it indicates that the status applies to a different blood product.
The sending and receiving systems must agree upon the use of this field.
BPX-18 BP Actual dispensed to location (PL)
Components: ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of facility: & &
Definition: This field contains the inpatient or outpatient location to which the blood product was actually dispensed. The default value is the current census location for the patient.
BPX-19 BP Actual dispensed to address (XAD)
Components: ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^ ^
Subcomponents of street address (SAD): & & Subcomponents of address validity range (DR): &
Definition: This field contains the actual address of the location to which the blood product was actually dispensed.
BPX-20 BP Dispensed to receiver (XCN)
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ < name assembly order (ID)>
Subcomponents of assigning authority: & & ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- scope what include and exclude in 3
- ceus online for social workers psychologists counselors
- the cure for all diseases
- facing the challenges best start
- bellafire farm adga registered nigerian dwarf dairy goats
- home crowville school
- health questionnaire for new patients
- proposal for implementing primary health care
- memo to file
- from the townsend letter
Related searches
- what does the and mean in odds
- what does and mean in betting
- what are periods and groups in chemistry
- include username password in url
- what causes tingling and numbness in toes
- scope for throat and esophagus
- scope of esophagus and stomach
- esophagus scope what to expect
- how to include a file in python
- can you include closing costs in mortgage
- what is debits and credits in accounting
- what to see and do in boston