Scope: What include and exclude in 3
Minutes of September 2000
Orders/Observations Worksession
|Attendee |Company/E-Mail |Mon AM |Mon PM |Tue AM |Tue PM |Wed AM |Wed PM |Thu AM |Thu PM |Fri |
|Liora Alschuler |Liora@the-word- | | |( | | | | | | |
|Kay Avant |Kay.avant@ | | |( | | |( | | | |
|Calvin Beebe |Cbeebe@mayo.edu | | |( | | | | | | |
|Fred Behlen |f-behlen@uchicago.edu | | | |( | | | | | |
|Paul V. Biron |Paul.v.biron@ | | | |( | | | | | |
|Sandy Boyer |Slboyer@ | | |( |( | | | |( | |
|Tina Buckeye |Tina@ | | |( |( |( |( |( |( | |
|Hans Buitendijk |Hans.buitendijk@ |( |( |( |( |( |( |( |( |( |
|Jim Case |Jcase@vols.ucdavis.edu | | |( | |( |( | | |( |
|Carmella Couderc |Carmella.couderc@ | | | |( | | | | | |
|Curt Coulter |Chc@ | | | |( |( | | |( | |
|Amy Danko |Amy.danko@ | | | |( | | | | | |
|Bob Dolin |Robert.h.dolin@ | | |( |( | | | | | |
|Joachim Dudeck |Jwd@uni-giessen.de | | | |( | | | | | |
|Lou Dunka |Ldunka@lfsus. | | | | | |( | | | |
|Shari Dworkin |Sdworkin@cihi.ca | | | |( | | | | | |
|Al Figler |al_figler@ | | | |( | | | | | |
|Jay Gaeta |Gaeta@ | | | |( | | | | | |
|Barry Gordon |Barryg@ | | |( |( | | | |( | |
|Louis R. Gordon |Louis_gordon@ | | | |( | | | | | |
|Kenzo Gushiken |Kenzo.gushiken@ | | | |( | | | | | |
|Dick Harding |Hardingr@health.e.au | | | |( | | | | | |
|Charles Hawker |Hawkercd@ | | | | |( | | | | |
|Masaaki Hirai |Masaaki_hirai@mbt.nkc.co.jp | | | | |( | | | | |
|Frank Howard |Frank.w.howard@ |( |( |( |( |( |( | | |( |
|Stan Huff |Coshuff@ | |( | |( | | | | | |
|Peter Johnson |p.d.johnson@ncl.ac.uk | | | |( | | |( |( | |
|Joan Kapusnik-Uner |Joan_kapusnik@ | | |( |( | | | | | |
|Martin Kernberg |Mkfrad@ | | | |( | | | | | |
|Jerry Kirchner |Jerry.kirchner@ | | |( |( | | | | | |
|Andrzej J. Knafel |Andrzej.knafel@ | | |( | |( |( | | | |
|Helmut König |Helmut.koenig@shs-online.de | | | |( | | | | | |
|Diane Kravec |Diane_kravec@ | | |( |( | | | | | |
|Austin Kreisler |Austin.kreisler@ |( |( |( |( | | |( |( |( |
|Ed Larson |Erlarsen@ | | | |( | | | | | |
|Joann Larson |Joann.larson@ncal. |( |( | | | | | | |( |
|Bill LeClair |Leclair@ | | | | | |( | | | |
|Andrei Leontiev |Andrei_leontiev@ | | | |( | | | | | |
|Michael Macaluso |Michael.macaluso@ | | | | | | | |( | |
|David Markwell |David@clinical-info.co.uk | | | |( | | | | | |
|Tom Marley |Marley@cs.man.ac.uk | | | | | |( |( |( | |
|Ken McCaslin |Kenneth.h.mccaslin@ |( |( | |( |( |( | | |( |
|Charles McCay |Charlie@ramseysystems.co.uk | | | |( | | | | | |
|Clem McDonald |Clem@regen.rg.iupui.edu | | |( |( | | | | | |
|Gary Meyer |Gary.meyer@ | | | | | | | | |( |
|Galen Mulrooney |Mulrooneyg-c@ | | | |( | | | | | |
|Manish Narang |Mnarang@ocdus. | | | | |( |( | | | |
|Thanh-Le Nguyen |Thanhle-nguyen@ | | | | | | | | |( |
|Karen Nocera |Kyn@ | | | | |( | | |( | |
|Herman Oosterwijk |Herman@ | | | |( | | | | | |
|Daniel Pollock |Dap1@ | | | |( | | | | | |
|Alan Rector |Rector@cs.man.ac.uk | | | |( | | | | | |
|Harry Rhodes |Harry.thodes@ | | |( | | | | | | |
|Scott Robertson |Scott.m.robertson@ |( |( | |( | | |( |( |( |
|David Robinson |David.robinson@nhsccc.exec.nhs.uk | | | |( | | | | | |
|Angelo Rossi Mori |Angelo@r.it | | | |( | | | | | |
|Alan Rowberg |Arowberg@ | | | |( | | | | | |
|Dan Russler |Dan.russler@ | | |( | | |( | | | |
|Jerry Sable |Jsable@health.missouri.edu | | | |( | | | | | |
|Gunther Schadow |Schadow@regenstrief.iupui.edu | | |( |( |( |( |( |( |( |
|Karen Sieber |Ksieber@ | | |( |( | | | | | |
|Alan Sim |Asim@ | | | | | | | | |( |
|Doug Sluis |Doug.sluis@ | | | |( | | | | | |
|David Snavely |Dav_snavely@ | | | |( | | | | | |
|Kent Spackman |Spackman@ohsu.edu | | | |( | | | | | |
|Michael Stearns |Mstearn@ | | | |( | | | | | |
|Helen Stevens |Helen.stevens@ |( |( |( |( |( | |( |( |( |
|Sean Sudduth |Sean.sudduth@ | | |( | | | | | | |
|Sadamu Takasaka |S-takasaka@cp.jp. | | | | |( | | | | |
|Timo Tarhonen |Timo.tarhonen@tto.fi | | | | |( |( | | | |
|Alfredo Tirado-Ramos |Atr@philabs.research. | | | |( | | | | | |
|Robin Todino |Rtodino@ | | | |( | | | | | |
|Wayne Tracy |Wrtracy@wrt. |( |( |( | | | |( |( |( |
|Cheryl Tyus |Ctyus@ | | | |( | | | | | |
|Serafina Versaggi |Sversaggi@ | | |( | | | | | | |
|Heather von Allmen |Heather.vonallmen@ |( |( |( |( | |( | |( |( |
|Gina Wade |Gwade@ | | | | | | | | | |
|Steve Wagner |Steve.wagner@med. | | | |( | | | | | |
|Judy Warren |Jjwarren@ | | | | | |( | | | |
|Mead Walker |Mead_walker@ | | | | | | | | |( |
|Andrew Woyak |Andy.woyak@ | | |( | | | | | | |
|Daphne Young |Daphne.young@ |( |( |( |( | |( | |( |( |
Communication with declared O&O participants can be done through ord@lists.. You can sign up on this list through HL7’s home page .
Monday, September 12, 2000
Need to synchronize the Specimen Source discussion with Laboratory, Point of Care, and Automated Testing SIG
V2.x Proposals
Add NK1 Segment to ORM message
Proposal
Add NK1 Segment to ORM message
Summary
This is a request to add the NK1 segment to the ORM message in the next 2.x release of HL7. The NK1 segment was added to the ORU message for unsolicited observation message in HL7 Version 2.3.1, however, it was not included in the ORM. This information is typically gather by the placer and will need to be included in the ORM message particularly when the information is mandated to be reported to state agencies based on specific test requests (example: heavy metals and sexually transmitted diseases.
ORM - general order message (O01)
The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. ORM messages can originate also with a placer, filler, or an interested third party.
The trigger event for this message is any change to an order. Such changes include submission of new orders, cancellations, updates, patient and nonpatient-specific orders, etc.
|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 |
| [{NK1}] |Next of Kin/Associated Parties |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 |
| [ | | |
| Order Detail Segment OBR, | |4 |
|etc. | | |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [{DG1}] |Diagnosis |6 |
| [ | | |
| { | | |
| OBX |Observation/Result |7 |
| [{NTE}] |Notes and Comments (for Results) |2 |
| } | | |
| ] | | |
| ] | | |
| {[CTI]} |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| } | | |
Discussion
Proposal to add to ORM is not valid as the ORM is for ‘backward compatibility only’ as of HL7 2.4.
Wayne: National Cancer Registry also has use case to support implementation of NK1 in ORU messages (ORU already includes NK1). For consistency NK1 should be included in the ‘family’ of order/observation messages.
There are no use cases presented to add NK1 to pharmacy, dietary and supply messages at this time.
Austin Motion: Modify proposal to add NK1 to OML (Laboratory order) and OMG (General order) immediately following the PID/PD1/NTE segments.
Vote: for 14, 0 against
Helen motion: Move the NK1 in the ORU message to follow immediately after the PID/PD1/NTE segments as the NTE applies to the PID/PD1 not the NK1 segment. This is to correct an error in the original placement of the NK1.
Vote: for 14, 0 against
Joann volunteers to raise the issue with CQ of placement of the NTE or the documentation of what segment the NTE applies to.
OBR – Special Instructions Proposal
Problem:
It is unclear where “special instructions” information for a test/service (e.g., draw specimen from left arm) should be transmitted.
At the working group meeting in San Diego we proposed that the Note segment (NTE) be used. This recommendation was not endorsed.
Another solution put forth was to transmit “special instructions in either the ORC-7 or OBR-27 in component-8 “text” of the TQ data type. However, the Orders TC agreed in January 2000 that only quantity or timing information such as “collection time” should be sent in this component. Designation of a proper field for “special instructions” that are neither timing nor quantity issues was tabled until such time as a new proposal could be submitted.
Proposed Solution:
Add a new field “Special Instructions” to the OBR as follows:
OBR - observation request segment
HL7 Attribute Table - OBR
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
| | | | | | | | |
|48 |250 |ST |O | | | |Special instructions |
| | | | | | | | |
Special instructions (ST)
Definition: This field contains any “special instructions” information from the ordering provider to the filler that may be necessary and not elsewhere transmitted for a test/service.
Examples: Draw specimen from left arm; isolation precautions.
NOTE: “Isolation precautions” example needs further evaluation—may overlap with the unfortunately labeled OBR-12 Danger code.
Decision: Use OBR:15 and OBR:12 for specific use cases given. Kaiser to investigate if there are other use cases and re-present.
MDM vs ORU Proposal – Kaiser Permanente
* This proposal was accepted by the Medical Record TC contingent upon approval by Orders and Observation TC
We have been implementing transcription messages at Kaiser Permanente and have found considerable difficulty in interpreting the HL7 Standard. For example, if the reader is looking for direction on what message to use for a transcribed lab pathology report the standard is ambiguous. After reading the Document Management (MDM) messages as described in section 9.4 of chapter 9, it would appear that the MDM message is appropriate, although lab pathology is not a suggested value in user-defined table 0270 Document Type as used in TXA-2 Document Type. Section 7.1 of chapter 7 speaks broadly and vaguely about structured reports. The reader is not referred elsewhere, such as chapter 9, for transcribed reports. Indeed, the presence of a Transcriptionist field in the OBR segment, specifically OBR-35 suggests that the ORU is a valid mechanism for transmitting transcription reports.
We believe that HL7 should clearly and unambiguously designate which message is to be used for transcription; there should not be 2 applicable to the same function.
Problem statement:
The following problems have arisen:
1. We attempted to set the MDM message as our standard for all transcription. We found that we needed to have the ORC/OBR for those transcription results tied to an explicit order, specifically because the MDM message does not contain fields for Ordering Provider and the Ordered Procedure. Consequently, we reverted back to the ORU message for transcription associated with an explicit order. This made our Lab, Radiology, and Electrodiagnostic systems happy because they are familiar with the ORU message. [In the meantime Medical Records TC has approved the inclusion of the ORC/OBR for the next balloting cycle.]
2. We attempted to reserve the MDM for transcription not having an explicit order. Our users have informed us that the distinction is arbitrary. Furthermore, transcription systems may have difficulty sending 2 different messages (MDM and ORU depending on the type of report coming through) when it appears to them that the ORU serves both purposes.
3. We explored abandoning the MDM message in favor of using the ORU for all transcription reports. We discovered that this made sending documents such as Progress Notes and Discharge Summary, unnecessarily cumbersome. We would have difficulty, for example, populating the required OBR segment, especially OBR-4.
4. We explored using both messages but found it was difficult to define when one should be used over the other. There is considerable overlap between the MDM and the ORU without clear language guiding the user. It might be hard to get agreement, for example, as to whether a transcribed Consultation report would require the ORU or the MDM.
Pros of the MDM: It’s concise without unnecessary segments (except the EVN). The segment format and data elements are ideal for documents that are not associated with explicit orders. We are not forced to populate non-relevant segments or fields. The trigger events (T01, T02, ect.) are nice for those who need to use them.
Cons of the MDM: The EVN segment is not necessary. An optional NOTE for OBX segment is missing. Many fields within the ORC or the OBR segments cover much of the information in the TXA segment. Examples:
TXA-7 and TXA-11 can be found in OBR-35;
TXA-9 = OBR-32;
TXA-23 = OBR-28;
TXA-14 = ORC-2 and OBR-2;
TXA-15 = ORC-3 and OBR-3;
Pros of the ORU: For functions of ordered results (as in Lab, EKG, and Radiology), the ORU message is familiar and fits the need exactly. Users are happy to stay with ORU.
Cons of the ORU: If we are dealing with non-ordered results (e.g., medical progress notes, etc.) there are issues with valuing some required fields to contend with. For example: ORC-2 and ORC-3 (or OBR-2 and OBR-3), as well as the OBR-4 fields.
The purpose of the required EVN segment in the MDM is not clear. Our users balk at populating it. There is only one required field (EVN-2), the Recorded Date/Time, which is the same as TXA-7 for a transcribed report. The remaining 5 fields are optional or retained for backward compatibility.
Proposed solution:
1. Add explanatory language to the ORU explaining if and when it should be used as opposed to the MDM. Conversely, add explanatory language to the MDM explaining when it should be used as opposed to the ORU.
2. In the next balloting cycle, the Medical Records TC will propose the inclusion of the ORC/OBR along with new trigger events to accommodate sending Results associated with explicit orders using MDM message. We suggest the removal of the EVN segment from the MDM message requirements.
3. If the ORU is retained as a legitimate transcription message, assign a unique trigger event so that appropriate segment optionality can be defined.
4. If the ORU is retained as a legitimate transcription message, modify the grammar to include the TXA and deprecate the OBR-35.
Chapter 7 - Purpose
This chapter describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) (the filler), to the ordering system (e.g., HIS order entry, physician’s office system) (the placer). However, the transaction set is not limited to such transactions. Observations can be sent from producing systems to archival medical record clinical information systems (not necessarily the order placer) and from such medical record systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon. This chapter also provides mechanisms for registering clinical trials and methods for linking orders and results to clinical trials and for reporting experiences with drugs and devices.
These transaction sets permit the transmission of any kind of clinical observations including (but not limited to) clinical laboratory results, the results of imaging studies (excluding the image), EKG pulmonary function studies, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms, drug allergies, problem lists, diagnostic lists, physician and nursing history, physicals, progress notes, operative notes and so on.
These transaction sets permit the transmission of clinical observations including (but not limited to) clinical laboratory results, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms, ?drug allergies?, ?problem lists?, ?diagnostic lists?.
If the observation being reported meets any of the following criteria, then the content would qualify as a medical document management message rather than an observation message. The reader is referred to the MDM message type in Chapter 9.
• Documents containing observations where the whole requires a signature
• Documents containing observations where the whole requires authentication
• Dictated and/or Transcribed reports
• Documents requiring succession management (of both document addenda and replacement documents).
• Documents where the content requires a security status applying to the whole.
OBR - observation request segment
In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations.
When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. So, the OBR segment is like a turn-around document. Some fields in the OBR segment apply only to the ordering message and some to the reporting message. To those familiar with healthcare procedures, these should be obvious from their names (e.g., transcriptionist or principal result interpreter could only apply to the reporting phase). However, we have also flagged them in Figure 7-4 to indicate whether placer, filler, or both may send data in a given field.
HL7 Attribute Table - OBR
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
|35 |200 |CM |O B |Y | |00267 |Transcriptionist + |
| | | | | | | | |
Note: The complete description of these fields is provided below as well as in Chapter 4.
OBR-35 Transcriptionist (CM) 00267
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Subcomponents of name: & & & & & & & &
Subcomponents of facility: & &
Definition: This field identifies the report transcriber.
This field is retained for backward compatibility only. Use of this field implies that the message content is a transcription in nature and thus is not supported in the ORU message construct. The reader is referred to the MDM messages in Chapter 9.
7.3.2.4 OBX-4 Observation sub-ID (ST) 00572
Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. For example, a chest X-ray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.
The sub-identifier is also used to group related components in reports such as surgical pathology. It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report. Consider, for example, a single surgical pathology report that describes the examination of gallbladder and appendix tissue. This report would be transmitted roughly as shown in Figure 7-2. Replace this example with urine analysis microscopic crystals example, or a CBC, differential/mylocytes example.
The following example should be moved to Chapter 9 and replaced here with an example that does not appear to be so document oriented
Figure 7-2. Example of sub-identifier usage
MSH||||||||MDM^T02^MDM_T02|...
OBR|1|||88304&SURG PATH REPORT...
OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM...
OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER...
OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY
NORMAL GALLBLADDER TISSUE...
OBX|4|CE|88304&IMP|1|M-00100^NML^SNM...
OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM...
OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX...
OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE...
OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM...
The example in Figure 7-2 has two segments for each component of the report, one for each of the two tissues. Thus, there are two 88304&ANT segments; there are two 88304&GDT segments, and there are two 88304&MDT segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.
The observation sub ID has other grouping uses. It can be used to organize the reporting of some kinds of fluid intakes and outputs. For example, when intake occurs through multiple intravenous lines, a number of separate observations (OBX segments), the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line, each requiring a separate OBX segment. If more than one IV line is running, we can logically link all of the OBX segments that pertain to the first IV line by assigning them an observation sub ID of 1. We can do the same with the second IV line by assigning them a sub ID 2 and so on. The same would apply to the outputs of surgical drains when there are multiple such drains.
The use of the sub ID to distinguish repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-6 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX.
|Distinct Observations |88304&ANT |88304&GDT |80304&MDT |80304&IMP |
|Sub ID 1st Group |1 |1 |1 |1 |
|Sub ID 2nd Group |2 |2 |2 |2 |
The use of Sub IDs to group results is equivalent to defining a table, and the use of sub IDs to distinguish repeats is just a special case, represented by one column in this table.
However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-7. This really represents the existence of a row nested within a single cell of the table given above.
Figure 7-3. Example of sub-identifier usage
OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...
OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...
OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY
NORMAL GALLBLADDER TISSUE...
OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...
OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...
OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...
OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...
OBX|8|CE|880304&IMP|2|M-40000^INFLAMMATION NOS^SNM...
OBX|9|CE|880304&IMP|2|M-30280^FECALITH^SNM...
The text under OBX-5-observation value provides guidance about dealing with two OBXs with the same observation ID and observation sub IDs. They are sent and replaced as a unit. However, some systems will take this to mean that the set of OBXs is to be combined into one composite observation in the receiving system. We suggest the use of a dot and a string (similar to the Dewey Decimal system) when users wish to distinguish each of the repeats within one type, or results within a cell for editing and correction purposes. Using this system, Figure 7-3 would become 7-4. If there are cases where such nesting occurs at even deeper levels, this approach could be extended.
Figure 7-4. Example of sub-identifier usage
OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...
OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...
OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY
NORMAL GALLBLADDER TISSUE...
OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...
OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...
OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...
OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...
OBX|8|CE|880304&IMP|2.1|M-40000^INFLAMMATION NOS^SNM...
OBX|9|CE|880304&IMP|2.2|M-30280^FECALITH^SNM...
Use a null or 1 when there is no need for multiples.
If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. This is in fact the case of the repeats depicted in Figure 7-8, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-IDs 1, 2 etc. alternatively, sub-IDs 1.1, 1.2, 1.3 could be used, as shown in Figure 7-8. Figure 7-9 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.
Figure 7-5. Example of Sub-ID used to distinguish three independent results with the same observation ID
OBX|1|CE|8601-7^EKG IMPRESSION ^LN|1|^atrial fibrillation|. . .
OBX|2|CE|8601-7^EKG IMPRESSION ^LN|2|^OLD SEPTAL MYOCARDIAL INFARCT| . . .
OBX|3|CE|8601-7^EKG IMPRESSION ^LN|3|^poor R wave progression|. . .
Chapter 9 - Purposes
This chapter currently supports document management. In the future, it is intended also to support the data exchange needs of applications supporting other medical record functions, including chart location and tracking, deficiency analysis, consents, and release of information. The main purpose of the medical record is to produce an accurate, legal, and legible document that serves as a comprehensive account of healthcare services provided to a patient.
Documents supported in this chapter will meet one or more of the following criteria. The reader is referred to the ORU message framework in Chapter 7 for messages that do not meet any of the following criteria.
• Documents containing observations where the whole requires a signature
• Documents containing observations where the whole requires authentication
• Dictated and/or Transcribed reports
• Documents requiring succession management (of both document addenda and replacement documents).
• Documents where the content requires a security status applying to the whole.
Within the context of the above criteria, these transaction sets permit the transmission of a wide range of clinical reports and/or observations. These documents include (but are not limited to) pathology reports, diagnostic imaging interpreted reports, EKG interpretations, pulmonary function studies, measures of patient status and condition, severity and/or frequency of symptoms, history & physical, nursing history, progress notes, operative notes, and reporting experiences with drugs or devices.
This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, “Relationship to Other Protocols.” The examples in this chapter were constructed using the HL7 Encoding Rules.
DOCUMENT MANAGEMENT SECTION
This section defines the Medical Document Management (MDM) transaction set. It supports transmission of new or updated documents or information about their status(es). The trigger events and messages may be divided into two broad categories, one which describes the statuses of documents, and one which both describes the statuses and contains the document content itself.
The document management section is concerned primarily with the management of those documents and entries, which are created as a result of a transcription process. These documents are created in two distinct contexts, one of which is related to an order and describes the procedures or activities associated with that order, and another which occurs independent of the order process. The scope of this section also includes any document that contains data derived from orders or results but which must be treated as aggregate display data due to system limitations. This is a transition strategy to support integration of data across the continuum of care.
The content of a document can be represented with one or more observation segments (OBX). Where headings or separations naturally exist within the text, it is preferred that each of these blocks be represented as a separate OBX record. Where systems are able to decompose the text into separate medical concepts, the most atomic level of granularity of content should be represented, ideally with each medical concept being represented in its own OBX segment. Many of these concepts can be represented as coded entities.
StrawVote
We took a straw vote on the following aspects together.
❑ There is value to MDM vs. ORU – document vs. report
❑ Need to Cross Reference
❑ “Document” in 9, “report” in 7
❑ Suffix example in 7, but also part of 9 (Example in 9 shows extension of 7)
❑ Document criteria to be further defined, and presented in both chapters.
❑ Using work from CDA/MDM document criteria definition
Vote: 13 in favor.
O&O and MM members will continue to work and prepare an update for the Friday morning.
❑ Note: ORC/OBR being added to MDM in V2.x
❑ Open Issue: Transcription field
Timing Quantity (TQ) Data Type Proposal
Problem 1:
For a many years I [HBOC – Austin K] have thought that TQ was a data type that was crying out to be a segment. There are far to many things encapsulated with in the data type for it to be truly considered a fundamental data type, and yet the information contained within it is definitely interrelated. It seems to me that a segment fulfills the needs of this data. By adopting timing/quantity as segments, we avoid the issues of how to make components/sub-components of data types repeat. No new delimiters are necessary with this approach, since segment and field repeat behavior is well defined.
Proposed Solution:
I propose 2 new segments, the TQ1 and TQ2. The TQ1 contains most of the information from the TQ data type, except for the data contained in the Order sequence component. The order sequence component is handled in the TQ2 segment.
TQ1 – Timing Quantity Segment
HL7 Attribute Table - TQ1
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |4 |SI |O |N | | |Set ID - TQ1 |
|2 | |NM |O |N | | |Service Quantity |
|3 | |CE |O |N | | |Service Quantity Units |
|4 | |IS |O |N | | |Repeat Pattern |
|5 | |TM |O |Y | | |Explicit Time |
|6 | |NM |C |N | | |Service duration |
|7 | |CE |C |N | | |Service duration units |
|8 | |TS |C |N | | |Service start date/time |
|9 | |TS |C |N | | |Service end date/time |
|10 | |ID |R |Y | | |Service priority |
|11 | |NM |C |N | | |Priority Integer of Criticality |
|12 | |ID |O |N | | |Priority Criticality Units |
|13 |250 |ST |O |N | | |Service condition text |
|14 |250 |TX |O |N | | |Service text |
|15 | |ID |C |N | | |Conjunction |
|16 | |CE |O |N | | |Service occurrence duration |
|17 | |NM |O |N | | |Service total occurrence's |
| | | | | | | | |
The field notes would come from the appropriate component definitions.
TQ1 field definitions
Set ID - TQ1
Problem 2:
Full population of Component 1 Quantity of the TQ data type cannot be legally expressed as it goes down to the sub sub component level. There is a note saying that the delimiters within the component have been demoted. This distinguishes Quantity from Units with an ampersand, but there is no way to legally delimit the parts of the Units subcomponent.
Proposed Solution:
Insert 2 fields: Service Quantity and Service Quantity Units.
Note: This solution should be consistent with that proposed by Joyce Spindler to OO at the Toronto meeting in June of 1999. Her proposal suggested these as 2 new components of the TQ.
The Spindler proposal also specified that a new code “U” for “until discontinued” be added to the units component. The minutes reflect that this was also approved: For: 10; Against: 0; Abstain: 0.
TQ1-2 Service quantity (NM)
Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1.
Question: Is there a use case requirement to add a ‘service quantity maximum’ and change this field to be a ‘minimum’ so that ranges may be entered?
TQ1-3 Service Quantity Units (CE)
Definition: This field indicates the units for the TQ1-5 Service Quantity field.
Conditionality Rule: This field may not be populated if the TQ1-5 Service Quantity field is not populated.
Problem 3:
The Component 2- Interval of the TQ data type is of the old style data type CM. The CM data type is not resolved in the 2.x HL7 data types DTD. This is a problem when using XML in messaging.
Proposed Solution:
Insert field into the TQ1 segment: Service Repetition of data type RI – Repeat Interval.
NOTE: This solution still does not resolve other problems embedded within the component.
1. There is language stating that the “Repeat Pattern” subcomponent can repeat. However, the only “Repetition Separator” defined in section 2.7 of chapter 2 is for field repetition; there are no legal repetition separators for components or subcomponents. We could ask CQ to define repetition separators for components and subcomponents if we feel they are needed after reworking the TQ data type. The data type for “Repeat Pattern” is “IS”. There is no rule saying that a code value may not have embedded spaces. So, we cannot declare that a space is a subcomponent repetition delimiter.
2. The second subcomponent “explicit time interval” is defined as an “ST” data type, but then a specific format is described which coincides with the data type “TM”.
3. The second subcomponent is also allowed to repeat; this time the delimiter appears to be a comma.
There may be a better solution for repeat patterns that can be taken from the version 3 Data Type document, but this requires further investigation. See section 8 of that document. We are also looking into the possibility of borrowing language from a “unix chron specification”.
TQ1-7 Service Repetition (RI)
Components: &
Definition: This field contains the interval between repeating appointments services. The default setting indicates that the appointment service should occur once, when the component is not valued.
Note: This field is replaced in favor of the next two fields.
Question: Should this be set to not allow repeating and just repeat the segment instead. I.e. only one service repetition per occurrence of the TQ1 segment.
TQ1-4 Repeat pattern (IS)
Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems. The following is preferred syntax for repeat patterns:
User-defined Table 0335 - Repeat pattern
|Value |Description |
|QS |every seconds |
|QM |every minutes |
|QH |every hours |
|QD |every days |
|QW |every weeks |
|QL |every months (Lunar cycle) |
|QJ |repeats on a particular day of the week, from the French jour (day). If |
| | is missing, the repeat rate is assumed to be 1. Day numbers are |
| |counted from 1=Monday to 7=Sunday. So Q2J2 means every second Tuesday; Q1J6 |
| |means every Saturday. |
|BID |twice a day at institution-specified times (e.g., 9AM-4PM) |
|TID |three times a day at institution-specified times (e.g., 9AM-4PM-9PM) |
|QID |four times a day at institution-specified times (e.g., 9AM-11AM-4PM-9PM) |
|XID |“X” times per day at institution-specified times, where X is a numeral 5 or |
| |greater. E.g., 5ID=five times per day; 8ID=8 times per day |
|Note: None of the above three specifications | |
|are equivalent to their QH | |
|counterpart. QID is not Q6H. The former is | |
|unequally spaced; the latter is equally spaced.| |
|QAM |in the morning at institution-specified time |
|QSHIFT |during each of three eight-hour shifts at institution-specified times |
|QOD |every other day (same as Q2D) |
|QHS |every day before the hour of sleep |
|QPM |in the evening at institution-specified time |
|C |service is provided continuously between start time and stop time |
|U |for future use, where is an interval specification as defined by the |
| |UNIX cron specification. |
|PRN |given as needed |
|PRNxxx |where xxx is some frequency code (e.g., PRNQ6H); given as needed over the |
| |frequency period. |
|Once |one time only. This is also the default when this component is null. |
|Meal Related Timings |C (“cum”) |
|A |Ante (before) |
|P |Post (after) |
|I |Inter (e.g., between this meal and the next, between dinner and sleep |
|M |Cibus Matutinus (breakfast) |
|D |Cibus Diurnus (lunch) |
|V |Cibus Vespertinus (dinner) |
|Example: one before breakfast and one after dinner: ACM,PCV |
TQ1-5 Explicit time interval
Definition: This field explicitly lists the actual times referenced by the code in the first subcomponent, in the following format: HHMM,HHMM,HHMM,.… This field will be used to clarify the TQ1-4 Repeat Pattern in cases where the actual administration times vary within an institution. If the time of the order spans more than a single day, this field is only practical if the same times of administration occur for each day of the order. If the actual start time of the order (as given by the TQ1-? of the quantity/timing segment) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing order may be updated with a new quantity/timing segment showing the changed explicit times.
Conditionality Rule: This field may not be populated if the TQ1-?Repeat Pattern field is not populated.
Problem 4:
The narrative for Component 3 Duration of the TQ data type suggests that it is coded and sets forth a specific coding structure to use. However, the data type is ST.
Proposed Solution:
Insert fields: and . This would be consistent with what chapter 10 has done in the AIL and AIP segments.
TQ1-6 Service duration (NM)
Definition: This field contains the duration for which the service is requested.
This field must be a positive, non-zero number. A negative number or zero (0) is nonsensical in the context of a duration.
TQ1-7 Service duration units (CE)
Components: ^ ^ ^ ^ ^
Definition: This field contains a code describing the units of time used associated with service-duration.
Conditionality Rule: This field may not be populated if the TQ1-? Service Duration field is not populated.
TQ1-8 Start date/time (TS)
Definition: This field may be specified by the orderer, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the order record (e.g., urgency - STAT). In such a case, this field will be empty.
The filling service will often record a value in this field after receipt of the order, however, and compute an end time on the basis of the start date/time for the filling service’s internal use.
TQ1-9 End date/time (TS)
Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.
Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.
Problem 5:
Component 6 Priority of the TQ data type is inconsistent with chapter 7. It is defined as ST in 4.2.6, ST in 4.4.1.7, 2.8 figure 2-2 HL7 Data types and ID in 7.3.1.27.
The narrative for Priority sets forth suggested coding values to use. Also v 2.2 of chapter 4 shows the data type as "ID" not "ST" in sections 4.3.1.7 and in section 4.4.6. This makes it appear that a typo might have crept into chapter 4 between versions 2.2 and 2.3, unless this was an intentional ballotted change.
Proposed Solution:
Insert Priority field into TQ1 with data type ID:
TQ1-10 Priority (CE):
Definition: This field describes the urgency of the request. If this field is blank, the default is R. The following values are suggested The following HL7 table may be used for this field.
HL7 Defined Table ???
|Value | | |
|S |Stat |With highest priority |
|A |ASAP |Fill after S orders |
|R |Routine |Default |
|P |Preop | |
|C |Callback | |
|T |Timing critical |A request implying that it is critical to come as close as possible to the |
| | |requested time, e.g., for a trough antimicrobial level. |
|PRN |As needed | |
If using the value “T” (timing critical), the degree of criticality can be specified in the TQ1-?-Priority decree of criticality and TQ1-12-Priority Units of Criticality:
TQ1-11 Priority integer of criticality (NM)
Definition: this field contains the integer indicating the level of criticality based on the code defined in TQ1-?Priority degree of criticality.
Conditionality Rule: this field may not be populated if the Priority field does not have “T” value.
TQ1-12 Priority Criticality Units (ID)
Definition: This field defines the criticality of the timing if the TQ1-? Priority field contains a time critical code value.
HL7 Defined Table ??
|S |timing critical within seconds |
|M |timing critical within minutes |
|H |timing critical within hours |
|D |timing critical within days |
|W |timing critical within weeks |
|L |timing critical within months |
Conditionality Rule: this field may only be populated if the TQ1-?-Priority field is populated with “T” value.
TQ1-13 Service condition text (ST)
Definition: This is a free text field that describes the conditions under which the drug is to be given. For example, PRN pain, or to keep blood pressure below 110.
The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.
TQ1-14 Service text (ST)
Definition: This field is a full text version of the instruction (optional).
Problem 6:
Component 9 Conjunction of the TQ data type is inconsistent with chapter 7. It is defined as ST in 4.2.9, ST in 4.4.1.7 and ID in 7.3.1.27 and 2.8 figure 2-2 HL7 Data types.
The narrative for Conjunction specifies the allowed set of coding values to use. Also v 2.2 of chapter 4 shows the data type as "ID" not "ST" in sections 4.3.1.7 and in section 4.4.9. This makes it appear that a typo might have crept into chapter 4 between versions 2.2 and 2.3, unless this was an intentional ballotted change.
Proposed Solution:
Insert Conjunction field into TQ1 with data type ID.
Problem 7:
The narrative for Component 9 Conjunction states that it is “non-null”. Does that mean this component is required? If so, that should be clearly stated. Also, better examples are needed that show the component populated followed by the proper field repetition.
Proposed Solution:
Insert Conjunction field into TQ1. Evaluate optionality. Examples need to be developed showing the correct syntax.
TQ1-15 Conjunction (ID):
Definition: This non-null field indicates that a second timing specification is to follow using the repeat delimiter. This field can take three values:
a) S = Synchronous
Do the next specification after this one (unless otherwise constrained by the following components: ORC-7^4-start date/time and ORC-7^5-end date/time).
An “S” specification implies that the second timing sequence follows the first, e.g., when an order is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day.
b) A = Asynchronous
Do the next specification in parallel with this one (unless otherwise constrained by the following components: ORC-7^4-start date/time and ORC-7^5-end date/time). The conjunction of “A” specifies two parallel instructions, as are sometimes used in medication, e.g., prednisone given at 1 tab on Monday, Wednesday, Friday, and at 1/2 tab on Tuesday, Thursday, Saturday, Sunday.
c) C = This is an actuation time
It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g., blood should be drawn) and the time and priority at which a service should be completed (e.g., results should be reported).
For continuous or periodic services, the point at which the service is actually stopped is determined by the components ORC-7^5-end date/time and ORC-7^3-duration, whichever indicates an earlier stopping time. Ordinarily, only one of these components would be present, but if one requested an EKG with the specification
^1^QAM^X3^D10
then the EKG would be done for only three days since the number of repeats (3) defined the earlier stopping time.
TQ1-16 Service Occurrence duration (CE)
Subcomponents: ^ ^ ^ ^ ^
Definition: This field contains the duration for a single performance of a service, e.g., whirlpool twenty minutes three times per day for three days.
TQ1-17Total occurrences component (NM)
Definition: This field contains the total number of occurrences of a service that should result from this order. If both the end date/time and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.
Follow-Up: Check this red bit.
Problem 8:
Component 10 order sequencing of the TQ data type is of the old style data type CM. The CM data type is not resolved in the 2.x HL7 data types DTD. This is a problem when using XML in messaging. Also the model is not expressed in the normal form for a data type even of the CM variety. The content appears to be complex and needs to be in clearly labeled sub-components or new components.
Proposed Solution:
This component appears to be largely related to pharmaceutical substance orders. Because of this and its complexity a pharmacy sub group should analyze this component.
We are also having the Clinical Laboratory Scientists on our KP HL7 team look at this to determine if it might be useful for complex lab orders.
HBOC recommends making this component its own segment as follows:
TQ2 – Service Relationship
Insert segment overview.
[NOTE: Kaiser Permanente has no objection to the content of this proposed segment. We are not currently sending this type of data however.]
HL7 Attribute Table - TQ2
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
|1 |4 |SI |O |N | | |Set ID - TQ2 |
|2 | |ID |O |N | | |Service Sequence/Results Flag |
|3 | |EI |C |Y | | |Predecessor placer order number |
|4 | |EI |C |Y | | |Predecessor filler order number |
|5 | |EI |C |Y | | |Predecessor placer group number |
|6 | |EI |C |Y | | |Successor placer order number |
|7 | |EI |C |Y | | |Successor filler order number |
|8 | |EI |C |Y | | |Successor placer group number |
|9 | |ID |C |N | | |Start/end predecessor order |
|10 | |ID |C |N | | |Start/end successor order |
|11 | |NM |C |N | | |Predecessor/successor time interval |
|12 | |CE |C |N | | |Predecessor/successor time interval units |
|13 | |NM |C |N | | |Cyclic group maximum number of repeats |
|14 | |ID |O |N | | |Sequencing relationship |
| | | | | | | | |
Note: Have added successor information and allowed for repeating.
The field notes would come from the appropriate component definitions. Fields 6-8, and 14 have no corresponding TQ components, and would need new field notes created for them. Fields 6-8 would have field notes similar to fields 3-5, except they define the relationship with successor orders, not predecessor orders. Field 14 would have
Field note for field 14:
Sequencing relationship defines the type of relationship between pharmacy orders. Example values would be:
|Value |Description |
|N |Nurse prerogative |
|C |Compound |
|T |Tapering |
|E |Exclusive |
|S |Simultaneous |
Problem 9:
The ORC-7 Quantity/timing as described in section 4.4.1.7 needs to be in synch with other TQ descriptions.
Proposed Solution:
If the above recommendations were accepted the following changes need to be made this section.
ORC - common order segment
4.4.1.7 ORC-7 Quantity/timing (TQ) 00221
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.4.4 and 4.4.5 respectively.
Problem 10
References to the TQ data type in chapter 7 need to be in synch with chapter 4.
Proposed Solution:
If the previous recommendations are approved the following changes should be made in chapter 7.
OBR - observation request segment
7.3.1.27 OBR-27 – Quantity/timing:
Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.4.4 and 4.4.5 respectively.
Usage of the TQ1/TQ2
TQ1 and TQ2 would form a repeating segment group within a message. The group would be in the form:
[{ TQ1 [{ TQ2 }] }]
|OMG^O19^OMG_O19 |General Clinical Order Message |Chapter |
|MSH |Message Header |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| PID |Patient Identification |3 |
| [PD1] |Additional Demographics |3 |
| [{NTE}] |Notes and Comments (for Patient ID) |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit- Additional Info |3 |
| ] | | |
| [{IN1 |Insurance |6 |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
| { | | |
| ORC |Common Order |4 |
| OBR |Observation |4 |
| [{NTE}] |Notes and Comments (for Detail) |2 |
| [{ |Start Timing/Quantity Group | |
| TQ1 |Timing/Quantity |4 |
| [{TQ2}] |Timing/Quantity Order Sequence |4 |
| }] |End Timing/Quantity Group | |
| [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 |
| } | | |
Tying TQ1/TQ2 to Version 3.0
The TQ1/TQ2 grouping has similarities to the Service/Service Relationship classes in version 3.0. The TQ1 segment is used to define timing/quantity information about the order (service) it is associated. The TQ2 segment is used to define the relationship between the order (service), and a separate order (service). Adopting this type of segment group in orders gives us a bridge between 2.x orders and the version 3.0 Service Action paradigm.
Discussion
Hans: Motion to accept this proposal in principle and endorse further development in coordination with Gunther Shadow on this proposal. Add use cases, examples, improve language and have full text of proposed segments and their placement in messages. Include overview of background issues with existing TQ structure.
Vote: abstain 1, for 13
Volunteers: Wayne (lead), Terry, Daphne & Austin (McKessonHBOC), Joann & Scott (Kaiser), Gunther, Hans, Heather (SMS).
Proposal will be scheduled for conference call discussions.
Hans to follow-up with Shafaman to clarify CQ actions on this proposal.
OBR-15 Specimen Source Change Proposal
Problem 1:
At the May HL7 meeting we asked the OO TC to add the following values to HL7 Table 0070 – Specimen Source as used in OBR-15 Specimen Source:
• Wash
• Brush
• Pericardial fluid
• Implant
We believe this was approved, but are resubmitting because there was some subsequent confusion regarding the outcome.
Proposed Solution:
Confirm proposed values were added to table 0070 Specimen Source.
Was this accepted in May 2000 meeting?
This list is not complete – need to either change to user defined table or to create more extensive list.
Problem 2:
The existing HL7 table 0070 Specimen source is very uneven in the items it contains. For example, “body fluid, unspecified”, is an entry as is “pancreatic fluid” and several other, but not all, fluids. Hence, our need to add “pericardial fluid”. Indeed, a number of new “fluid” entries were made for version 2.4. “Tissue” is an entry and then there are 6 other specific tissue entries e.g., “tissue gall bladder”. If all potential modifiers were to be added the size of this table would be increased exponentially. Also, it is unclear when component 4 Body Site could or should be used instead of adding new codes.
There is an “Other” entry, but without a place to state what “other” is, its use is questionable.
There is a “To be specified in another part of the message” entry. It is unclear how this differs from “Other” or where you specify what it is.
Currently there are less than 130 entries in the table. I have been told by the Clinical Laboratory Scientists on our KP HL7 team that there are often over 500 entries in a Specimen Source table. Also, the table needs a more user-friendly layout for quickly finding entries.
Does HL7 really want to maintain this table? If so should there be guidelines for user extensions to the table, e.g., Zxxx for local codes?
Proposed Solution:
Refer content issues in table 0070 to Vocab.
Re-arrange “Description” column so that keyword comes first. Sort on revised “Description” column rather than “Value”. Insert category column and populate as appropriate.
Problem 3:
The “specimen source name” component is constrained to HL7 table 0070 although it is defined as data type CE. Some sites may prefer to use SNOMED or some other nationally recognized standard. We believe (but are still researching) that the College of American Pathologists (CAP) recommend SNOMED codes. Special exception has already been necessary for use in the Veterinary Medicine context.
Proposed Solution:
Remove table 0070 constraint in figure 7-4 OBR Attributes and in Specimen Source Name narrative. Insert language listing allowable coding schemes, including table 0070, that meet requirements of the field. We are withdrawing our earlier proposed solution to change table 0070 to a user-defined table.
Add option to support multiple tables recognizing this field as a CE data type:
o HL7 070
o SNOMED
o Veterinary medicine (check with Jim Case for specific code system).
o Local codes?
o Free text
Vote to accept proposal #3: for 13 , against, abstain
Wayne motion: Modify table 0070 from HL7 to user defined where HL7 has a suggested list and where alternate representations (e.g. snomed or vet.) may be used.
Vote: for 13.
Problem 4:
The body site component (component 4) is constrained to HL7 table 0163 Body site. The problem is the same as problem 3 above. Some sites may prefer to use SNOMED or some other nationally recognized standard. The presence of a CE data type suggests that this may have been intended, but the narrative still constrains the valid entries.
Proposed Solution:
Remove table 0163 constraint in body site narrative. Insert language listing allowable coding schemes, including table 0163 and SNOMED, that meet requirements of the field.
Vote to accept proposal #4: for 13 , against, abstain
Wayne motion: Modify table 0163 from HL7 to user defined where HL7 has a suggested list and where alternate representations (e.g. snomed) may be used.
Question is it legal to change table from HL7 to user defined – yes there is precedent.
Vote: for 13.
Note to minutes: implication is that the table can now be added to, deleted from (i.e. some values not supported); but it is not valid to substitute values defined in the table.
Problem 5:
The name of HL7 table 0163 was changed from “Administration site” to “Body site” in version 2.4. The current entries are perhaps appropriate for administration sites but fall far short of being a laundry list of body sites.
There are 54 entries in this table with the majority of them being duplicates except for a right or left modifier. This makes it unclear as to when component 5 Body site modifier could or should be used instead of adding a new code to 0163. There is an entry “nebulized” that seems inappropriate as a body site.
It is difficult to find specific entries because the table is currently sorted on “Value”. Sorting on “Description” still presents difficulties because the description does not always begin with the key word.
Does HL7 really want to maintain this table?
Can the same table be used for administration site fields and specimen source/site fields? There is inconsistency as to whether or not an associated body site modifier field exists.
Proposed Solution:
Refer content issues in table 0163 to Vocab.
Request that vocabulary harmonize the use of ‘anatomical locations’ for common usage across all messages relating to the previous point (admin site & spec source). Recognize that there are non-HL7 sources (i.e. SNOMED) that need to be investigated.
Vote – abstain 1, for 8.
Re-arrange description so that it begins with a key word and sort on this new column.
Already done by Kaiser (see below).
Vote – for 13.
Consider deprecating the “nebulized” entry in table 0163. It is already an entry in HL7 table 0165 Administration method and Nebulizer is an entry in HL7 table 0164 Administration device. Perhaps an argument could be made for having it added to table 0070 specimen source. It is at the same level as “Sputum tracheal aspirate” and “Sputum coughed”.
Vote – for 13.
Separate the administration site field table from the specimen source site field table in 2.x.
Vote – for 13.
Problem 6:
OBR-15 Specimen Source is defined using the old style data type CM. The CM data type is not resolved in the 2.x HL7 data types DTD. This is a problem when using XML in messaging.
Proposed Solution:
Deprecate OBR-15 Specimen Source in favor of 6 clearly labeled new fields that are usable in XML messaging.
Specimen information looks a lot like it should be its own segment.
Helen motion: create a separate proposal to create a new segment for specimen. Proposal must include segment’s placement in messages, repeatability and any other OBR/SAC fields that are appropriate to specimen. Also, UK has requested a specimen identifier field. Replaced OBR/SAC fields would become ‘backward compatibility only’. This addresses problems 6-9. Proposal will include reference to Version 3.x
Discussion:
Wayne – concern over backward compatibility and size of change.
Austin – this is a bridge to version 3 model where specimen is separate.
Joann – CM causes problems with XML encoding.
Joann – Issues with sub-sub-components and repeatability.
Vote: abstain 2, for 12
Volunteers to work on proposal: Joann (Kaiser), Ken(Quest), Austin(McKessonHBOC)
Problem 7:
The existing narrative for the OBR:15 field is confusing:
• Examples are either non-existent or unsupported by table values
• The narrative cites incorrect component numbers
• Table 0070 is not properly sequenced
Proposed Solution:
Time has not permitted a thorough review of the narrative. Corrections have been suggested in several places.
Resolution: included in Problem 6 resolution.
Problem 8:
There are new fields and tables in chapter 13 that could be used to good advantage in the OBR.
Proposed Solution:
Time has not permitted a thorough review of chapter 13 to evaluate the new fields and tables. We have incorporated a few that seemed clearly applicable as follows:
• Change Component 2 Additive to coded and refer to table 0371.
• Add table 0376 to Component 6 Specimen collection method modifier code
Resolution: included in Problem 6 resolution.
Problem 9:
The minutes from the Atlanta meeting indicate that a 7th component, Specimen Role, was to be added to Specimen Source. This happened in the SAC-6 Specimen Source as described in section 13.3.3.6 of chapter 13, but not in the OBR-15. Was this intended?
Proposed Solution:
We have copied and pasted this component as a new field to promote discussion. It looks to us like it is relevant only to the SAC segment and perhaps should not have been a modification of the data type.
Resolution: included in Problem 6 resolution.
OBR - observation request segment
HL7 Attribute Table - OBR
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
|15 |300 |CM |O B | |0070 |00249 |Specimen Source * |
|48 | |CE | | | | |Specimen source name or code |
|49 | |ID | |Y |0371 | |Specimen additives |
|50 | |TX | | | | |Specimen collection method |
|51 | |CE | | | | |Specimen source body site |
|52 | |CE | | | | |Specimen source body site modifier |
|53 | |CE | | |0376 | |Specimen collection method modifier code |
|54 | |CE | | | | |Specimen role |
7.3.1.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 OBR 48 – OBR-53.
7.3.1.48 Specimen source name or code (CE)
Components: ^ ^ ^ ^ ^
Definition: This field identifies the site where the specimen should be obtained or where the service should be performed.
Definition: This field contains the specimen source name or code (as a CE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) NOTE: This is not a good example. Table 0070 does not include an entry “heart-blood”.
A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
• 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.
Note: Check for consistency of commas in Description column.
Fix description so that key word comes first: vote – for = 12
Add Category column is this a good idea?: vote – for = 11, abstain =1
Frank Howard (Kaiser) to check if he can work with Vocab to create a more complete/logical list with category column. Or identify industry vocabulary that can be used and referenced.
HL7 Table 0070 - Specimen source codes
|Value |Description |Category |Description |
|ABS |Abscess | |Abscess |
|ASP |Aspirate | |Aspirate |
|BPH |Basophils | |Basophils |
|BLDA |Blood, arterial |Blood |Blood arterial |
|BLDC |Blood, capillary |Blood |Blood capillary |
|BLDV |Blood, venous |Blood |Blood venous |
|BBL |Blood bag |Blood |Blood bag |
|BPU |Blood product unit |Blood |Blood product unit |
| BLDCO |Blood, Cord |Blood |Cord blood |
|MBLD |Blood, Menstrual |Blood |Menstrual blood |
|UMB |Blood, Umbilical |Blood |Umbilical blood |
|BLD |Blood, Whole |Blood |Whole blood |
|BDY |Body, Whole | |Whole body |
|BON |Bone | |Bone |
|BRTH |Breath (use EXHLD) | |Breath (use EXHLD) |
|BRO |Bronchial | |Bronchial |
|BRSH |Brush or brushing (these may be 2 separate entries as| |Brush or brushing |
| |in a physical brush or a portion thereof vs the | | |
| |substance obtained after a surface has been brushed) | | |
|BRN |Burn | |Burn |
|CALC |Calculus (=Stone) | |Calculus (=Stone) |
|CNL |Cannula | |Cannula |
|CTP |Catheter tip | |Catheter tip |
|CVM |Cervical mucus | |Cervical mucus |
|CVX |Cervix | |Cervix |
|COL |Colostrum | |Colostrum |
|CNJT |Conjunctiva | |Conjunctiva |
|CUR |Curettage | |Curettage |
|CYST |Cyst | |Cyst |
|DOSE |Dose med or substance | |Dose med or substance |
|DRN |Drain | |Drain |
|EAR |Ear | |Ear |
|EARW |Ear wax (cerumen) | |Ear wax (cerumen) |
|ELT |Electrode | |Electrode |
|ENDC |Endocardium | |Endocardium |
|ENDM |Endometrium | |Endometrium |
|EOS |Eosinophils | |Eosinophils |
|RBC |Erythrocytes | |Erythrocytes |
|EYE |Eye | |Eye |
|FIB |Fibroblasts | |Fibroblasts |
|FLT |Filter | |Filter |
|FIST |Fistula | |Fistula |
|PRT |Fluid /ascites, Peritoneal | |Peritoneal fluid /ascites |
|AMN |Fluid, amniotic | |Amniotic fluid |
|BIFL |Fluid, bile | |Bile fluid |
|FLU |Fluid, Body unsp | |Body fluid, unsp |
|CSF |Fluid, Cerebral spinal | |Cerebral spinal fluid |
|DIAF |Fluid, dialysis | |Dialysis fluid |
|DUFL |Fluid, duodenal | |Duodenal fluid |
|PAFL |Fluid, Pancreatic | |Pancreatic fluid |
|PCFL |Fluid, Pericardial | |Pericardial fluid |
|PLR |Fluid, Pleural (thoracentesis fluid) | |Pleural fluid (thoracentesis fld)|
| SMN |Fluid, Seminal | |Seminal fluid |
|SNV |Fluid, synovial (Joint fluid) | |Synovial fluid (Joint fluid) |
|GAST |Fluid/contents, Gastric | |Gastric fluid/contents |
|GAS |Gas | |Gas |
|EXG |Gas, exhaled (=breath) | |Exhaled gas (=breath) |
|IHG |Gas, Inhaled | |Inhaled Gas |
|GEN |Genital | |Genital |
|GENC |Genital cervix | |Genital cervix |
|GENL |Genital lochia | |Genital lochia |
|GENV |Genital vaginal | |Genital vaginal |
|HAR |Hair | |Hair |
|IMPL |Implant | |Implant |
|IT |Intubation tube | |Intubation tube |
|ISLT |Isolate | |Isolate |
|LAM |Lamella | |Lamella |
|WBC |Leukocytes | |Leukocytes |
|LN |Line | |Line |
|LNA |Line arterial | |Line arterial |
|LNV |Line venous | |Line venous |
|LIQ |Liquid NOS | |Liquid NOS |
|LYM |Lymphocytes | |Lymphocytes |
|MAC |Macrophages | |Macrophages |
|MAR |Marrow | |Marrow |
|MEC |Meconium | |Meconium |
|RT |Medicine, Route of | |Route of medicine |
|UMED |Medicine, Unknown | |Unknown medicine |
|MLK |Milk | |Milk |
|MILK |Milk, Breast | |Breast milk |
|CDM |Muscle, Cardiac | |Cardiac muscle |
|SKM |Muscle, Skeletal | |Skeletal muscle |
|NAIL |Nail | |Nail |
|NOS |Nose (nasal passage) | |Nose (nasal passage) |
|ORH |Other | |Other |
|PAT |Patient | |Patient |
|PLC |Placenta | |Placenta |
|PLAS |Plasma |Blood |Plasma |
|PLB |Plasma bag |Blood |Plasma bag |
|PPP |Plasma, Platelet poor |Blood |Platelet poor plasma |
|PRP |Plasma, Platelet rich |Blood |Platelet rich plasma |
|PMN |Polymorphonuclear neutrophils | |Polymorphonuclear neutrophils |
|PUS |Pus | |Pus |
|SAL |Saliva | |Saliva |
|SER |Serum | |Serum |
|SKN |Skin | |Skin |
|SPRM |Spermatozoa | |Spermatozoa |
|SPT |Sputum | |Sputum |
|SPTC |Sputum - coughed | |Sputum - coughed |
|SPTT |Sputum - tracheal aspirate | |Sputum - tracheal aspirate |
|STON |Stone (use CALC) | |Stone (use CALC) |
|STL |Stool = Fecal | |Stool = Fecal |
|SWT |Sweat | |Sweat |
|TEAR |Tears | |Tears |
|THRT |Throat | |Throat |
|THRB |Thrombocyte (platelet) | |Thrombocyte (platelet) |
|TISS |Tissue | |Tissue |
|TISG |Tissue gall bladder | |Tissue gall bladder |
|TLGI |Tissue large intestine | |Tissue large intestine |
|TLNG |Tissue lung | |Tissue lung |
|TISPL |Tissue placenta | |Tissue placenta |
|TSMI |Tissue small intestine | |Tissue small intestine |
|TISU |Tissue ulcer | |Tissue ulcer |
|XXX |To be specified in another part of the message | |To be specified in another part |
| | | |of the message |
|TUB |Tube NOS | |Tube NOS |
|ULC |Ulcer | |Ulcer |
|USUB |Unknown substance | |Unknown substance |
|URTH |Urethra | |Urethra |
|UR |Urine | |Urine |
|URT |Urine catheter | |Urine catheter |
|URC |Urine clean catch | |Urine clean catch |
|URNS |Urine sediment | |Urine sediment |
|VITF |Vitreous Fluid | |Vitreous Fluid |
|VOM |Vomitus | |Vomitus |
|WASH |Wash or washing e.g. bronchial washing | |Wash or washing e.g. bronchial |
| | | |washing |
|WAT |Water | |Water |
|WICK |Wick | |Wick |
|WND |Wound | |Wound |
|WNDA |Wound abscess | |Wound abscess |
|WNDD |Wound drainage | |Wound drainage |
|WNDE |Wound exudate | |Wound exudate |
7.3.1.49 Specimen additives (ID)
Definition: Lists additives to the specimen when applicable. Refer to HL7 table 0371 Additives.
Examples: Heparin, EDTA, or Oxlate
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.
HL7 Table 0371 – Additive
|Value |Description |
|EDTK |Potassium/K EDTA |
|EDTN |Sodium/Na EDTA |
|HEPL |Lithium/Li Heparin |
|HEPN |Sodium/Na Heparin |
|C32 |3.2% Citrate |
|C38 |3.8% Citrate |
|BOR |Borate |
|HCL6 |6N HCL |
7.3.1.50 Specimen collection method (TX)
Definition: describes the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment, i.e. an OBX segment.
7.3.1.51 Specimen source body site (CE)
Components: ^ ^ ^ ^ ^
Definition: specifies the body site from which the specimen was obtained.
A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
• HL7 Table 0163 - Body site
• SNOMED etc.
Table 0163 is listed for reader convenience.
NOTE: The RXR-2 Site also uses table 0163. Could we insert the same language as there?: As a CE data type, this field may be extended to cover a wide variety of body site codes (e.g., when SNOMED is used as the table source).
Need to verify term to be used to indicate that a value ‘should not’ be used anymore. Is Deprecated the right word? Check with CQ?
Add narrative that explains that the deprecated values are there because these values may be sent with a separate modifier.
Need guidance from Vocab.
Options:
1. Create separate tables for administration site and collection site?
1. Stan: separate tables with overlap in content.
Need to split body site table and create separate tables. HL70163 should return to administration site and add new table for collection site.
2. For each field what data type should it be.
2. Administration site: CE to CWE
3. Collection site: CE to CWE
4. Specimen source: CE to CWE
Vote: abstain 1, for 12.
This allows us to use HL7 table or other vocabulary.
3. For the following fields they will remain HL7 defined tables.
5. Administration site: Vote - abstain 3, for 10
6. Collection site: Vote - abstain 3, for 10
7. Specimen source: Vote - abstain 3, for 10
If user defined table, extensions would be supported like this:
|1^^HL7070| user defined just suggested values from HL7
If HL7 defined table, extensions would be supported like this:
|1^^Local| or |1^^99H001| or |1^^SNOMED|
If HL7 defined, HL7 will need to maintain these tables.
Add comment preamble to table definition that says that this is not an exhaustive list, but that the table includes all values identified to HL7 as required. Additional values may be added using local or other published coding systems.
4. HL70165 Administration method RXR-4 is user defined and will remain so.
▪ Wayne: missing values from the table may be Transdermal and micro infusion pump. Wayne will submit proposal including use case.
5. keep single table with all values.
▪ Separate pre/post coordinated entries.
▪ Change table to user defined (table is start point only)
▪ Add missing? values to the table
6. Add values to the table to cover more pre-coordinated values
7. Add new table for un-coordinated values
8. Should this be an HL7 table or User Defined?
Stan: In 3.x can not specify CE without specifying vocabularies.
▪ If CD (or any derived type) not pointing to an HL7 table, must point to 1-* external vocabularies. Must specify the specific vocabularies that are valid. May not point to an HL7 table and an external vocabulary.
▪ If concept is not defined in the HL7 table, may send a SNOMED or local code instead IF data type is CWE but NOT if data type is CNE.
Proposal to change
|1^^HL7070|
|2^^SNOMED|
|3^^Local|
▪ If HL7 defined table, then this is the only vocabulary allowed for the field.
▪ In 3.x you may extend an HL7 defined table using the CWE without extending the actual values of the table.
▪ Local tables are only supported as CWE
▪ HL7 May define ‘suggestion tables’ as part of the standard.
Hl7 Table 0163 - Body site
|Value |Description |Description |
|ABD |Abdomen | |
|LLAQ |Abdomen, Left Lower Quadrant – |Left Lower Abd Quadrant |
| |Deprecated? | |
|LUAQ |Abdomen, Left Upper Quadrant- |Left Upper Abd Quadrant |
| |Deprecated | |
|RLAQ |Abdomen, Right Lower Quadrant- |Rt Lower Abd Quadrant |
| |Deprecated | |
|RUAQ |Abdomen, Right Upper Quadrant- |Right Upper Abd Quadrant |
| |Deprecated | |
|LA |Arm, Left |Left Arm |
|LUA |Arm, Left Upper |Left Upper Arm |
|RA |Arm, Right |Right Arm |
|RUA |Arm, Right Upper |Right Upper Arm |
|BU |Buttock |Buttock |
|CT |Chest Tube |Chest Tube |
|LAC |Chest, Left Anterior |Left Anterior Chest |
|LPC |Chest, Left Posterior |Left Posterior Chest |
|RAC |Chest, Right Anterior |Right Anterior Chest |
|RPC |Chest, Right Posterior |Right Posterior Chest |
|LD |Deltoid, Left |Left Deltoid |
|RD |Deltoid, Right |Right Deltoid |
|LE |Ear, Left |Left Ear |
|RE |Ear, Right |Right Ear |
|BE |Ears, Bilateral |Bilateral Ears |
|OS |Eye, Left |Left Eye |
|OD |Eye, Right |Right Eye |
|OU |Eyes, Bilateral |Bilateral Eyes |
|LF |Foot, Left |Left Foot |
|RF |Foot, Right |Right Foot |
|LLFA |Forearm, Left Lower |Left Lower Forearm |
|LMFA |Forearm, Left Mid |Left Mid Forearm |
|LUFA |Forearm, Left Upper |Left Upper Forearm |
|RLFA |Forearm, Right Lower |Right Lower Forearm |
|RMFA |Forearm, Right Mid |Right Mid Forearm |
|RUFA |Forearm, Right Upper |Right Upper Forearm |
|LACF |Fossa, Left Antecubital |Left Antecubital Fossa |
|RACF |Fossa, Right Antecubital |Right Antecubital Fossa |
|LG |Gluteus Medius, Left |Left Gluteus Medius |
|RG |Gluteus Medius, Right |Right Gluteus Medius |
|LH |Hand, Left |Left Hand |
|RH |Hand, Right |Right Hand |
|LEJ |Jugular, Left External |Left External Jugular |
|LIJ |Jugular, Left Internal |Left Internal Jugular |
|REJ |Jugular, Right External |Right External Jugular |
|RIJ |Jugular, Right Internal |Right Internal Jugular |
|BN |Nares, Bilateral |Bilateral Nares |
|LN |Naris, Left |Left Naris |
|RN |Naris, Right |Right Naris |
|NB |Nebulized |Nebulized |
|PA |Perianal |Perianal |
|PERIN |Perineal |Perineal |
|LSC |Subclavian, Left |Left Subclavian |
|RSC |Subclavian, Right |Right Subclavian |
|LT |Thigh, Left |Left Thigh |
|RT |Thigh, Right |Right Thigh |
|LVL |Vastus Lateralis, Left |Left Vastus Lateralis |
|RVL |Vastus Lateralis, Right |Right Vastus Lateralis |
|LVG |Ventragluteal, Left |Left Ventragluteal |
|RVG |Ventragluteal, Right |Right Ventragluteal |
7.3.1.52 Specimen source body site modifier (CE)
Components: ^ ^ ^ ^ ^
Definition: Modifies body site.
For example, the site could be antecubital fossa, and the site modifier “right.”
7.3.1.53 Specimen collection method modifier handling (CE)
Components: ^ ^ ^ ^ ^
Definition: indicates whether the specimen is frozen as part of the collection method. Specifies the state of the specimen.
Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.
Refer to HL7 table 0376 Need Name for valid values.
Definition: This field describes any special handling considerations that are associated with the specimen. (E.g. centrifugation). Refer to HL7 Table 0376 – Special handling considerations for valid values. This table’s values are taken from NCCLS AUTO4. The value set can be extended with user specific values.
HL7 Table 0376 - Special handling considerations
|Value |Description |
|PRTL |Protect from light |
|CFRZ |Critical Frozen |
|CATM |Critical do not expose to atmosphere – Do not uncap |
|CREF |Critical refrigerated |
|CAMB |Critical ambient temperature |
|C37 |Critical maintain at 37C (e.g., cryoglobulin specimen |
7.3.1.54 Specimen role (CE)
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.
User-defined Table 0369 - Specimen role
|Value |Description |
|P |Patient (default if blank component value) |
|Q |Control specimen |
|C |Calibrator |
|B |Blind Sample |
|R |Replicate (of patient sample as a control) |
7.3.1.55 Specimen Temperature (degrees) (NM)
Definition: Specifies the numeric value of the temperature of the specimen.
7.3.1.56 Specimen temperature units (CE)
Components: ^ ^ ^ ^ ^
Definition: Specifies the specimen temperature units: Farenheit, Celsius…
Pharmacy Proposals
These proposals were postponed until Friday due to lack of time. It was decided that Scott would lead some between meeting conference calls as well to review the proposals in preparation for the next meeting.
Tuesday, September 13, 2000
Co-Chair Election
The first order of business was to elect a new co-chair as Wayne Tracy’s term expired. Gunther Schadow was elected the new co-chair. Wayne will continue as the facilitator for Vocabulary in Orders & Observations.
RIM Review
Gunther Schadow provided a review of RIM changes from the last Harmonization meeting:
❑ Many changes were made on the left hand side.
❑ This resulted in essentially 5 classes and everything else subclasses of these 5.
❑ An O&O proposal to remove one data element was not accepted.
❑ The State Transition Diagram accepted.
❑ A suggestion was made to synchronize Act, Service Code, and Activity Date/Time. Since the naming would be act.service_cd it could work. Suggestion withdrawn based on definitions and purpose.
❑ Review of RIM classes/attributes
❑ Participation class is the collapse of actor and target. A person has one or more “static” roles (Role) and a role in the context of a particular act (Participation). We need to provide various role codes as O&O needs them.
❑ We want to maintain an HL7 defined list of participation.type_cd values, whereas the participation.function_cd can be more flexibile. Suggestion to either drop function_cd or make stronger case for using it and tightening it up. Will be brought up with PRA.
❑ Revive Jim Case - Cleveland proposal to clean-up certain attributes that should be observations.
❑ Resolution of Materials/Specimen issues.
❑ Materials Relationship, Entity Relationship moved to RoleRoleRelationship.
❑ Prefer to use Specimen instead of Sample.
❑ Propose to make Specimen a specialization of a role and remove category_cd (covered elsewhere), content_category_cd (covered elsewhere), description_txt (unknown origin).
❑ Suggestion to change body_site_cd to anatomical_site_cd.
❑ Need to move material.desc to entity used principally to further specify/annotate about the entity.
❑ Specimen Source Code would be entity type.
❑ Challenge with identifiers within SAC. Will work into the message discussion.
PRA/MR Joint Meeting
PRA, MR, and O&O conducted a joint meeting to further understand the relationship between documents, reports, and messages, and how the respective committees view these concepts. While we did not reach a conclusion and consensus, we were able to address various topics through the discussion using the document at the end of this section as a guide.
❑ There is agreement that the underlying facts communicated as part of a document, message, report, are the same and currently represented through the OBX (V2.x) / Act (V3.x).
❑ There is considerable difference of perspective whether a document is different from a message is different from a report.
❑ There is agreement that characteristics such as “signature”, “persistence”, “authentication”, “wholeness”, “human readibility” are valid concepts that must be able to be part of a communication.
❑ The discussion indicates that some feel that there should not be a distinction between a message and a document, but rather that a document is always communicated through a message. The message may have data that is not relevant to the document aspects of the message.
❑ An interest was expressed to look at the differences in a more fluid fashion and the differences are actually on the same continuum. A message may need to incorporate more or less characteristics that may be associated with the content becoming a document.
❑ Thoughts were expressed that since a “message” has particular and conflicting meanings, to maybe use “information exchange” as a concept.
❑ There are differences of perspective as to the ability to influence the receiving system’s ability to maintain a document as a whole vs. a message.
❑ There is a common sense that operations need to be performed on metadata, e.g., the tracking of completion, attestation of a document.
Much more discussion needs to take place to resolve these types of issues. They must be resolved in the context of Level III PRA, which gives us ample time to address them. RIM Harmonization and initial V3.0 message definitions initiated through MR and O&O will provide further perspective and input into this discussion as well as PRA continuing its efforts. There will be continued joint sessions to address these and other issues.
CDA - O/O Differentiation
(Last Revised: Sept 07, 2000)
Introduction
The purpose of the discussion is to begin to identify and articulate the differences and similarities between document and message content. In particular, we recognize that it will be possible to send coded observations both in HL7 messages and CDA Level Three documents, and we are hoping to better understand the use cases for each. This will minimize ambiguities for both senders and receivers and will allow joint development and more rapid deployment of HL7 specifications.
The objective of the discussion is to:
• Understand the potential implications for implementers if these issues are not resolved.
• Identify issues that need further clarification.
• Begin to understand the use cases for sending observations in documents and the use cases for sending observations in messages.
• Begin to understand potential solutions to managing the potential for ambiguity.
The objective of the discussion will not be to fully articulate and come to closure on these issues, since it is expected that they are too complex to be solved in a single meeting. Rather, it is hoped to increase awareness on these issues, and ultimately come to a consensus on how they should be solved.
Differentiate "document" from "message"
Here we begin by trying to clearly differentiate a "document" from a "message".
• Definition of "Clinical Document" (from CDA August 2000 Membership Ballot):
A clinical document contains observations and services and has the following characteristics:
• Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.
• Stewardship – A clinical document is maintained by a person or organization entrusted with its care.
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
• Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
• Human readability – A clinical document is human readable.
A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.
Anything that does not meet all 5 of these criteria is not a clinical document.
Other potential differentiators:
• USAM services act on documents, but not on messages
• Documents can be packaged (and separately encrypted) within messages, but we see no need for the converse.
Use cases for packaging observations in "documents" vs. "messages"
The following is presented as a preliminary brain-storming list being put forth to stimulate discussion. No one is proposing that any of the following use cases are true or correct, and in fact some of the use cases contradict others. The real intent is to stimulate thought and discussion.
• Those observations that come into being as part of a clinical document must be sent within that clinical document.
The definition of clinical document includes the notion of "wholeness" - which means that an observation taken out of context is not necessarily true, unless the context of the observation is conveyed in some manner that is as safe as the document. As we move in to structured data entry systems with provider-based data entry, providers will be the primary source of observation data (e.g. symptoms, assessments). These observations, if recorded within a clinical document, should be transmitted within the clinical document to ensure safety of context.
• Observations that are included in a clinical document will be transmitted in the clinical document even though they may be redundantly sent as messages, where use cases warrant.
This "use case" also relies on the definition of a clinical document to say that you can't send less then the logical unit which is the document. Those observations added into the document by the healthcare provider will continue to live in that document, even though many (such as lab results) will also live in other formats.
• Observations that require real-time processing should be transmitted in a message.
We should try to understand the receiver responsibilities for "documents" and "messages". In general, I imagine receivers getting a document and making it available for immediate viewing or putting it into a repository, while I imagine receivers getting a message to be able to apply some automated process to the information in that message. Thus, observations (such as critical lab values) that require immediate processing (? or any processing ?), should be sent as a message. The Hierarchical Message Descriptor described in the MDF specifies receiver update semantics. How are these applicable to messages vs. documents?
• Observations that come in to being outside the context of a clinical document can be transmitted as messages. Those that come in to being within the context of a clinical document are transmitted as documents.
When a laboratory wants to transmit a coded observation, it sends it as a message. When a pathologist studies a specimen and generates a pathology report using a structured data entry system that automatically inserts codes into the document, the entire pathology report, including the coded observations, are transmitted as a document. An exception is that in some cases, business rules may dictate that information created as a Level 3 CDA or as a message be "dumbed down" before transmission for view-only applications. For example, a lab may choose to allow access to its repository of reports to entities that are part of competing business enterprises, based on the need to serve a shared patient population. Such a cooperative agreement would cover release of single sets of results for individual patients needed for a consultation or referral or to insert into a cumulative patient record. In this case, a human-readable form of the observations fits the requirements for point-of-care communication and safeguards against abuse of the access privilege to build a knowledge base of information on the patient population treated by the lab.
• Complex semantic networks that can't be represented by the receiver's database can be sent in a document, giving them a secure home until they can be further processed.
Complex semantic networks of symptoms and their modifiers are going to be difficult for receivers to process for a while. A structured XML blob holds the data in an unambiguous fashion until it can be processed. (A V3 message could do the same - is it any easier or harder to just hold all the V3 messages in a repository?)
• Semantic networks can point to original narrative contained in a document.
We should consider the case where such a semantic network is expressed and is not included in the character stream/file/encrypted package of the document. Should the network and document be sent in the same message? Is such a network synonymous with coded observations? What is the relationship between such a network and other observations?
• Requirements for human processing (readability) should indicate that observations must be sent as documents.
Of course, any observation may need to be read at some point. The distinction of interest might be whether further processing is required for display, or whether a standard browser application can be used.
• What are the use cases for sending documents today within OBXs?
CDA Level One is basically just a more consistent approach to sending the type of documents that are currently being passed in OBX segments. In general, documents are sent when the contents are largely textual. Codes associated with the documents are sent as coded observations in their own segments.
• Sender has the option of using message and/or document. Receiver must parse both messages and documents.
This is to indicate that we're not really talking about ambiguity. Rather, we're trying to avoid redundancy. If we say that receivers must process both messages and documents, then there is no ambiguity. In any case, we should articulate the receiver responsibilities when they receive a document that contains coded observations.
• Different trigger events and message types for document vs. message.
Should there be different application roles defined - to differentiate receivers that can accept messages and receivers that can accept documents? Would it help to define different messages - those that transmit coded observations within the message, and those that transmit coded observations within documents? Would it help to define different triggers -- those that cause the observations to be sent in a document vs. those that cause the information to be sent in a message?
• All possible observations and other services are flagged as being primarily transmitted in messages or documents.
It would be possible to go through SNOMED, ICD-9, LOINC, etc, and for each code state HL7's preferred transmission route. In the case of lab results, receivers WOULD NOT have to look in documents - they could safely assume that the sender will send the data in a message, although it may be transmitted also in a document. In the case of symptoms, receivers WOULD have to look in documents for the data, and could not assume that symptom data will be sent in a message.
• Always send coded observations in messages, regardless of whether or not they are also in documents. (see above on observations that point to nodes/anchors in a document.)
• Documentation of the observations made in the context of an encounter are captured in a clinical document. Corollary: messages are derived from such documents.
• Compare / contrast with CEN EHCR which contains original component complexes and data items in the model, with no redundancy.
How have other standards solved this dichotomy?
• Who/what is the actor on the receiver side? human? machine?
Obviously, it will be a receiving application, but is there a point of differentiation in the expectation for the timing of human intervention?
• Does all the above apply only to Level 3 CDA?
Vocabulary Joint Meeting
Stan Huff reviewed the different areas that Vocabulary is currently looking at.
Background
❑ Overview of Vocabulary TC activity in pharmacy:
❑ Recipe Orders – List of ingredients
❑ Not fully specified order – It cannot be pulled of the shelf, etc. Free Text
❑ Clinical Drug – Single name, all active ingredients, strength, form “diazepan 5 mg tablet”
or by trade name
including manufacturer + packaging -> NDC
❑ Vocabulary is focused mostly on the clinical drug area at this point.
❑ Need for name and form only and let the pharmacy complete as a variation of “not fully specified”.
❑ Intended repository as part of Clinical LOINC with associated ownership.
❑ Suggestion is to have the “file format” of this repository based on the RIM to enable future updates of whatever vocabulary is decided upon.
❑ There is a lot of work going on in European arena, particularly route, form.
Today’s Discussion
❑ Today’s discussion focus on RXR: route, site, method, device, instruction.
❑ They are not independent, inconsistent, not orthogonal.
❑ Proposal is to do something different:
❑ Combine Method, Route, and Device (125-150 or so sensible permutations) and keep the site separate.
❑ Route Description would be the name for the pre-coordinated combination of method, route, and device.
❑ There is a concern with new methods, how it is valued as it may not be ordered that way.
❑ Alan Rector shares the approach pursued in Europe. Create legal combinations that generate cumulative legal combinations. About 250 legal combinations, but not necessarily agreed upon to be different.
❑ Experience is that form and route needs to be coordinated.
❑ Need to make a distinction between intended use and actual use.
❑ Suggestion to look at what Alan has done in the same space around form.
❑ Galen Mulrooney volunteers to work with Stan and Alan to assist with further refinement.
❑ Will combine the permutations whether used as part of order through administration.
❑ Need to consider to separate the device and how it ties to being able to identify specific devices. Start to work from combining first and possibly separate some aspects as discovered.
❑ A motion to continue the efforts as described today based on combining Method, Route, and Device, with further review of the approach taken in Europe is accepted with 25 in favor, 6 abstain, remainder no vote, and nobody against.
❑ Vocabulary will come back a recommendation on sites for specimen source.
IISIG Joint Meeting
❑ Herman Oosterwijk of IISIG presented the DICOM procedure and image object model and a typical data flow model. We compared the object model with the RIM and found many similarities. For example, DICOM as HL7 v3 has the understanding that procedure orders may be revised as they are processed by the filler. This reinforced the distinction between the placer's order object and the filler's intent and event objects that the OO working group has developed in Cleveland.
❑ Harmonization of DICOM information in HL7 was discussed with a focus on HL7 v3 and the RIM. Bob Dolin of CDA noted that DICOM SR and CDA cooperation should go through RIM harmonization rather than a direct XML mapping. This will assure that the fruits of DICOM HL7 interoperability will be available for HL7 version 3 messages and clinical documents.
❑ The IISIG has been working with the RIM since Cleveland. The objective was to map DICOM structures to RIM sturctures. Several tasks have been defined that will be addressed until the January meeting.
1. DICOM study-series-image model
2. DICOM/IHE procedure model
3. DICOM SR structured reporting model
To make the DICOM/RIM mapping clearer, we will express the mapping as Refined Message Information Models (RMIMs). The RMIMs are direct predecessor to HL7 messages. Thus, the work product of the mapping will effectiely be HL7 v3 message structures representing the DICOM information structures.
Ad 1. Al Figler, IISIG's RIM Facilitator maintains the DICOM study-series-image RIM mapping. He will draft an RMIM for this with the help of Gunther Schadow.
Ad 2. Fred Behlen and Gunther Schadow will draft an RMIM for the DICOM/IHE procedure model.
Ad 3. Structured reporting will be addressed once the other two projects have been successful. Meanwhile Bob Dolin and David Clunie will explore the issue.
If missing elements are found in the RIM, we will try to bring forward harmonization proposals for November so that the mapping projects 1 and 2 can be completed at the January meeting. The joint OO/II meeting will reconvene in January (on Wednesday PM before cookies.)
Wednesday, September 13, 2000
V3.0 Trigger Events
We discussed the potential trigger events for Orders & Observations. The following table is the result of these initial discussions. On Thursday we continued the discussion with a specific focus on Pharmacy. Therefore, the results from Thursday for Pharmacy override the ones listed in this table. We still include it to show the progression of the discussion. In preparation of the Orlando meeting, the two tables will be combined and further expanded with the work that Austin Kreisler has performed in this space.
Legend:
Category Reflects the general state in the State Transition Diagram
Numbers Indicates a preliminary count of messages. Where cells have the same number, the
thought is that the same message can provide the required communication.
Colors Red – Lower priority, may not need it.
Green – Punt to Patient Care
Blue – Scheduling/Logistics
Burgundy – Wait for general direction
|Trigger Event |Area |
|Category |Initiation |Response |Lab |Rx |CS |Diet |Gen |
|New |XYZ Order | |1 |- |3 |4 |5 |
| | |XYZ Order Accepted & OK & ID |6 |
| | |Unable to Accept XYZ Order |6 |
| |Medication Order Request (Prov to Rx) | | |2 | | | |
| | |Medication Order Accepted & OK & ID | | |6 | | |
| | |Unable to Accept Medication Order | | |6 | | |
| |XYZ Intent | |7 |- |9 |10 |11 |
| | |Intent Accepted |6 |
| | |Unable to Accept XYZ Intent |6 |
| |Medication Intent – Structured (Rx to other) | | |8 | | | |
| | |Medication Order Accepted & ID | | |6 | | |
| | |Unable to Accept Medication Order | | |6 | | |
| |??Medication Intent Notification?? (Rx to | | |N | | | |
| |other) | | | | | | |
| |No expectation for feedback. | | | | | | |
| |Add New Order to Specimen Request | |12 |- |- |- |- |
| | |New Order Added to Specimen as Requested |13 |- |- |- |- |
| | |Unable to Add New Order to Specimen |14 |- |- |- |- |
| |New Order Added to Specimen | |15 |- |- |- |- |
| | |New Order Added to Specimen as Indicated |13 |- |- |- |- |
| | |Unable to Add New Order to Specimen |14 |- |- |- |- |
| |Order Number Assignment (SN/NA) | |1 |
| |Link Order Request | |1 |
| | |Linked as Indicated |1 |
| | |Unable to Link |1 |
| |Order Linked | |1 |
| | |Linked as Indicated |1 |
| | |Unable to Link |1 |
| |Order Extend | |16 |
| | |Renewed as Indicated |6 |
| | |Unable to Renew |6 |
| |Extend Order Request | |17 |
| | |Renewal approved |6 |
| | |Renewal Denied |6 |
| | |Unable to Renew |6 |
|Correct |Change Order Request | |18 |19 |20 |21 |22 |
| | |Changed as Requested |6 |
| | |Unable to Change |6 |
| |Order Changed | |23 |24 |25 |26 |27 |
| | |Changed as Indicated |6 |
| | |Unable to Change |6 |
| |Replace Order Request | |1 |1 |1 |1 |1 |
| | |Replaced as Requested |6 |
| | |Unable to Replace |6 |
| |Order Replaced | |1 |1 |1 |1 |1 |
| | |Replaced as Indicated |6 |
| | |Unable to Replace |6 |
|In Process |Order Schedule Request | |1 |? |? |? |1 |
| | | | | | | | |
| | |Order Not Scheduled |- |- |- |- |6 |
| | |Order Scheduled |- |- |- |- |1 |
| |Order Re-Scheduled | | | | | | |
| |Schedule Information Request | | | | | | |
| |Add Specimen to Existing Order Request | |1 |- |- |- |- |
| | |Existing Order Added to Specimen as Requested |6 |- |- |- |- |
| | |Unable to Add Existing Order to Specimen |6 |- |- |- |- |
| |Specimen Added to Existing Order | |1 |- |- |- |- |
| | |Existing Order Added to Specimen as Indicated |6 |- |- |- |- |
| | |Unable to Add Existing Order to Specimen |6 |- |- |- |- |
| |Dispense Order Request | |- |28 |? |? |- |
| | |Order Dispensed as Requested |- |6 |? |? |- |
| | |Unable to Dispense Order |- |6 |? |? |- |
| |Order Dispensed | |- |29 |? |? |- |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| |Equipment Status Update | |34 |
| | |Acknowledgement |6 |
| |Equipment Status Request | |1 |
| | |Equipment Status Update |34 |
| |Specimen Status Update | |35 |- |- |- |- |
| | |Acknowledgement |6 |- |- |- |- |
| |Specimen Status Request | |36 |- |- |- |- |
| | |Specimen Status Update |35 |- |- |- |- |
| |Equipment Inventory Update | |37 |? | | |38 |
| | |Acknowledgement |6 |? | | |39 |
| |Equipment Inventory Request | |40 |? | | |41 |
| | |Equipment Inventory Update |37 |? | | |42 |
| |Equipment Command | |43 |? | | | |
| | |Acknowledgement |6 |? | | | |
| | |Equipment Response |44 |? | | | |
| |Equipment Notification | |45 |? | | |? |
| | |Acknowledgement |6 |? | | |? |
| |Equipment Test Code Settings Update | |46 |? | | | |
| | |Acknowledgement |6 |? | | | |
| |Equipment Test Code Settings Request | |47 |? | | | |
| | |Equipment Test Code Settings Update |46 |? | | | |
| |Equipment Log/Service Update | |48 |
| | |Acknowledgement |49 |
| |Equipment Log/Service Request | |49 |
| | |Equipment Log/Service Update |48 |
|Hold | Interrupt Order Request | |50 |
|Suspend | | | |
| | |Put on Hold as Requested |6 |
| | |Unable to Put on Hold |6 |
| |Order Interrupt | |51 |
| | |Put on Hold as Indicated |6 |
| | |Unable to put on Hold |6 |
| |Release Interrupt Request | |52 |
| | |Released as Requested |6 |
| | |Unable to Release |6 |
| |Interrupt Released | |53 |
| | |Released as Indicated |6 |
| | |Unable to Release |6 |
|Cancel |Stop Order Request | |54 |
|Discontinue | | | |
| | |Stopped as Requested |6 |
| | |Unable to Stop |6 |
| |Order Stopped | |55 |
| | |Stopped as Indicated |6 |
| | |Unable to Stop |6 |
|Complete |Observation | |56 |- |- |- |56 |
| |Observation Update (Status/Corrections/etc.) | |57 |- |- |- |57 |
| | |Observation Updated |6 |- |- |- |6 |
| | |Unable to Update Observation |6 |- |- |- |6 |
| |Observation Update Request | |58 |- |- |- |58 |
| | |Observation Update |57 |- |- |- |57 |
| |Medication Administration | |- |59 |- |? |- |
| |Medication Administration Deleted | |- |60 |- |? |- |
| | |Medication Administration Deleted as Indicated |- |61 |- |? |- |
| | |Unable to Delete Medication Administration |- |62 |- |? |- |
| |Medication Administration Updated | |- |63 |- |? |- |
| | |Medication Administration Updated as Indicated |- |64 |- |? |- |
| | |Unable to Update Medication Administration |- |65 |- |? |- |
|Query |Order Query | | | | | | |
| | |No Order Fits Criteria | | | | | |
| | |Order Subject is Unknown | | | | | |
| | |Order Query Response | | | | | |
| |Vaccination Query | | | | | | |
| | |Multiple Patient Matches | | | | | |
| | |Single Patient Vaccinations | | | | | |
| | |Unable to Find Patient Match | | | | | |
|Referral |Referral Notification | | | | | | |
| | |Referral Accepted | | | | | |
| | |Referral Denied | | | | | |
| |Modify Referral | | | | | | |
| | |Referral Modification Accepted | | | | | |
| | |Referral Modification Denied | | | | | |
| |Cancel Referral | | | | | | |
| | |Referral Cancelled | | | | | |
| | |Referral Cancel Denied | | | | | |
| |Referral Status Request | | | | | | |
| | |Referral Status Update | | | | | |
Additional notes:
❑ We may be able to combine Dietary and Pharmacy messages. To be determined.
❑ Unclear where Clinical Trials will fit.
❑ Need to have a times on the order.
❑ Need to have the ability for an acknowledgement to reflect “I’m thinking”, i.e., acknowledgement they received it, but still need to determine whether they can accept the meaning of the message.
❑ The Replace message is deemed duplicative of a cancel and new. Could consider creating a CMET for communicating an Act – Act relationship that enables cross-references/purposes. Requires further thought.
❑ The State Transition Diagram needs to be updated to reflect the scheduling messages.
❑ A question was raised whether Lab Automation could be applied more generically.
❑ Need clarification through vocabulary as we progress that Hold is intended to reflect a pre-execution stop, vs., Suspend is intended to reflect while executing.
Specimen Container Segment
We reviewed with the Lab Automation SIG the mapping of V2.x identifiers to V3 constructs. The conclusions can be summarized as follows:
❑ Primary (parent) Container Identifier
Make sure the R-MIM has a required 1:1 relationship for parent container to pick up the identifier of the parent identifier for the aliquot.
❑ Accession Identifier (internal/external)
Likely place on the Act Collection side. Will be resolved as part of the Grouping discussion (Entity Group Class). Internal/external identifiers can be handled since the ID is a set.
❑ Available Volume
Point to Specimen.qty
❑ Initial Specimen Volume
Probably warrants an additional attribute. Alternative is to make it an observation. Andrezj, Jim, and Gunther to follow-up and if attribute is chosen, they will move forward to harmonization.
❑ Location
Map to entity.description and use role-role relationship to “nest”. Alternative is to create a specific identifier (OID). Suggestion is to allow for recursion and then a recursion of 1 satisfies the alternative.
❑ Specimen Component
Suggest to improve the V2.x description. Follow-up will take place in the specimen group and conclusions moved forward to V3.0.
❑ SAC-31 through 42
Address as observations. Jim Case will work on obtaining LOINC Codes as necessary. Spin-off suggestion is to change the name of Temperature to Current Specimen Temperature.
❑ Special Handling Considerations
List to be created by SIG and to become part of material.handling_cd.
❑ Other Environmental Factors
To be treated as observations.
Messages
❑ We need to ask for Patient and Provider CMET.
❑ Lab Auto SIG will provide a CMET for Specimen CMET and Specimen/Container CMET.
Thursday, September 14, 2000
Pharmacy Messages
We initiated the discussion with a focused review of potential pharmacy messages. The following table reflects the first round of review and replaces the pharmacy message rows/cells in the earlier table.
|Medication Order | |
| |6* - Medication Accepted & OK |
| |6* - Unable to Accept Medication Order |
| |Medication Intent Notification |
|Medication Intent Notification (Rx to Other) | |
| |6* - Medication Order Accepted + Number Assignment |
| |6* - Unable to Accept Medication Order |
|??Medication Intent Notification?? (Rx to other) No expectation for feedback. | |
|Medication Dispense Request (Rx to Robot) | |
| |6 - Medication Dispensed as Requested |
| |6 - Unable to Dispense Medication |
|Medication Dispense Notification (Robot – Rx, Rx to Prov) | |
|Medication (Re)fill Request (Pt/Prov to Rx) | |
| |6 - Unable to (Re-)fill |
| |6 - Medication (Re-)fill Request Accepted |
| | |
|Medication Extension Authorization Request (Rx to Prov) | |
| |6 - Medication Refill Authorized as Requested |
| |6 - Unable to Authorize Medication Refill |
|Medication Extension Notification (Prov to Rx) | |
|Medication Schedule Notification (Rx to MedAdmin) | |
| |Order Given as Requested |
| |Unable to Give Order |
|Order Given | |
|Medication Administration Notification (MedAdmin to other, other to other) | |
The two diagrams on the following page provides an interaction review of how the different messages are used in an inpatient scenario and outpatient scenario.
The following diagram focuses on an initial message definition for a medication order without the formulary definition coming along.
If we want to add formulary information to the message, then the following classes would need to be added, somehow.
Friday, September 15, 2000
On Friday we reviewed CDC’s model and resolved various conceptual synchronization issues with the RIM. Addtionally, various V2.4 proposals were reviewed as an overflow from Monday.
RIM Proposals
Mead Walker presented various RIM proposals that require O&O input that were generated as a result of the Public Health Data Model review.
Populations or Informal Organizations
Both government models provide a way to handle groups, generally of persons or animals. This concept is particularly important in public health and in community medicine. On the other hand, the LSR-RIM supports the notion of groups with a quantity attribute within biological entity. It would be to better provide more explicit recognition of this important concept. At the same time, the term, “logical entity” is excessively general; it can refer to anything. Also, collections of events can be handled as Act Collections
Proposal
a) Remove “Logical Entity”. Make Organization a specialization of Entity
b) Add “Entity Collection”. Use the following description: “Entity Collection provides a way to recognize the grouping and/or collective action of individual entities. An Entity Collection may also be a group of interest that has been assembled or defined in some formal or informal manner. The members of a collection to not have to be enumerated or known. Examples of such are social groups or units such as families, boy scouts, day care attendees, and college students. Another kind of Entity Collection is an organization, a grouping of people and/or a group of functions operating as a unit. Examples are managed care organizations, hospital systems, State Health Departments and regulatory agencies.
c) Remove qty as an attribute from Living Subject, and make it an attribute of Entity Collection.
Discussion:
Already discussed with PAFM and already moving forward with proposal to harmonization.
Case
A model that includes the direct patient care oriented concept of patient encounter should also include the public health related concept of the case. These are rather similar as organizers of clinical information, and case is widely used within disease and other types surveillance as the anchor point for analysis and summarization.
In the PHCDM, case appears as a specialization of health related activity (the LSR’s act) instead of being a type of collection. There appears to be some sentiment for treating patient encounters similarly – that is as acts rather than as collections. Instead of taking a position on that question here, we would simply say: a) both patient encounter and case should be explicitly recognized in the model, b) they should be treated symmetrically.
It is true that all of the attributes of case and outbreak can be modeled as observations, however that would not be a reasonable thing to do. Once the model included the generic concept of observation that can handle any bit of data that is not explicitly represented, there is no longer any firm, “objective” basis to handle any attribute as an explicit attribute. This applies to race code, and valuables description just as much as to transmission mode code. The argument for any explicit attribute has to be essentially heuristic or political. That is, it is essentially a beauty contest. With this as the criteria, it is important to note that the attributes of case are virtually always valued for a case, and constitute markers of the case that are widely recognized and seen as important by users of the case. (By way of contrast, what happens to patient encounter if you consider whether its attributes should be observations?) Therefore, it is both reasonable and valuable to explicitly represent these attributes.
Proposal
a) Include case as a class within the model. (Does this need a more specific name, e.g., “public health case”?) Use the following description for case: “A case represents a condition or event that has a specific significance for public health. The case can include a health-related event concerning a single individual or it may refer to multiple health-related events that are occurrences of the same disease or condition of interest to public health. An outbreak involving multiple individuals may be considered as a type of case.
b) Add confirmation-method-code as an attribute of case. Use the following description: “Code for the mechanism by which the case was classified. This attribute is intended to provide information about how the case status (confirmed, probable, suspected) was derived. Includes laboratory-confirmed, clinical case inclusion criteria (alone) met, epidemiologist- or other public health worker-assigned, epidemiologically-linked via investigation, physician reported.” (2)
c) Add detection-method-code as an attribute of case. Use the following description: “Code for the method by which the case was identified. Includes provider report, patient self-referral, laboratory report, case or outbreak investigation, contact investigation, active surveillance, routine physical, prenatal testing, perinatal testing, prison entry screening, occupational disease surveillance, medical record review, etc.” (1)
d) Add transmission-mode-code as an attribute of case. Use the following description: “Code for the mechanism by which disease was acquired by the living subject involved in the case. Includes sexually transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental exposure, indeterminate.” (1-2 need use cases)
e) Add disease-imported-code as an attribute of case. Use the following description: “Code that indicates whether the disease was likely acquired outside the jurisdiction of observation, and if so, the nature of the inter-jurisdictional relationship. Possible values include not imported, imported from another country, imported from another state, imported from another jurisdiction, and insufficient information to determine.” (1-2 need use cases)
f) Add etiologic-status-code as an attribute of case. Use the following description: “Code to indicate the extent to which the disease causing agent, or other factor behind the case is known. Examples include suspected, confirmed, and unknown.” (2)
g) Include outbreak as a specialization of case. (Would “cluster” be a more acceptable name for this?) Use the following description of outbreak: “An outbreak or cluster is the occurrence in a community or region of cases of an illness in excess of those normally expected. The designation of an outbreak implies that a public health assessment of causality or at least of relatedness among cases has taken place. An outbreak is considered to be a special type of case (where a case, in this instance, may include many affected individuals), and may not simply be an aggregate of multiple cases although an outbreak may also be designated as an aggregate of multiple individual cases.”
h) Add extent-code as an attribute of outbreak. Use the following description: “Code for the qualitative measure of the number of jurisdictions involved. Possible values include single jurisdiction, multi-county, multi-state, and multi-national. Note that if the specific jurisdictions are to be captured they are captured as target participations associated with a jurisdictional party.” (2)
i) Add peak-date as an attribute of outbreak. Use the following description: “Date of onset for the highest number of cases (statistically this refers to the mode of the distribution) associated with the outbreak.” (2)
j) Add time-range as an attribute of outbreak. Use the following description: “The period of time during which the outbreak takes place. The date on which an outbreak starts is the earliest date of onset among the cases assigned to the outbreak, and its ending date is the last date of onset among the cases assigned to the outbreak. (1)
Discussion
❑ Jim Case: many attributes should be observations (confirmation method, disease imported code, transmission mode code, extent code). Others could be attributes. Need confidence code tied to case. LOINC for epidemiological measures. Peak date is a calculation so should it be in the model? Time range is also derived. Like to see incidence level as well, and others.
❑ Criteria: single/persistent characteristic as attribute (1) – transient/changing values during the course of the class would be observations (2)
❑ Uncomfort with the term case as it may be confusing between environments.
❑ Observations are made against entities. Make Case a group of people/entities onto which observation are made. Case has epidemiological importance. Investigation. Clinical Trial.
❑ “Case” specialization of Act (or Observation) and entities brought in through the participation class. Then Act-Act relationship provides observations about the “case”.
❑ Clinical Trial has similarities.
❑ Suggestion to move towards Investigation. Work with Linda.
12 Favor, 1 abstain in support of direction to make Investigation a specialization of Act, provide grouping of entities through Participation, and associated observations about the Investigation through act-act-relationship. Attributes to by synchronized with Clinical Trials.
Notification
The concept of notification is critical for the practice of public health. These kinds of acts may be important in other contexts as well. A notification could record, for example, a practitioner’s notification to a family physician that a child had received an injury consistent with physical abuse.
Notification information is significant, and should not simply be identified with the header information on a message for two reasons. 1) Message header information such as transmission date/time is specifically intended to indicate information about message transmission, while the comparable notification date/time would be the point in time that the notifying party recorded their notification. 2) Sometimes information is recorded specifically to be a notification, and would not be other wise recorded. Therefore this information cannot be captured as a side effect of other transactions.
Proposal
a) Add notification as a specialization of Act. Use the following description: “A notification is an interaction with a practitioner, case worker, or other person or organization to report or document a condition or health-related activity of importance to the health of the public. Includes notification by a provider to a patient that they have a disease, report by a provider or laboratory to public health of a case or positive isolate, report of a gunshot wound to police, reminder of the need for immunization against disease, notification of a possible adverse reaction to a drug.”
b) Add reason_cd as an attribute of notification. Use the following description: “Code for the reason for the notification. Examples might include reportable condition, positive laboratory test, positive screening results, self-motivated, interview, referral, and positive gonorrhea test.”
Discussion
❑ Hearing argument for a use case for a message (electronic, phone). Not sure whether it requires additional specializations of Act.
❑ May need persistence that messages were send.
❑ To be further pursued.
Intervention
It is important, for modeling public health activities, to capture information about activities that are carried out to change the state of entities besides individual living things. Such activities include population interventions such as chlorinating or fluoridating the water supply, and pesticide application in a specific geographic area.
Proposal
We need further discussion on how to manage these concepts within the RIM. Do existing structures support these requirements? If so, are definitional changes indicated? Are there related issues, such as the role of “procedure” to be considered?
Discussion
❑ Definition of classes seems to imply that Act is only applicable to living things. That is not the intent though. Clarifications should be made accordingly.
❑ Model different types of interventions appropriately, e.g., applying agents to the environment is similar to a medication, vs. teaching.
❑ Need to straighten out Medication, Procedure, Intervention concepts, but cannot use the “purpose” as a discriminator (e.g., procedure for diagnostic purpose vs. corrective purposes – it’s still a procedure).
❑ Present by next meeting as part of joint discussion with Patient Care. Jim/Mead/Dan.
Body Site Code
It is important to recognize that the source for a sample is not necessarily a human body.
Proposal
c) Use the following definition for the attribute: “The xxxx (see b) site code indicates from where, in relationship to the specimen source, the specimen is taken. For persons and non-person living organisms, the valid domain is a list of body sites. This is an attribute of the specimen, since it may be relevant in some cases, e.g., if multiple liver needle biopsies are taken from different lobes and locations of the liver. In the case of material items such as restaurants or lakes, the site code indicates from where the specimen was taken. In the case of a lake, this could be, "near intake", "at swimming site", etc. In the case of a restaurant, this could indicate a typical restaurant component such as a meat grinder.
d) Change the name of the attribute to “source site code”
e) Would it be preferable to only allow a single non-body value, i.e., environmental in the attribute domain?
Discussion:
❑ Body Site is changed to anatomical site.
❑ Specimen moved in the RIM as part of Role could address this.
❑ Do not use the CNE to enable non-human descriptions.
V2.x Proposals
Table 396 – Name of Coding System Proposal – Kaiser Permanente
We have the following issues with the Name of Coding System (Table 396) as described section 2.16.5 of v2.4.
Problem:
5. Chapter 15, Personnel Management, references codes in CE data type fields for which there are no entries in User Defined Table 396 to indicate the coding system:
• Birth State
United States Postal Service
• Health Care Provider Type Code
ANSI ASC X12 Health Care Provider Taxonomy
• Health Care Provider Classification Code
ANSI ASC X12 Health Care Provider Taxonomy
• Health Care Provider Area of Specialization Code
ANSI ASC X12 Health Care Provider Taxonomy
6. Table 0396 is a user-defined table. This means we cannot count on values being standardized.
Proposed Solution:
1. Add new terms to User Defined Table 396, Specific Non-Drug Codes. (see 2.16.5)
We’ve listed three organizations as the source for the Health Care Provider taxonomy in our proposed solution because we were confused. From their website, it states that Blue Cross and Blue Shield Association acts as the administrator of the Provider Taxonomy so that the code structure is classified as external to X12, Workgroup 15 (Provider Information) within ANSI ASC X12 is responsible for maintenance, and Washington Publishing Company is responsible for distribution.
Vote: 10 favor, 0 against, 3 abstain.
2. Change the designation of Table 396 to an HL7 table.
Vote: unanimous
Coding system table
Chapter 7is the steward for the Coding Systems table. The table is copied here for reader convenience.
HL7 Table 0396 - Coding System
|Value |Description |Comment / Source |Category |
|99zzz or L |Local general code (where z |Locally defined codes for purpose of sender or receiver. Local codes |General code |
| |is an alphanumeric character)|can be identified by L (for backward compatibility) or 99zzz (where z | |
| | |is an alphanumeric character). | |
|ACR |American College of Radiology|Index for Radiological Diagnosis Revised, 3rd Edition 1986, American |Specific Non-Drug Code|
| |finding codes |College of Radiology, Reston, VA. | |
|ART |WHO Adverse Reaction Terms |WHO Collaborating Centre for International Drug Monitoring, Box 26, |Drug code |
| | |S-751 03, Uppsala, Sweden. | |
|AS4 |ASTM E1238/ E1467 Universal |American Society for Testing & Materials and CPT4 (see Appendix X1 of |Specific Non-Drug Code|
| | |Specification E1238 and Appendix X2 of Specification E1467). | |
|AS4E |AS4 Neurophysiology Codes |ASTM’s diagnostic codes and test result coding/grading systems for |Specific Non-Drug Code|
| | |clinical neurophysiology. See ASTM Specification E1467, Appendix 2. | |
|ATC |American Type Culture |Reference cultures (microorganisms, tissue cultures, etc.), related |Specific Non-Drug Code|
| |Collection |biological materials and associated data. American Type Culture | |
| | |Collection, 12301 Parklawn Dr, Rockville MD, 20852. (301) 881-2600. | |
| | | | |
|C4 |CPT-4 |American Medical Association, P.O. Box 10946, Chicago IL 60610. |Specific Non-Drug Code|
|C5 |CPT-5 |(under development – same contact as above) |Specific Non-Drug Code|
|CAS |Chemical abstract codes |These include unique codes for each unique chemical, including all |Drug code |
| | |generic drugs. The codes do not distinguish among different dosing | |
| | |forms. When multiple equivalent CAS numbers exist, use the first one | |
| | |listed in USAN. USAN 1990 and the USP dictionary of drug names, | |
| | |William M. Heller, Ph.D., Executive Editor, United States | |
| | |Pharmacopeial Convention, Inc., 12601 Twinbrook Parkway, Rockville, MD| |
| | |20852. | |
|CD2 |CDT-2 Codes |American Dental Association’s Current Dental Terminology (CDT-2) code.|Specific Non-Drug Code|
| | |American Dental Association, 211 E. Chicago Avenue,. Chicago, Illinois| |
| | |60611. | |
|CDCA |CDC Analyte Codes |As above, for CDCM | |
|CDCM |CDC Methods/Instruments Codes|Public Health Practice Program Office, Centers for Disease Control and|Drug code |
| | |Prevention, 4770 Buford Highway, Atlanta, GA, 30421. Also available | |
| | |via FTP: ftp.pub/laboratory _info/CLIA and Gopher: | |
| | |gopher.:70/11/laboratory_info/CLIA | |
|CDS |CDC Surveillance |CDC Surveillance Codes. For data unique to specific public health |Specific Non-Drug Code|
| | |surveillance requirements. Epidemiology Program Office, Centers for | |
| | |Disease Control and Prevention, 1600 Clifton Rd, Atlanta, GA, 30333. | |
| | |(404) 639-3661. | |
|CE |CEN ECG diagnostic codes |CEN PT007. A quite comprehensive set of ECG diagnostic codes |Specific Non-Drug Code|
| | |(abbreviations) and descriptions published as a pre-standard by CEN | |
| | |TC251. Available from CEN TC251 secretariat, c/o Georges DeMoor, State| |
| | |University Hospital Gent, De Pintelaan 185-5K3, 9000 Gent, Belgium or | |
| | |Jos Willems, University of Gathuisberg, 49 Herestraat, 3000 Leuven, | |
| | |Belgium. | |
|CLP |CLIP |Simon Leeming, Beth Israel Hospital, Boston MA. Codes for radiology |Specific Non-Drug Code|
| | |reports. | |
|CPTM |CPT Modifier Code |Available for the AMA at the address listed for CPT above. These |Specific Non-Drug Code|
| | |codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 | |
| | |Standard Edition, American Medical Association, Chicago, IL). | |
|CST |COSTART |International coding system for adverse drug reactions. In the USA, |Drug code |
| | |maintained by the FDA, Rockville, MD. | |
|CVX |CDC Vaccine Codes |National Immunization Program, Centers for Disease Control and |Drug code |
| | |Prevention, 1660 Clifton Road, Atlanta, GA, 30333 | |
|DCL |DICOM Class Label |From the Message Standards Classes table of the |Specific Non-Drug Code|
| | |SNOMED-DICOM-Microglossary. College of American Pathologists, Skokie, | |
| | |IL, 60077-1034 | |
|DCM |DICOM modality codes |Dean Bidgood, MD; Duke University Medical Center, Durham NC. Digital |Specific Non-Drug Code|
| | |Imaging and Communications in Medicine (DICOM). From NEMA | |
| | |Publications PS-3.1 – PS 3.12: The ACR-NEMA DICOM Standard. National | |
| | |Electrical Manufacturers Association (NEMA). Rosslyn, VA, 22209., | |
| | |1992, 1993, 1995 | |
|DQL |DICOM Query Label |HL7 Image Management Special Interest Group, Health Level Seven, Ann |Specific Non-Drug Code|
| | |Arbor, MI. | |
|E |EUCLIDES |Available from Euclides Foundation International nv, Excelsiorlaan 4A,|Specific Non-Drug Code|
| | |B-1930 Zaventem, Belgium; Phone: 32 2 720 90 60. | |
|E5 |Euclides quantity codes |Available from Euclides Foundation International nv (see above) |Specific Non-Drug Code|
|E6 |Euclides Lab method codes |Available from Euclides Foundation International nv, Excelsiorlaan 4A,|Specific Non-Drug Code|
| | |B-1930 Zaventem, Belgium; Phone: 32 2 720 90 60. | |
|E7 |Euclides Lab equipment codes |Available from Euclides Foundation International nv (see above) |Specific Non-Drug Code|
|ENZC |Enzyme Codes |Enzyme Committee of the International Union of Biochemistry and |Specific Non-Drug Code|
| | |Molecular Biology. Enzyme Nomenclature: Recommendations on the | |
| | |Nomenclature and Classification of Enzyme-Catalysed Reactions. London:| |
| | |Academic Press, 1992. | |
|FDDC |First DataBank Drug Codes |National Drug Data File. Proprietary product of First DataBank, Inc. |Drug code |
| | |(800) 633-3453, or . | |
|FDDX |First DataBank Diagnostic |Used for drug-diagnosis interaction checking. Proprietary product of |Drug code |
| |Codes |First DataBank, Inc. As above for FDDC. | |
|FDK |FDA K10 |Dept. of Health & Human Services, Food & Drug Administration, |Specific Non-Drug Code|
| | |Rockville, MD 20857. (device & analyte process codes). | |
|HB |HIBCC |Health Industry Business Communications Council, 5110 N. 40th St., Ste|Specific Non-Drug Code|
| | |120, Phoenix, AZ 85018. | |
|HCPCS |HCFA Common Procedure Coding |HCPCS: contains codes for medical equipment, injectable drugs, |Specific Non-Drug Code|
| |System |transportation services, and other services not found in CPT4. | |
|HCPT |Health Care Provider Taxonomy|The Blue Cross and Blue Shield Association will act as the |Specific Non-Drug Code|
| | |administrator of the Provider Taxonomy so that the code structure is | |
| | |classified as external to X12. Ongoing maintenance is solely the | |
| | |responsibility of Workgroup 15 (Provider Information) within ANSI ASC | |
| | |X12N, or the work group’s successor. | |
| | |Blue Cross and Blue Shield Association, 225 North Michigan Avenue | |
| | |Chicago, IL 60601, Attention: ITS Department, ECNS Unit. | |
| | | | |
| | |Primary distribution is the responsibility of Washington Publishing | |
| | |Company, through its World Wide Web Site, at the same web site. | |
|HHC |Home Health Care |Home Health Care Classification System; Virginia Saba, EdD, RN; |Specific Non-Drug Code|
| | |Georgetown University School of Nursing; Washington, DC. | |
|HI |Health Outcomes |Health Outcomes Institute codes for outcome variables available (with |Specific Non-Drug Code|
| | |responses) from Stratis Health (formerly Foundation for Health Care | |
| | |Evaluation and Health Outcomes Institute), 2901 Metro Drive, Suite | |
| | |400, Bloomington, MN, 55425-1525; (612) 854-3306 (voice); (612) | |
| | |853-8503 (fax); dziegen@. See examples in the | |
| | |Implementation Guide. | |
|HL7nnnn |HL7 Defined Codes where nnnn |Health Level Seven where nnnn is the HL7 table number |General code |
| |is the HL7 table number | | |
|HPC |HCFA Procedure Codes (HCPCS) |Health Care Financing Administration (HCFA) Common Procedure Coding |Specific Non-Drug Code|
| | |System (HCPCS) including modifiers.[1] | |
|I10 |ICD-10 |World Health Publications, Albany, NY. |Specific Non-Drug Code|
|I10P |ICD-10 Procedure Codes |Procedure Coding System (ICD-10-PCS.) See |Specific Non-Drug Code|
| | | for more information. | |
|I9 |ICD9 |World Health Publications, Albany, NY. |Specific Non-Drug Code|
|I9C |ICD-9CM |Commission on Professional and Hospital Activities, 1968 Green Road, |Specific Non-Drug Code|
| | |Ann Arbor, MI 48105 (includes all procedures and diagnostic tests). | |
|IBT |ISBT |International Society of Blood Transfusion. Blood Group Terminology |Specific Non-Drug Code|
| | |1990. VOX Sanquines 1990 58(2):152-169. | |
|IC2 |ICHPPC-2 |International Classification of Health Problems in Primary Care, |Specific Non-Drug Code|
| | |Classification Committee of World Organization of National Colleges, | |
| | |Academies and Academic Associations of General Practitioners (WONCA), | |
| | |3rd edition. An adaptation of ICD9 intended for use in General | |
| | |Medicine, Oxford University Press. | |
|ICDO |International Classification |International Classification of Diseases for Oncology, 2nd Edition. |Specific Non-Drug Code|
| |of Diseases for Oncology |World Health Organization: Geneva, Switzerland, 1990. Order from: | |
| | |College of American Pathologists, 325 Waukegan Road, Northfield, IL, | |
| | |60093-2750. (847) 446-8800. | |
|ICS |ICCS |Commission on Professional and Hospital Activities, 1968 Green Road, |Specific Non-Drug Code|
| | |Ann Arbor, MI 48105. | |
|ICSD |International Classification |International Classification of Sleep Disorders Diagnostic and Coding |Specific Non-Drug Code|
| |of Sleep Disorders |Manual, 1990, available from American Sleep Disorders Association, 604| |
| | |Second Street SW, Rochester, MN 55902 | |
|ISOnnnn |ISO Defined Codes where nnnn |International Standards Organization where nnnn is the ISO table |General code |
| |is the ISO table number |number | |
|IUC |IUPAC/IFCC Property Codes |International Union of Pure and Applied Chemistry/International |Specific Non-Drug Code|
|IUPP | |Federation of Clinical Chemistry. The Silver Book: Compendium of | |
| | |terminology and nomenclature of properties in clinical laboratory | |
| | |sciences. Oxford: Blackwell Scientific Publishers, 1995. Henrik | |
| | |Olesen, M.D., D.M.Sc., Chairperson, Department of Clinical Chemistry, | |
| | |KK76.4.2, Rigshospitalet, University Hospital of Copenhagen, DK-2200, | |
| | |Copenhagen. | |
|IUPC |IUPAC/IFCC Component Codes |Codes used by IUPAC/IFF to identify the component (analyte) measured. |Specific Non-Drug Code|
| | |Contact Henrik Olesen, as above for IUPP. | |
|JC8 |Japanese Chemistry |Clinical examination classification code. Japan Association of |Specific Non-Drug Code|
| | |Clinical Pathology. Version 8, 1990. A multiaxial code including a | |
| | |subject code (e.g., Rubella = 5f395, identification code (e.g., virus | |
| | |ab IGG), a specimen code (e.g., serum =023) and a method code (e.g., | |
| | |ELISA = 022) | |
|LB |Local billing code |Local billing codes/names (with extensions if needed). |General code |
|LN |Logical Observation |Regenstrief Institute, c/o LOINC, 1050 Wishard Blvd., 5th floor, |Specific Non-Drug Code|
| |Identifier Names and Codes |Indianapolis, IN 46202. 317/630-7433. Available from the | |
| |(LOINC®) |Regenstrief Institute server at . | |
| | |loinc/loinc.htm. Also available via HL7 file server: | |
| | |FTP/Gopher (mcis.duke.edu/standards/ termcode/loinclab and | |
| | |mcis.duke.edu/standards/termcode/loinclin) and World Wide Web | |
| | |(http:// mcis.duke.edu/ standards/termcode/loincl.htm). January | |
| | |2000 version has identifiers, synonyms and cross-reference codes for | |
| | |reporting over 26,000 laboratory and related observations and 1,500 | |
| | |clinical measures. | |
|MCD |Medicaid |Medicaid billing codes/names. |Specific Non-Drug Code|
|MCR |Medicare |Medicare billing codes/names. |Specific Non-Drug Code|
|MDDX |Medispan Diagnostic Codes |Codes Used for drug-diagnosis interaction checking. Proprietary |Drug code |
| | |product. Hierarchical drug codes for identifying drugs down to | |
| | |manufacturer and pill size. MediSpan, Inc., 8425 Woodfield Crossing | |
| | |Boulevard, Indianapolis, IN 46240. Tel: (800) 428-4495. WWW: | |
| | | medhome.html. As above for MGPI. | |
|MEDC |Medical Economics Drug Codes |Proprietary Codes for identifying drugs. Proprietary product of |Drug code |
| | |Medical Economics Data, Inc. (800) 223-0581. | |
|MEDR |Medical Dictionary for Drug |Dr. Louise Wood, Medicines Control Agency, Market Towers, 1 Nine Elms |Drug code |
| |Regulatory Affairs (MEDDRA) |Lane, London SW85NQ, UK Tel: (44)0 171-273-0000 WWW: | |
| | | | |
|MEDX |Medical Economics Diagnostic |Used for drug-diagnosis interaction checking. Proprietary product of |Drug code |
| |Codes |Medical Economics Data, Inc. (800) 223-0581. | |
|MGPI |Medispan GPI |Medispan hierarchical drug codes for identifying drugs down to |Drug code |
| | |manufacturer and pill size. Proprietary product of MediSpan, Inc., | |
| | |8425 Woodfield Crossing Boulevard, Indianapolis, IN 46240. Tel: (800) | |
| | |428-4495. | |
|MVX |CDC Vaccine Manufacturer |As above, for CVX |Drug code |
| |Codes | | |
|NDA |NANDA |North American Nursing Diagnosis Association, Philadelphia, PA. |Specific Non-Drug Code|
|NDC |National drug codes |These provide unique codes for each distinct drug, dosing form, |Drug code |
| | |manufacturer, and packaging. (Available from the National Drug Code | |
| | |Directory, FDA, Rockville, MD, and other sources.) | |
|NIC |Nursing Interventions |Iowa Intervention Project, College of Nursing, University of Iowa, |Specific Non-Drug Code|
| |Classification |Iowa City, Iowa | |
|NPI |National Provider Identifier |Health Care Finance Administration, US Dep’t. of Health and Human |Specific Non-Drug Code|
| | |Services, 7500 Security Blvd., Baltimore, MD 21244. | |
|OHA |Omaha System |Omaha Visiting Nurse Association, Omaha, NB. |Specific Non-Drug Code|
|OHA |Omaha |Omaha Visiting Nurse Association, Omaha, NB. |Specific Non-Drug Code|
|POS |POS Codes |HCFA Place of Service Codes for Professional Claims (see |Specific Non-Drug Code|
| | |). | |
|RC |Read Classification |The Read Clinical Classification of Medicine, Park View Surgery, 26 |Specific Non-Drug Code|
| | |Leicester Rd., Loughborough LE11 2AG (includes drug procedure and | |
| | |other codes, as well as diagnostic codes). | |
|SDM |SNOMED- DICOM Microglossary |College of American Pathologists, Skokie, IL, 60077-1034. (formerly |Specific Non-Drug Code|
| | |designated as 99SDM). | |
|SNM |Systemized Nomenclature of |Systemized Nomenclature of Medicine, 2nd Edition 1984 Vols 1, 2, |Specific Non-Drug Code|
| |Medicine (SNOMED) |College of American Pathologists, Skokie, IL. | |
|SNM3 |SNOMED International |SNOMED International, 1993 Vols 1-4, College of American Pathologists,|Specific Non-Drug Code|
| | |Skokie, IL, 60077-1034.. | |
|SNT |SNOMED topology codes |College of American Pathologists, 5202 Old Orchard Road, Skokie, IL |Specific Non-Drug Code|
| |(anatomic sites) |60077-1034. | |
|UC |UCDS |Uniform Clinical Data Systems. Ms. Michael McMullan, Office of Peer |Specific Non-Drug Code|
| | |Review Health Care Finance Administration, The Meadows East Bldg., | |
| | |6325 Security Blvd., Baltimore, MD 21207; (301) 966 6851. | |
|UMD |MDNS |Universal Medical Device Nomenclature System. ECRI, 5200 Butler Pike,|Device code |
| | |Plymouth Meeting, PA 19462 USA. Phone: 215-825-6000, Fax: | |
| | |215-834-1275. | |
|UML |Unified Medical Language |National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894.|Specific Non-Drug Code|
|UPC |Universal Product Code |The Uniform Code Council. 8163 Old Yankee Road, Suite J, Dayton, OH |Specific Non-Drug Code|
| | |45458; (513) 435 3070 | |
|UPIN |UPIN |Medicare/HCFA’s universal physician identification numbers, available |Specific Non-Drug Code|
| | |from Health Care Financing Administration, U.S. Dept. of Health and | |
| | |Human Services, Bureau of Program Operations, 6325 Security Blvd., | |
| | |Meadows East Bldg., Room 300, Baltimore, MD 21207 | |
|USPS |United States Postal Service |Two Letter State and Possession Abbreviations are listed in |Specific Non-Drug Code|
| |– Two Letter State and |Publication 28, Postal Addressing Standards which can be obtained from| |
| |Possession Abbreviations |Address Information Products, National Address Information Center, | |
| | |6060 Primacy Parkway, Suite 101, Memphis, Tennessee 38188-0001 | |
| | |Questions of comments regarding the publication should be addressed to| |
| | |the Office of Address and Customer Information Systems, Customer and| |
| | |Automation Service Department, US Postal Service, 475 Lenfant Plaza SW| |
| | |Rm 7801, Washington, DC 20260-5902 | |
|W1, W2 |WHO rec# drug codes |World Health organization record number code. A unique sequential |Drug code |
| | |number is assigned to each unique single component drug and to each | |
| | |multi-component drug. Eight digits are allotted to each such code, | |
| | |six to identify the active agent, and 2 to identify the salt, of | |
| | |single content drugs. Six digits are assigned to each unique | |
| | |combination of drugs in a dispensing unit. The six digit code is | |
| | |identified by W1, the 8 digit code by W2. | |
|W4 |WHO rec# code with ASTM |With ASTM extensions (see Implementation Guide), the WHO codes can be |Drug code |
| |extension |used to report serum (and other) levels, patient compliance with drug | |
| | |usage instructions, average daily doses and more (see Appendix X1 the | |
| | |Implementation Guide). | |
|WC |WHO ATC |WHO’s ATC codes provide a hierarchical classification of drugs by |Drug code |
| | |therapeutic class. They are linked to the record number codes listed | |
| | |above. | |
Barcode Field Proposal
Problem:
Many systems are moving to barcoding functionality as a means to reducing medication dispensing and administration errors. Barcodes must be small enough to fit on medication labels as small as syringes, without losing readability. The filler number combined with the give-sub-id as an instance identifier barcode is too large for many medication labels. Systems have devised individual barcode standards to meet their functional requirements. There currently is no suitable HL7 field to define a dose or instance identifier in a format that is realistic for medication label barcodes.
According to , “By 2005 all US retailers will have to be able to scan all EAN/UCC article numbers (8, 12, 13 and 14-digit).”
Use Case
The following use case provides an example of the reason for this proposal:
1. A pharmacy enters a rotating IV order which contains 3 different bottle types. The pharmacy label printer creates a barcode identifying the particular instance of each of the IV bottles. The barcode is unique to the bottle type (the ingredients contained within the IV bag), the patient and the instance of the bottle but is not unique over all time. The whole code can be easily read by the barcode reader without the user having to commit multiple swipes.
The nurse administers the drug to the patient and swipes both the patient barcode, their staff barcode and the drug barcode to identify who gave what ingredients ( and/or the instance of the drug being administered) to what patient. The information displays on the screen and the user validates. This functionality has been critical to reducing medication administration errors in health care settings.
The RX system receives the administration information with the associated barcode. That system can validate what was given using either the barcode number or the individual component values sent.
2. A pharmacy enters a single ingredient medication order. The barcode identifies the unique service item code for the item to be administered to the patient.
The nurse administers the drug to the patient and swipes both the patient barcode, their staff barcode and the drug barcode to identify who gave what ingredients to what patient. The information displays on the screen and the user validates. This functionality has been critical to reducing medication administration errors in health care settings.
The RX system receives the administration information with the associated barcode. That system can validate what was given using either the barcode number or the individual component values sent.
In both cases sited above, the barcode is used to identify which drug or combination of drugs was administered to which patient and by what clinician. Whether the code defines the give information to the granularity of an instance identifier or not should be negotiated between systems but is typically identified as the service item code for single ingredient drugs and service item and instance id for Ivs. There is a real business need to accommodate a method for using a coded value as created by the dispensing system as a means of documenting and validating administrations of drugs.
Proposed Solution:
Add a new field, Barcode Identifier, to the RXG and RXA segments. The value may define a specific drug, dose and form or identify an instance of that drug, dose and form. In all cases it defines what drug or combination of drugs was given to the patient. The degree of granularity assigned to the barcode is negotiable between systems.
HL7 Attribute Table - RXG
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |4 |NM |R | | |00342 |Give Sub-ID Counter |
|2 |4 |NM |O | | |00334 |Dispense Sub-ID Counter |
|3 |200 |TQ |R | | |00221 |Quantity/Timing |
|4 |100 |CE |R | |0292 |00317 |Give Code |
|5 |20 |NM |R | | |00318 |Give Amount - Minimum |
|6 |20 |NM |O | | |00319 |Give Amount - Maximum |
|7 |60 |CE |R | | |00320 |Give Units |
|8 |60 |CE |O | | |00321 |Give Dosage Form |
|9 |200 |CE |O |Y | |00351 |Administration Notes |
|10 |1 |ID |O | | |00322 |Substitution Status |
|11 |200 |CM |O | | |01303 |Dispense-To Location |
|12 |1 |ID |O | |0136 |00307 |Needs Human Review |
|13 |200 |CE |O |Y | |00343 |Pharmacy/Treatment Supplier’s Special Administration|
| | | | | | | |Instructions |
|14 |20 |ST |C | | |00331 |Give Per (Time Unit) |
|15 |6 |ST |O | | |00332 |Give Rate Amount |
|16 |60 |CE |O | | |00333 |Give Rate Units |
|17 |20 |NM |O | | |01126 |Give Strength |
|18 |60 |CE |O | | |01127 |Give Strength Units |
|19 |20 |ST |O |Y | |01129 |Substance Lot Number |
|20 |26 |TS |O |Y | |01130 |Substance Expiration Date |
|21 |60 |CE |O |Y | |01131 |Substance Manufacturer Name |
|22 |200 |CE |O |Y | |01123 |Indication |
|23 |20 |NM |O | | | |Drug Volume |
|24 |60 |CE |O | | | |Drug Volume Units |
|25 |60 |CE |O | | | |Give Barcode Identifier |
Give Barcode Identifier
Definition: This field contains the pharmacy system’s assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of the order. This number can be an instance identifier; unique for the patient, drug combination, and schedule instance or it may be just a drug identifier.
The composition and use of the barcode number is dependent on application negotiation. An example of this field follows: The barcode number is in the following format, 9XXXXXXX000. The number ‘9’ is a constant, XXXXXXX is seven (7) characters for a unique identifier assigned or derived from the patient account and order ID and 000 is the zero-filled three (3) character IV bottle number.
The maximum length of the first component of this field is 40 characters to allow for the maximum existing barcode length in use today. The second component contains the description of the item being coded and the third component may define the barcode type.
12345678901^IV bottle^3X9
HL7 Attribute Table - RXA
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |4 |NM |R | | |00342 |Give Sub-ID Counter |
|2 |4 |NM |R | | |00344 |Administration Sub-ID Counter |
|3 |26 |TS |R | | |00345 |Date/Time Start of Administration |
|4 |26 |TS |R | | |00346 |Date/Time End of Administration |
|5 |100 |CE |R | |0292 |00347 |Administered Code |
|6 |20 |NM |R | | |00348 |Administered Amount |
|7 |60 |CE |C | | |00349 |Administered Units |
|8 |60 |CE |O | | |00350 |Administered Dosage Form |
|9 |200 |CE |O |Y | |00351 |Administration Notes |
|10 |200 |XCN |O |Y | |00352 |Administering Provider |
|11 |200 |CM |C | | |00353 |Administered-at Location |
|12 |20 |ST |C | | |00354 |Administered Per (Time Unit) |
|13 |20 |NM |O | | |01134 |Administered Strength |
|14 |60 |CE |O | | |01135 |Administered Strength Units |
|15 |20 |ST |O |Y | |01129 |Substance Lot Number |
|16 |26 |TS |O |Y | |01130 |Substance Expiration Date |
|17 |60 |CE |O |Y |0227 |01131 |Substance Manufacturer Name |
|18 |200 |CE |O |Y | |01136 |Substance/Treatment Refusal Reason |
|19 |200 |CE |O |Y | |01123 |Indication |
|20 |2 |ID |O | |0322 |01223 |Completion Status |
|21 |2 |ID |O | |0323 |01224 |Action Code-RXA |
|22 |26 |TS |O | | |01225 |System Entry Date/Time |
|23 |60 |CE |O | | | |Administered Barcode Identifier |
Administered Barcode Identifier
Definition: This field contains the pharmacy system’s assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of the order. This number can be an instance identifier; unique for the patient, drug combination, and schedule instance or it may be just a drug identifier.
The composition and use of the barcode number is dependent on application negotiation. An example of this field follows: The barcode number is in the following format, 9XXXXXXX000. The number ‘9’ is a constant, XXXXXXX is seven (7) characters for a unique identifier assigned or derived from the patient account and order ID and 000 is the zero-filled three (3) character IV bottle number.
The maximum length of the first component of this field is 40 characters to allow for the maximum existing barcode length in use today. The second component contains the description of the item being coded and the third component may define the barcode type.
Example: 12345678901^IV bottle^3X9
Vote: 8 favor, 0 against
Version 3.0 Requirements
We’ll need to account for the new field in 3.0 message instances for medications. There is already an instance identifier that could be used if its definition were changed from an instance throughout all time to an instance in the patient encounter. Otherwise a new identifier should be assigned.
Daphne Young will forward to Gunther.
RXE Proposal – Kaiser Permanente
Problem 1:
We have found that our users are requiring transmission of several pieces of data related to the encoded order currently not available in the RXE segment.
Proposed Solution:
Add fields as follows to the RXE.
RXE - pharmacy/treatment encoded order segment
Note that we have started the numbering of the proposed new fields at 33. This is to accommodate the new field Original order date/time which was approved in May at the Cleveland meeting.
Figure. RXE attributes
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
| | | | | | | | |
|32 |26 |TS |O | | | |Original Order date/time |
|33 |60 |CE |O | | | |Controlled substance schedule |
|34 |1 |ID |O | |NNN | |Formulary status |
|35 |60 |CE |O |Y | | |Pharmaceutical Substance Alternative |
|36 | |CE |O | | | |Pharmacy of most recent fill |
|37 | |NM |O | | | |Initial dispense amount |
Controlled substance schedule (CE)
This field specifies the class of the drug or other substance if it comes under the jurisdiction of the federal Controlled Substance Act (CSA) or a State Uniform Controlled Substance Act. Refer to user-defined table NNN – Controlled Substance Schedule for valid values.
Because some states may extend the list of drugs in a particular class and may create an additional schedule, table NNN is user-defined.
HL7-defined Table 0NNN – Controlled Substance Schedule*
|Value |Description |Explanation |
|I |Schedule I |Includes drugs that have a high potential for abuse, no |
| | |currently accepted medical use in the United States and a lack|
| | |of accepted safety for use under medical supervision. |
|II |Schedule II |Includes drugs having currently accepted medical use in the |
| | |United States and a high abuse potential, with severe |
| | |psychological or physical dependence liability. |
|III |Schedule III |Includes drugs having an abuse potential less than that of |
| | |drugs listed in Schedules I and II. All CS III drugs have a |
| | |currently accepted medical use in the United States. |
|IV |Schedule IV |Includes drugs having a lesser potential for abuse than those |
| | |listed in Schedule III. CS IV drugs have a currently accepted |
| | |medical use in the United States. |
|V |Schedule V |Includes drugs having low abuse potential and limited physical|
| | |or psychological dependence relative to those listed in IV and|
| | |have an accepted medical use in the United States. |
|VI |Schedule VI |State defined |
*Pharmacy Law Digest July 1988
Formulary status (IS)
This field specifies whether or not the pharmaceutical substance is part of the local formulary. Refer to user-defined table 0NNN - Formulary Status for valid values.
User Table NNN – Pharmaceutical Substances
|Value |Description |
|Y |Pharmaceutical substance is in the formulary |
|N |Pharmaceutical substance is NOT in the formulary |
|R |Pharmaceutical substance is in the formulary, but restrictions apply |
|G |Pharmaceutical substance is in the formulary, but guidelines apply |
Pharmaceutical Substance Alternative (CE)
This field specifies a pharmaceutical substance that is in the formulary that could be prescribed in lieu of the substance being prescribed. In the case where the specified medication is non-formulary this field would contain therapeutic alternatives that are on the formulary.
Pharmacy of most recent fill (CE)
This field specifies the pharmacy that last filled the prescription.
Initial dispense amount (NM)
This field specifies the quantity dispensed on the original fill (first fill) of a prescription when that amount is not the same as the quantity to be used in refills. One use case is when a new medication is being prescribed and the prescriber wants to determine if the patient will tolerate the medication. The prescriber indicates that the medication should be filled for an initial amount of 30 tablets and, if tolerated, refilled using a quantity of 100 tablets. In this case, RXE-36 would contain 30 and RXE-10 would contain 100.
If this field is not populated, then the initial dispense amount is the same as RXE-10.
The units are identified in RXE-11.
Vote: 7 favor, 0 against
Problem 2:
The RXE-2 narrative and the attribute table are unclear as to the table that should be used. The attribute table leads one to believe that table 292 be used when in fact its usage is conditional depending on whether or not the item in question is a vaccine or not. In the context of the RDE message, especially a refill authorization request, the substance is rarely a vaccine.
Proposed Solution:
Revise figure 4-16 as follows:
Figure 4-16. RXE attributes
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|2 |100 |CE |R | |0292 |00317 |Give Code |
Amend the RXE-2 as follows:
RXE-2 Give code (CE) 00317
Components: ^ ^ ^ ^ ^
Definition: This field identifies the medical substance or treatment that has been ordered to be given to the patient, as encoded by the pharmacy or treatment supplier; it is equivalent to OBR-4-universal service ID in function. In the RXE segment, this give code must be fully encoded. The dispense fields, which define the units and amount of what is to be issued to the patient (see RXE-10-dispense amount and RXE-11-dispense units below), do not necessarily correlate with the instructions of what amount is to be “given” or administered with each dose, and may or may not be specified with the order. For example, the “give” part of the order may convey the field-representation of give 250 mg of Ampicillin, while the request to dispense part of the order may convey issue 30 tablets of generic equivalent for this outpatient prescription.
If the substance is a pharmaceutical substance other than a vaccine, refer to user-defined table NNN – Pharmaceutical substances for valid values that are site defined. Sites typically use an internal coding scheme, National Drug codes (NDC), Generic Product Identifier (GPI), or Generic Code Number Sequence Number (GCN_SEQNO) as the coding scheme.
The coding system used is conditional on both the nature of the medical substance or treatment ordered and site-specific implementation consideration. The coding system may be an internal user defined table or an external coding systems. Examples of coding systems that might be used include, but are not limited to, National Drug Codes (NDC), Drug Descriptor Identifier (DDID), and in the case of vaccines, HL7 Table 0292 - Vaccines administered. The following examples illustrate
NDC: 0006915404^Norvasc 10mg Tabs^NDC
DDID: 015189^Norvasc 10mg Tabs^DDID
CVX (HL70292): 30^HBIG^CVX
User Table NNN – Pharmaceutical Substances
|Value |Description |
| |No suggested values |
| | |
If the substance is a vaccine, Refer to HL7 Table 0292 - Vaccines administered for valid values.
Vote: 6 favor, 1 abstain, 0 against.
Problem 3:
The RXE-8 Deliver-to location is of the old style data type CM. The CM data type is not resolved in the 2.x HL7 data types DTD. This is a problem when using XML in messaging.
We also have found it difficult or at least awkward to specify if the delivery location is a specific pharmacy; the PL portion of the data type lends itself more to specification of the patient’s location. It would be beneficial to deprecate its usage and replace it with fields that can more accurately specify the pharmacy identifier if the location is a pharmacy, allow for patient location whether inpatient or home delivery, and an address if necessary.
Proposed Solution:
Deprecate the RXE-8 and add fields and amend the RXE attribute table as follows:
Figure. RXE attributes
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
| | | | | | | | |
|8 |200 |CM |B | | |00299 |Deliver-to-location |
| | | | | | | | |
|38 |250 |CE |O | |NNN | |Dispensing pharmacy |
|39 |250 |XAD |O | | | |Dispensing pharmacy address |
|40 |80 |PL |O |Y | | |Deliver-to patient location |
|41 |250 |XAD |O | | | |Deliver-to address |
4.13.4.8 Deliver-to location (CM) 00299
Components: ^ ^ ^ ^ ^ ^ ^
Subcomponents of facility: & &
Subcomponents of address (AD): & < other designation (ST)> & & & & & &
Definition: The first component contains the inpatient or outpatient location to which the pharmacy or treatment supplier is to deliver the drug or treatment (if applicable). The default (null) value is the current census location for the patient. Site-specific table. The first eight components have the same form as the first eight components of PV1-3-assigned patient location. The final eight components replace the ninth component of PV1-3-assigned patient location and represent the full address specification. This field is retained for backward compatiblity only. The reader is referred to RXE-38, RXE-39, RXE-40 and RXE-41.
4.13.4.38 Dispensing Pharmacy (CE)
This field specifies the pharmacy that will dispense the prescription.
Dispensing pharmacy address (XAD)
Components: In Version 2.3 and later, replaces the AD data type. ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^ ^
Subcomponents of street address (SAD): & &
Subcomponents of address validity range (DR): &
This field specifies the address of the dispensing facility.
Deliver-to patient location (PL)
Components: ^ ^ ^ ^ < location status (IS )> ^ ^ ^ ^
This field specifies the location of the patient to whom the pharmaceutical substance is to be delivered.
Multiple names and identifiers for the same location may be send. The field sequences are not used to indicate multiple patient locations, but rather are synonymous.
Deliver-to address (XAD)
Components: In Version 2.3 and later, replaces the AD data type. ^ ^ ^ ^ ^ ^ < address type (ID)> ^ ^ ^ ^ ^
Subcomponents of street address (SAD): & &
Subcomponents of address validity range (DR): &
This field specifies the address, either mailing or physical, to which the prescription should be mailed or delivered.
Vote: 5 favor, 3 abstain, 0 against
Scott will follow-up with forwarding this work into V3.0 Harmonization.
Hard-Stop Indicator Proposal – HBOC
Problem:
Pharmacy systems have concepts of hard-stops and soft-stops. A hard-stop is used to indicate that the order should end at the date and time sent in the end date/time field of the quantity timing field. Most drugs are ordered as hard-stops. Soft-stops are used primarily for antibiotics and other pharmaceuticals where the end date/time is dependent on the treatment outcome. When a soft-stop is used, the pharmacy has two options, one does not end the order at the end date/time but leaves it open to be continued per physician request and does not continue to schedule, the second does not end the order at the end date and time but autoextends the schedules . Receiving systems that perform the scheduling for pharmacy systems need to know whether orders are to be hard-stopped or soft-stopped in order to keep their schedules and statuses in sync.
Proposed Solution:
Add a new field to the RXO, RXC and RXE segments called Hard-Stop Indicator. The field would be used by pharmacy systems to communicate that the order is a hard-stop that ends at the end date/time or that it is a soft-stop that remains active and continues to schedule or does not continue to schedule. Add an HL7 defined table called Hard Stop Indicator with the following values and attributes:
Hard Stop Indicator Table
|Value |Description | | |
|H |Hard Stop |Order becomes inactive and no further schedules |
| | |are created from the order stop date and time |
| | |forward. |
|SN |Soft stop – no auto extend |Order remains active upon reaching the stop |
| | |date/time and the originally defined stop |
| | |date/time remains unchanged. |
|SD |Soft stop – auto extend by duration |Order remains active upon reaching the stop |
| | |date/time, and the stop date/time should be |
| | |advanced by the duration. This would continue |
| | |until the order is manually discontinued. |
HL7 Attribute Table - RXO
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |100 |CE |C | | |00292 |Requested Give Code |
|2 |20 |NM |C | | |00293 |Requested Give Amount - Minimum |
|3 |20 |NM |O | | |00294 |Requested Give Amount - Maximum |
|4 |60 |CE |C | | |00295 |Requested Give Units |
|5 |60 |CE |C | | |00296 |Requested Dosage Form |
|6 |200 |CE |O |Y | |00297 |Provider’s Pharmacy/Treatment Instructions |
|7 |200 |CE |O |Y | |00298 |Provider’s Administration Instructions |
|8 |200 |CM |O | | |00299 |Deliver-To Location |
|9 |1 |ID |O | | |00300 |Allow Substitutions |
|10 |100 |CE |O | | |00301 |Requested Dispense Code |
|11 |20 |NM |O | | |00302 |Requested Dispense Amount |
|12 |60 |CE |O | | |00303 |Requested Dispense Units |
|13 |3 |NM |O | | |00304 |Number Of Refills |
|14 |60 |XCN |C |Y | |00305 |Ordering Provider’s DEA Number |
|15 |60 |XCN |C |Y | |00306 |Pharmacist/Treatment Supplier’s Verifier ID |
|16 |1 |ID |O | |0136 |00307 |Needs Human Review |
|17 |20 |ST |C | | |00308 |Requested Give Per (Time Unit) |
|18 |20 |NM |O | | |01121 |Requested Give Strength |
|19 |60 |CE |O | | |01122 |Requested Give Strength Units |
|20 |200 |CE |O |Y | |01123 |Indication |
|21 |6 |ST |O | | |01218 |Requested Give Rate Amount |
|22 |60 |CE |O | | |01219 |Requested Give Rate Units |
|23 |10 |CQ |O | | |00329 |Total Daily Dose |
|24 |60 |CE |O |Y | |01476 |Supplementary Code |
|25 | |IS |O | | | |Multi-item Order Link Relationship |
|26 | |EI |O | | | |Multi-item Order Link Number |
|27 |20 |NM |O | | | |Drug Volume |
|28 |60 |CE |O | | | |Drug Volume Units |
|29 |2 |ID |O | | | |Hard-Stop Indicator |
| | | | | | | | |
Hard Stop Indicator (ID)
Definition: Indicate ‘H’ if the order should be processed with a hard stop so that it may be discontinued automatically when the end date/time is reached. Indicate ‘SA’ if the order should remain active after the end date/time and continue to produce schedules. Indicate ‘SD’ if the order should remain active but not auto-extend the schedules.
HL7 Attribute Table - RXC
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |1 |ID |R | | |00313 |RX Component Type |
|2 |100 |CE |R | | |00314 |Component Code |
|3 |20 |NM |R | | |00315 |Component Amount |
|4 |60 |CE |R | | |00316 |Component Units |
|5 |20 |NM |O | | |01124 |Component Strength |
|6 |60 |CE |O | | |01125 |Component Strength Units |
|7 |60 |CE |O |Y | |01476 |Supplementary Code |
|8 |20 |NM |O | | | |Drug Volume |
|9 |60 |CE |O | | | |Drug Volume Units |
|10 |2 |ID |O | | | |Hard-Stop Indicator |
(Note that Drug Volume and Drug Volume Units have been accepted for V2.x)
Hard Stop Indicator (ID)
Definition: Indicate ‘H’ if the order should be processed with a hard stop so that it may be discontinued automatically when the end date/time is reached. Indicate ‘SA’ if the order should remain active after the end date/time and continue to produce schedules. Indicate ‘SD’ if the order should remain active but not auto-extend the schedules.
HL7 Attribute Table - RXE
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |200 |TQ |R | | |00221 |Quantity/Timing |
|2 |100 |CE |R | |0292 |00317 |Give Code |
|3 |20 |NM |R | | |00318 |Give Amount - Minimum |
|4 |20 |NM |O | | |00319 |Give Amount - Maximum |
|5 |60 |CE |R | | |00320 |Give Units |
|6 |60 |CE |O | | |00321 |Give Dosage Form |
|7 |200 |CE |O |Y | |00298 |Provider’s Administration Instructions |
|8 |200 |CM |C | | |00299 |Deliver-to Location |
|9 |1 |ID |O | | |00322 |Substitution Status |
|10 |20 |NM |C | | |00323 |Dispense Amount |
|11 |60 |CE |C | | |00324 |Dispense Units |
|12 |3 |NM |O | | |00304 |Number of Refills |
|13 |60 |XCN |C |Y | |00305 |Ordering Provider’s DEA Number |
|14 |60 |XCN |O |Y | |00306 |Pharmacist/Treatment Supplier’s Verifier ID |
|15 |20 |ST |C | | |00325 |Prescription Number |
|16 |20 |NM |C | | |00326 |Number of Refills Remaining |
|17 |20 |NM |C | | |00327 |Number of Refills/Doses Dispensed |
|18 |26 |TS |C | | |00328 |D/T of Most Recent Refill or Dose Dispensed |
|19 |10 |CQ |C | | |00329 |Total Daily Dose |
|20 |1 |ID |O | |0136 |00307 |Needs Human Review |
|21 |200 |CE |O |Y | |00330 |Pharmacy/Treatment Supplier’s Special Dispensing |
| | | | | | | |Instructions |
|22 |20 |ST |C | | |00331 |Give Per (Time Unit) |
|23 |6 |ST |O | | |00332 |Give Rate Amount |
|24 |60 |CE |O | | |00333 |Give Rate Units |
|25 |20 |NM |O | | |01126 |Give Strength |
|26 |60 |CE |O | | |01127 |Give Strength Units |
|27 |200 |CE |O |Y | |01128 |Give Indication |
|28 |20 |NM |O | | |01220 |Dispense Package Size |
|29 |60 |CE |O | | |01221 |Dispense Package Size Unit |
|30 |2 |ID |O | | |01222 |Dispense Package Method |
|31 |60 |CE |O |Y | |01476 |Supplementary Code |
|32 | |IS |O | | | |Multi-item Order Link Relationship |
|33 | |EI |O | | | |Multi-item Order Link Number |
|34 |2 |ID |O | | | |Hard-Stop Indicator |
Hard Stop Indicator (ID)
Definition: Indicate ‘H’ if the order should be processed with a hard stop so that it may be discontinued automatically when the end date/time is reached. Indicate ‘SA’ if the order should remain active after the end date/time and continue to produce schedules. Indicate ‘SD’ if the order should remain active but not auto-extend the schedules.
To be considered as part of TQ1/2 discussion as well. Agreement on the concept, but exact placement may change based on TQ1/2 discussion.
Vote: 6 favor, 1 against, 1 abstain
Version 3.0 Requirements
We’ll need to account for the hard stop indicator in version 3.0 medication order related services. This could be defined as a type of status related to processing of the end date and subsequent schedules. I don’t know if the definition of the current STATUS attribute of the service could be expanded to include these indicators or if a new attribute for defining timing related statuses is needed or if there is already a suitable place to accommodate this information. The indicator is used for pharmacy orders only.
Daphne Young will follow up with Austin on TQ1/2 discussion and V3 discussions.
Modification to Give Code from R to C
Problem:
In the HL7 standard, the following verbiage is contained prior to the RXC segment definition:
If the drug or treatment ordered with the RXO segment is a compound drug OR an IV solution, AND there is not a coded value for OBR-4-universal service ID, which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments.
The same logic is used with the RXO, RXE, RXD, and RXG segments. However, in all of these segments, the respective give codes fields (RXO-1, RXE-2, RXD-2, RXG-4) are defined as ‘R’equired. To comply with the standard while using the RXC segment logic required placing non-functional information in the RXO-1, RXE-2, RXD-2, and RXG-4.
Proposed Solution:
For the RXO, RXE, RXD and RXG, change the R/O/C from ‘R’equired to ‘C’onditional with the conditionality rule defined as follows:
This field is required if no RXC segment are defined following the RXO|RXE|RXD|RXG segment. In other words, this field is optional when RXC segments are defined.
Also change the initial paragraph to:
If the drug or treatment ordered with the RXO segment is a compound drug OR an IV solution, AND there is not a coded value for RXO/RXE/etc. nnn Code, which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments.
Version 3.0 Requirements
This definition would extend to 3.0.
Need technical correction to 4.13.3 to NOT point to OBR-4, but rather RXO/RXE/etc. xyz codes. Not considered a backwards compatability issue since the narrative always allowed for conditional.
Vote: 6 favor, 1 abstain
Orlando V2.x Agenda Items
The following proposals will be on the agenda for Orlando, plus any other ones that may be submitted at least two weeks prior to the meeting. We will add any additional proposal to the back of this list.
❑ V2.4 Overflow
❑ Prescription Refill Request Proposal
❑ RXD Proposal
❑ Proposal for Pharmacy Refill Authorization Request
❑ Order Control Code
❑ Modification to RXG
❑ IV Bottle Type
❑ Pharmacy Dispense Query
-----------------------
[1] The HCPCS code is divided into three "levels." Level I includes the entire CPT-4 code by reference. Level II includes the American Dental Association’s Current Dental Terminology (CDT-2) code by reference. Level II also includes the genuine HCPCS codes, approved and maintained jointly by the Alpha-Numeric Editorial Panel, consisting of HCFA, the Health Insurance Association of America, and the Blue Cross and Blue Shield Association. Level III are codes developed locally by Medicare carriers. The HCPCS modifiers are divided into the same three levels, I being CPT-4 modifiers, II CDT-2 and genuine HCPCS modifiers, and III being locally agreed modifiers.
The genuine HCPCS codes and modifiers of level II can be found at . HCFA distributes the HCPCS codes via the National Technical Information Service (NTIS, ) and NTIS distribution includes the CDT-2 part of HCPCS Level II, but does not include the CPT-4 part (Level I). HCFA may distribute the CPT-4 part to its contractors.
-----------------------
[pic]
[pic]
[pic]
[pic]
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- what does the and mean in odds
- what does and mean in betting
- what are periods and groups in chemistry
- include username password in url
- what causes tingling and numbness in toes
- scope for throat and esophagus
- scope of esophagus and stomach
- esophagus scope what to expect
- how to include a file in python
- can you include closing costs in mortgage
- what is debits and credits in accounting
- what to see and do in boston