Scope: What include and exclude in 3
Minutes of January 2001
Orders/Observations Worksession
Table of Contents
Table of Contents 1
Attendees 2
Monday, January 8, 2001 5
Version 2.x Discussion 5
PM Pre-Cookies – Blood Bank 68
Tuesday, January 9, 2001 69
Co-Chair Election 69
Blood Bank 69
Scope Statements 70
RIM Harmonization Update 71
Joint CDA/MDM/Integration/O&O 71
Wednesday, January 10, 2001 73
Joint II/O&O 73
Lab Messages Continuation 79
Joint LAPOCT 82
Thursday, January 11, 2001 86
Joint Vocab/O&O 86
Pharmacy RIM/Messages 87
Interim V3 Message Definition Effort 88
Friday, January 12, 2001 89
Referral 89
TQ 89
Attendees
|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- | | | |√ | | | | | |
|Judy Audin |Judy_audin@ | | | | |√ | | | | |
|Kay Avant |Kay.avant@ | | | | | | | | |√ |
|Steve Baranowski | | | | |√ | | | | | |
|Calvin Beebe |Cbeebe@mayo.edu | | | |√ | | | | | |
|Fred Behlen |f-behlen@uchicago.edu | | | |√ |√ | | | | |
|Noah Bentley |Noah@ | |√ |√ | | | | | | |
|Jeff Blair |Jeffblair@ | | | |√ | | | | | |
|Chris Brown |Clbrown@ | | | |√ | | | | | |
|Nicholas Brown |Nbrown.mimic@ | | | |√ |√ | | | | |
|Hans Buitendijk |Hans.buitendijk@ |√ |√ |√ |√ |√ |√ |√ |√ |√ |
|Eric Cannon |Eric@.uk | | | |√ | | | | | |
|Jim Case |Jtcase@ucdavis.edu |√ |√ |√ | | √ | | | |√ |
|Carmella Couderc |Carmella.couderc@ | | | |√ | | | | | |
|Miklos Csore |Miklos@ | |√ |√ | | | | | | |
|Bob Dolin |Robert.h.dolin@ | | | |√ | | | | | |
|Tammy Dugan |Tdugan@ | | | | | |√ | | | |
|Dav A. Eide |Eide.d@ |√ |√ |√ |√ | |√ | | | |
|Al Figler |al_figler@ | | | |√ |√ | | | | |
|Edgar Glück |Edgar.gluck@kith.no | | | |√ | | | | | |
|Louis R. Gordon |Louis_gordon@ | | | | | |√ | | |√ |
|Erik Grimmelmann |Egrimmelmann@ | | | |√ | | | | | |
|Nils Graversen |Nils.graversen@radiometer.dk | | | | | |√ | | | |
|Paul Gudmundsson |Hilmar.p.gudmundsson@ |√ | |√ | | | | | |√ |
|Mary Hamilton |Maryhamilton@ |√ | | | | | | | | |
|Charles Hawker |Hawkercd@ | | | | | |√ | | | |
|Ann Hueber |Ahueber@ |√ |√ | | | | | | | |
|Stan Huff |Coshuff@ |√ | | | | | | | | |
|Gaby Jewell |Gjewell@ | |√ |√ | | | | | | |
|Anne Jolly |Jollya@ | |√ | | | |√ | | | |
|Bert Kabbes |Kabbes@wxd.nl | | | |√ | | | | | |
|Martin Kernberg |Mkfrad@ | | | |√ |√ | | | | |
|Jim Kingsland |Jim.kingsland@itb. | | | |√ | | | | | |
|Andrzej J. Knafel |Andrzej.knafel@ | | | | | |√ | | | |
|Helmut König |Helmut.koenig@shs-online.de | | | |√ |√ | | | | |
|Austin Kreisler |Austin.kreisler@itb. |√ |√ | | |√ |√ | | |√ |
|Rebecca Kush |Rkush@ | | | | | |√ | | | |
|Joann Larson |Joann.larson@ncal. |√ |√ | | | | | | | |
|Patti Larson |Plarson@ | |√ |√ |√ | | | | |√ |
|Andrei Leontiev |Andrei_leontiev@ | | | |√ | | | | | |
|Rupert Lugg |Lugg@smh.toronto.on.ca | | | |√ | | | | | |
|Tony Mallia |Tmallia@ | | | | |√ | | | | |
|Tom Marley |t.Marley@salford.ac.uk |√ | | | | | | | | |
|Ken McCaslin |Kenneth.h.mccaslin@ | | |√ | |√ |√ | | |√ |
|Lloyd McKenzie |Lmckenzie@la. | | | | | | | | |√ |
|Jeff McNiel |Jeff_mcniel@ | | | | | | | | |√ |
|Gary Meyer |Gary.meyer@ | | | | | | | | |√ |
|Jason Mimick |Jmimick@ | | | |√ | | | | | |
|Galen Mulrooney |Mulrooneyg-c@ | | | | | |√ | | | |
|Suzanne Nagami |Suzanne.e.nagami@ |√ |√ |√ |√ | |√ | | | |
|Manish Narang |Mnarang@ocdus. | | | | | |√ | | | |
|Thanh-Le Nguyen |Thanhle-nguyen@ |√ |√ |√ |√ | | | | | |
|Karen Nocera |Kyn@ | | | |√ |√ |√ | | | |
|Rory O’Connor |Roryocon@ | | | | |√ | | | | |
|Vassil Peytchev |Vassil@ | | | | | | | | |√ |
|Connie Pinkley |Connie.pinkley@ | | | | | |√ | | |√ |
|Kamran Rastgooy |Kamran.rastgooy@ | | | | | |√ | | | |
|Melvin Reynolds |Melvin_r@amsc.demon.co.uk | | | |√ | | | | | |
|Scott Robertson |Scott.m.robertson@ |√ |√ |√ | | | | | |√ |
|Angelo Rossi Mori |Angelo@r.it | | | |√ | | | | | |
|Alan Rowberg |Arowberg@ | | | |√ |√ | | | | |
|Dan Russler |Dan.russler@ | | | | | | |√ |√ |√ |
|Rhonda Sato |Rhonda.sato@ | | | |√ | | | | | |
|Gunther Schadow |Schadow@regenstrief.iupui.edu | | |√ |√ | | | | |√ |
|Mark Shafarman |Mshafarm@ |√ | | | | | | | |√ |
|Karen Sieber |Ksieber@ | | | |√ |√ |√ | | |√ |
|David Snavely |Dav_snavely@ | | | |√ |√ | | | | |
|Harry Solomon |Harry.solomon@med. | | | |√ |√ | | | | |
|Mary Stehlin |Mary.stehlin@itb. | | | |√ | | | | |√ |
|Helen Stevens |Helen.stevens@ |√ |√ |√ | | | | | | |
|Sadamu Takasaka |S-takasaka@cp.jp. | | | | | |√ | | | |
|Greg Thomas |Greg.j.thomas@ | | | |√ | | | | | |
|Alfredo Tirado-Ramos |Atr@philabs.research. | | | |√ | | | | | |
|Wayne Tracy |Wrtracy@wrt. | | | |√ | | | | | |
|Cheryl Tyus |Ctyus@ | | | |√ |√ | | | | |
|Bruce Wood |Bruce_wood@ | | | |√ |√ |√ | | |√ |
|Daphne Young |Daphne.young@itb. |√ |√ |√ | |√ |√ | | | |
Thursday attendance is documented as part of the Vocabulary minutes as we had a joint session with Vocabulary and Medical Records.
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, January 8, 2001
Version 2.x Discussion
We started the week with a review of V2.x proposals. Thanks to the efforts of the V2.x Focus Group since the St. Louis meeting, many proposals were ready for final review. The focus group will continue through at least the next meeting to complete work on proposals requiring follow-up and/or completion. The following provides a review of all the proposals reviewed and the disposition at this meeting. The numbers in the title reference the proposal number in the V2.x proposal data base available through HL7 HQ.
15: Numeric Range Data Types Proposal
Short Description:
Define a Numeric Range (NR) data type.
Justification:
The OM2-6 Reference (normal) range for ordinal and continuous observations as defined in chapter 8, section 8.8.4.6, has a number of components with an undefined data type. This was uncovered by Frank Oemig during the version 2.4 membership ballotting process. A temporary solution that retained the CM data type but assigned data types to the subcomponents was agreed upon with the understanding that this situation could be corrected with a new data type in the next release.
A Numeric Range (NR) consisting of the following components would meet requirements:
Components ^
The definition needs to include language to allow high or low values only (for single bounded range). This data type could then be applied to the following components of OM2-6:
8.8.4.6.1 - OM2-6.1The reference (normal) range
8.8.4.6.3 - OM2-6.3 Age range
8.8.4.6.4 - OM2-6.4 Gestational age range
The possibility of using the SN - Structured Numeric data type was explored, but the OO subcommittee has rejected that approach believing that it would not be backwards compatible.
This proposal with minor changes was heard and approved in OO subcommittee on 12/13/00 with 7 participants representing HBOC and Kaiser Permanente.
An early version of the proposal was considered in the OO teleconference on October 4. Twelve persons participated in the discussion representing Regenstrief, PIXIS, HBOC, SMS, Quest, and Kaiser Permanente.
2.9 Data Types
2.9.N Numeric range (NR)
^
Definition: Specifies the interval between the lowest and the highest values in a series of data.
In the case of a single bounded series one component may be null.
2.9.N.1 Low value (NM)
Definition: The number specifying the lower limit or boundary of the range.
2.9.N.2 High value (NM)
Definition: The number specifying the high limit or boundary of the range.
Disposition:
We agreed to add clarifying language that this is not intended for general replacement of min/max fields. The proposal was accepted with this modification: Favor: 14, Against: 0, Abstain: 0
16/17: RFR Data Type
Proposals for RFR data type was tabled. We need to check with V3.0 direction. Only applied to Chapter 8 right now. Chapter 7 would require serious backwards compatibility discussion. Need to cover Chapter 7 and 8 together. Proposals 16 and 17 will be further followed up on during the focus group discussions.
21: Specimen Source Data Type
Short Description:
Create a new data type, SPS, to replace the existing CM data type used for OBR-15 and SAC-6.
Justification:
The CM data types defined for ORC-15 and SAC-6 (along with all CM’s) cannot be handled by the XML ITS for version 2.x. This proposal is to create a new data type, the SPS, which can be handled by the XML ITS.
Subcommittee Findings:
The O/O sub-committee on specimen source has decided to move forward with a 2.x proposal for a new data type for specimen source. This data type would replace the existing CM data type used for OBR-15 and SAC-6. The sub-committee is still trying to determine if a new segment or an extension to an existing segment (SAC) will be necessary for dealing with all the issues surrounding specimen source. At a minimum, the new data type will resolve the XML encoding issue in 2.4. This proposal will need to be submitted to both the CQ and OO technical committees.
What this proposal entails:
• Create a new, specific data type for specimen source. This will allow the specimen source to be handled by the XML ITS for version 2.x.
Why create a new data type for specimen:
• It is the simplest, least invasive solution. It does not require any change to current message structures. It will require submissions to the OO technical committee to change the data types of ORC-15 and SAC-6.
• It meets all the requirements of the original Kaiser proposal.
• It does allow multiple specimens to be associated with a single order (by allowing the field to repeat). This would be submitted as a separate proposal for the O/O committee.
This proposal refers to some HL7 tables that are still in flux. The content of these tables has not been added to this proposal for that reason.
The structure of the CM data type from chapter 4, and chapter 13 (ballot version 2.4) is:
Components: ^ ^ ^ ^ ^ ^
This proposal changes the data types of components 1, 4, 5, 6, and 7 from CE to CWE. This is recognition of the fact that no single coding system is going to meet the needs of all users of these components of specimen source. In addition there is a need to be able to communicate the text that is not part of the coding system. The CWE data type is ideal for the requirements of these components.
The proposal also changes the data type of component 2 (additives) from TX to CWE. The sub-committee believes that this sort of data type change is backward compatible. The reason for the selection of the CWE is the same as the other components.
Component 3 (Specimen collection method) was known as freetext in the original CM data type. The sub-committee felt the new name was more descriptive of the component’s purpose. The data type, TX, has not been changed.
ISSUES:
Component 6. The sub-committee found that the narrative for component 6 (Specimen Collection Method Modifier Code) expressed the same intent as SAC-43-"Special Handling Considerations" and changed the description to read "Specimen Handling" rather than "Specimen Collection Method Modifier Code." In addition, HL7 table 0376 Special Handling Considerations was assigned. The submitter (Austin Kreisler) believes that expanding the intent of this component is outside the scope of a data type proposal. This type of change would be appropriate in the context of a new segment proposal, which is one of the alternatives the sub-committee is still looking at. The original language from the CM data type has been retained in this proposal, and has been noted as an issue here.
Suggested Solution:
2.8.?? SPS – specimen source
Components: ^ ^ ^ ^ ^ ^
This data type identifies the site where the specimen should be obtained or where the service should be performed.
2.8.10.0
Specimen source name or code (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
The first component contains the specimen source name or code (as a CWE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) Refer to HL7 Table 0070 - Specimen source codes for valid entries.
Additive (CWE)
This component identifies an additive introduced to the specimen before or at the time of collection. Refer to HL7 Table 0371 – Additive for valid values. The table’s values are taken from NCCLS AUTO4. The value set can be extended with user specific values.
Specimen collection method (TX)
Free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment (i.e., OBX segment).
Body site (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component specifies the body site from which the specimen was obtained. A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:
HL7 Table 0163 - Body site
SNOMED etc.
Site modifier (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component modifies body site. For example, the site could be antecubital fossa, and the site modifier “right.” Refer to HL7 table nnnn Body Site Modifier for allowed values.
Collection method modifier code (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
The sixth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.
Specimen role (CWE)
Subcomponents: ^ ^ ^ ^ ^ ^ ^ alternate coding system version ID (ST)> ^
This component indicates the role of the sample. Refer to User-defined Table 0369 – Specimen role for suggested values. Each of these values is normally identifiable by the systems and its components and can influence processing and data management related to the specimen.
Disposition
The proposed solution is needed for XML encoding. The objective today is to obtain OO approval to submit to CQ and once approved by CQ to deal with the impact on OBR-15 and SAC-6. We agreed on one correction to the proposal (editorial). The proposal was accepted: Favor: 14, Against: 0, Abstain: 0
22: TQ Data Type
Austin provided an update on the TQ1/TQ2 discussions to replace the TQ data type. The major challenge is for other committee (CQ, Sched, PC, MR, LAPOCT) to adopt the new approach and identifying appropriate “sunset” approach for TQ datatype once TQ1/TQ2 definition is complete. We agreed to meet with the respective committee chairs on Friday to gain consensus on the follow-up required.
24: Modification to RXG-1-Give sub-ID counter
Short Description:
Modify RXG-1-Give sub-ID counter narrative to clarify the intent of the field.
Justification:
Continuation of a proposal originally submitted by HBOC to the HL7 Spring 2000 Working Group meeting in Cleveland. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
In the HL7 standard for 2.4 Ballot, following is the definition of RXG-1-Give sub-ID counter:
Definition: Use if this RXG segment carries information about a single administration. Starts with 1 for the first scheduled give date/time transmitted by the pharmacy/treatment supplier for this order. Increments by one with each additional scheduled give date/time for this order.
If the RXG segment carries information about multiple administrations, this field’s value is zero (0), since in this case a one-to-one matching with the RAS segment is ambiguous.
The clear intent with this definition is that this field provides uniqueness of the give instruction associated with the placer order number (ORC-2). In other words, this field defines the unique number of many Give instructions for a single placer order number. This definition also defines the method for deriving the unique number.
However, with a large volume IV order where as part of the single instance of treatment, there are physical bottles with different compositions of base and additives, the level of uniqueness is commonly associated with the physical bottle number. Depending on the pharmacy system’s method of defining and processing IV orders, multiple placer order numbers may be generated to accommodate different bottle types (unique composition of base and additives for the IV order). For example, if there are 16 physical bottles associated with an IV order and there are 2 bottle types, RXG-1-Give sub-ID counter would be incremented for each physical bottle in the whole order. This would yield a Give sub-ID counter that may not start with 1 nor increment by 1 with each additional scheduled give date/time for a bottle.
Subcommittee Findings:
This proposal was presented by Daphne Young (HBOC) to the OO teleconference on October 4, 2000.
Twelve persons participated: (Gunther Schadow, (Regenstrief); Gary Meyer (PIXIS); Daphne Young (HBOC); Austin Kreisler, (HBOC); Rose Jenkins, (SMS); Ken McCaslin, (Quest); Scott Robertson, (KP); Frank Howard, (KP); Thanh-Le Nguyen, (KP); Paul Gudmundsson, (KP); Gina Johnson (KP); and Joann Larson, (KP).
The group considered whether or not there might be a problem with the RXG-2 as well, but determined that until such time as someone posed a specific problem, it would be left as is.
Proposed Solution
Modify the documentation in the standard so that the method for generating a unique number for this field is not defined, thereby allowing sequence of give messages that contain numbers that do not start at 1 nor increment by 1.
A proposed modification to the field definition follows:
Definition: Use if this RXG segment carries information about a single administration. This field must contain a unique number for the placer order number. This field along with the placer order number provides a unique reference to the specific scheduled give date/time transmitted by the pharmacy/treatment supplier for this order.
If the RXG segment carries information about multiple administrations, this field’s value is zero (0), since in this case a one-to-one matching with the RAS segment is ambiguous.
Version 3.0 Requirements
We will need to ensure that the method for tracking medication give sequencing is handled in all version 3.0 medication scheduling message instances as it does today but with the definition changed as proposed herein.
Disposition
There was no discussion. The proposal was accepted: Favor: 14, Against: 0, Abstain: 1
37: Update Values for Table 0070
Short Description:
Update values for HL7 Table 0070- Specimen Source.
Justification:
Continuation of a portion of the Specimen Source Proposal originally submitted by Kaiser Permanente to the HL7 Fall 2000 Working Group meeting in St. Louis. Additions to Table 0070 – Specimen Source, as well as its present values, are currently under investigation by the OO Specimen Source task force. Usefulness of an additional column for comments is under consideration.
Subcommittee Findings:
Specimen source information data was gathered and evaluated by 3 Clinical Lab Scientists who were familiar with 4 implementation sites in Colorado, California and Hawaii. All “4” sites were either using the OBR-15-Specimen source or are about to implement it.
It appeared that users were trying to answer one or more of the following questions regarding specimen source as part of the ordering process:
1. What is it?
2. Where did it come from?
3. How was it collected?
4. How was the specimen transported?
The team entered the results into a spreadsheet and evaluated almost 1200 entries. The following shows the variety of entries that were discovered for table 0070 and what the team plans to do with them:
|Findings |Example |Disposition |
|Procedures |Colonoscopy |Rejected |
| |Suprapubic tap |TBD |
| |Craniotomy |Rejected |
|Diagnoses |Chicken Pox |Rejected |
|Conditions/ Observations |Tissue, acne |Add to Table 70 |
| |Tissue, ulcer |Retained Table 70 |
|Collection Methods |Pump Specimen |Collection Method field |
| |Plate, Thayer-Martin |Collection method field; add “discharge” to|
| | |table 70 |
|Anatomical Locations |Left Hand |Moved to Table 0163 |
|Non-Human sources |Cat Bite, Coral Cut |Retained Table 70 |
|Environmental |Faucet Water |Retained Table 70 |
|Quality Control |Cell Saver Wash |Retained Table 70 |
|Body Substances |Blood, spinal fluid |Retained Table 70 |
|Products or Byproducts of Biological |Finger Nail |Retained Table 70 |
|processes | | |
|Products or Byproducts of Pathological |Pus |Retained Table 70 |
|processes | | |
| |Fibroblasts |Reject |
| |Filter |Retained Table 70 |
|Ambiguous entries |Liquid NOS |Replaced with 2 entries Liquid, |
| | |unidentified, Liquid, unspecified, |
| | |(could be mistaken for No organisms seen) |
| |Line |Deprecated |
Assumptions:
These findings have led to the following assumptions for table 0070:
1. Specimen substances (aka types) would be retained in table 0070.
2. Anatomical locations would be moved to table 0163.
3. Collection methods would be moved to a new table nnnn.
4. The exception to points 2 and 3 above is clinical nomenclature in common usage (body part or collection method is an integral part of the commonly used descriptor) (How you commonly say what you see) Urine, Clean Catch was our gold standard.
5. Diagnoses would not be retained or added.
6. Procedures would not be retained or added.
7. Ambiguous entries would not be retained or added.
8. Entries that accommodate unidentified substances, substances known but not appearing in the table, illegible source, substance not specified would be retained or added. These items are necessary to facilitate entry into a user system.
Formatting:
Entries will begin with a keyword that is a noun.
Definitions:
Specimen substances can include the following:
1. A general type that does not identify a specific body part, e.g., tissue or fluid.
2. An entity that has specific meaning to the Lab, e.g., “Tissue, acne” or “spinal fluid”.
3. A particular situation or condition that caused the creation of the specimen e.g., “cat bite”.
4. A product or byproduct of a biological process e.g., mucus.
5. A product or byproduct of a pathological process e.g., pus.
6. A substance that is contained in a transport container and/or inoculated onto a transport media e.g., “skin scraping” or “discharge” or “nail clippings” Transport media and containers should be included in the OBR^15.3 (Collection Method) [SPM^?].
7. Procedure result e.g., “brushing” or “washing”.
8. A device e.g., “catheter” or “IUD” or “implant” or “pacemaker”
Issues:
• Given that the field name for OBR-15 and SAC-6 is Specimen Source, should we change the name of the first component to “Specimen Type”? The whole field is needed to specify specimen source information not just the first component. It is confusing to give a part the same name as the whole.
• How are we going to handle specimen type modifiers e.g, if “wound” is a specimen substance/type, what do we do with “wound, puncture”. “Wound, puncture” has special meaning to the lab. Should we introduce a new component/field “specimen type modifier”.
• Is it useful to have a code “Source, Other” for situations where the source is known but not in the code table? It is planned that table 70 will be assigned to fields/components having a data type of CWE. Therefore, the “description” would appear in CWE - 6 “original text”.
• If we remove all items that appear to be body parts from table 0070, it changes the nature of the table drastically. Will this give us backwards compatibility issues?
• Should we consider defining a new table NNNN Specimen Type and deprecate table 0070 Specimen Source? Both tables could be offered for use in the OBR-15.1 and SAC-6.1. The data type for these components is CWE and offers other table choices as well.
• How do we handle a specimen from an associated procedure? For example, what do we do with an entry like suprapubic tap? We do not think the OBR^44 (Procedure Code) and OBR^45 (Procedure code modifier) are appropriate for this purpose.
• How are we going to handle blood products and administration devices?
• How are we going to handle associated procedures e.g., craniotomy?
• How are we going to handle associated diagnoses or conditions?
Solution:
Possible Deprecations:
The following table shows 71 values currently in v 2.4 that are under investigation as items to possibly deprecate, largely because they appear to be anatomical locations.
HL7 Table 0070 Recommend Deprecations
|CD Value |CD Name |Category |Comment |
|AMN |Amniotic fluid | |Moved to Table 0163 Body Parts |
|BPH |Basophils | |Moved to Table 0163 Body Parts |
|BIFL |Bile fluid | |Moved to Table 0163 Body Parts |
|BLDA |Blood, Arterial | |Moved to Table 0163 Body Parts |
|BLDC |Blood, Capillary | |Moved to Table 0163 Body Parts |
|BLDV |Blood, Venous | |Moved to Table 0163 Body Parts |
|CBLD |Blood, Cord | |Moved to Table 0163 Body Parts |
|BLD |Blood, Whole | |Moved to Table 0163 Body Parts |
|BDY |Body, Whole | |Moved to Table 0163 Body Parts |
|BRO |Bronchial | |Moved to Table 0163 Body Parts |
|CNL |Canola | |Moved to Table 0163 Body Parts |
|CDM |Cardiac Muscle | |Moved to Table 0163 Body Parts |
|CSF |Cerebral Spinal Fluid | |Moved to Table 0163 Body Parts |
|CVM |Cervical Mucus | |Replace by Mucus & Body Part |
|CVX |Cervix | |Moved to Table 0163 Body Parts |
|CUR |Curettage | |Unclear meaning |
|DIAF |Dialysis Fluid | |Moved to Table 0163 Body Parts |
|DUFL |Duodenal Fluid | |Moved to Table 0163 Body Parts |
|EAR |Ear | |Moved to Table 0163 Body Parts |
|ENDC |Endocardium | |Moved to Table 0163 Body Parts |
|ENDM |Endometrium | |Moved to Table 0163 Body Parts |
|EOS |Eosinophils | |Moved to Table 0163 Body Parts |
|EYE |Eye | |Moved to Table 0163 Body Parts |
|FIB |Fibroblasts | |To specific |
|GEN |Genital | |Moved to Table 0163 Body Parts |
|GENC |Genital Cervix | |Moved to Table 0163 Body Parts |
|GENL |Genital Lochia | |Moved to Table 0163 Body Parts |
|HAR |Hair | |Moved to Table 0163 Body Parts |
|ISLT |Isolate | |Unclear meaning |
|LAM |Lamella | |Moved to Table 0163 Body Parts |
|WBC |Leukocytes | |Moved to Table 0163 Body Parts |
|LN |Line | |Unclear meaning |
|LNA |Line, Arterial | |Moved to Collection Method |
|LNV |Line, Venous | |Moved to Collection Method |
|LIQ |Liquid, NOS | |Unclear meaning |
|LYM |Lymphocytes | |Moved to Table 0163 Body Parts |
|MAC |Macrophages | |Moved to Table 0163 Body Parts |
|MAR |Marrow | |Moved to Table 0163 Body Parts |
|MEC |Meconium | |Moved to Table 0163 Body Parts |
|MILK |Milk, Breast | |Moved to Table 0163 Body Parts |
|NAIL |Nail | |Moved to Table 0163 Body Parts |
|NOS |Nose (Nasal Passage) | |Moved to Table 0163 Body Parts |
|PAFL |Pancreatic Fluid | |Moved to Table 0163 Body Parts |
|PAT |Patient | |Unclear meaning |
|PRT |Peritoneal Fluid /Ascites | |Replace by Fluid & Body Part |
|PLC |Placenta | |Moved to Table 0163 Body Parts |
|PLR |Pleural Fluid (Thoracentesis Fld) | |Moved to Table 0163 Body Parts |
|PMN |Polymorphonuclear Neutrophils | |To specific |
|RBC |Red Blood Cells | |Moved to Table 0163 Body Parts |
|RT |Route Of Medicine | |Ambiguous |
|SEM |Seminal Fluid | |Moved to Table 0163 Body Parts |
|SKM |Skeletal Muscle | |Moved to Table 0163 Body Parts |
|SPRM |Spermatozoa | |Moved to Table 0163 Body Parts |
|STON |Stone (Use CALC) |Condition |Replace by CALC |
|SWT |Sweat | |Moved to Table 0163 Body Parts |
|TEAR |Tears | |Moved to Table 0163 Body Parts |
|THRB |Throat | |Moved to Table 0163 Body Parts |
|THRT |Thrombocyte (Platelet) | |Too specific |
|TISPL |Tissue, Gall Bladder | | |
|TISS |Tissue, Large Intestine | |Replace by Tissue & Body Part |
|TISU |Tissue, Lung | |Replace by Tissue & Body Part |
|TLGI |Tissue, Placenta | |Replace by Tissue & Body Part |
|XXX |To Be Specified In Another Part Of | | |
| |The Message | | |
|TUB |Tube NOS | |Unclear meaning |
|ULC |Ulcer | |Replace by Tissue, Ulcer |
|UMB |Umbilical Blood | |Moved to Table 0163 Body Parts |
|UMED |Unknown Medicine | | |
|USUB |Unknown Substance | | |
|URTH |Urethra | |Moved to Table 0163 Body Parts |
|URNS |Urine, Sediment | | |
|DOSE |Dose Med Or Substance | | |
Possible Additions:
The following table shows 218 values that are still under investigation as additions to table 0070.
HL7 Table 0070 Recommend Additions
|CD Value |CD Name |Category |Comment |
|PELVA |Abscess, Pelvic |Condition | |
|PERIA |Abscess, Perianal |Condition |Abscess & Body Part |
|RECTA |Abscess, Rectal |Condition | |
|SCROA |Abscess, Scrotal |Condition | |
|SUBMA |Abscess, Submandibular |Condition | |
|SUBMX |Abscess, Submaxillary |Condition | |
|TSTES |Abscess, Testicular |Condition | |
|AIRS |Air Sample |Environment | |
|ALL |Allograft |Tissue | |
|AMP |Amputation |Tissue | |
|GASAN |Antrum, Gastric |Tissue | |
|ETA |Aspirate, Endotrach |Aspirate | |
|GASA |Aspirate, Gastric |Aspirate | |
|NGASP |Aspirate, Nasogastric |Aspirate | |
|TASP |Aspirate, Tracheal |Aspirate | |
|TTRA |Aspirate, Transtracheal |Aspirate | |
|AUTP |Autopsy |Tissue | |
|BX |Biopsy |Tissue | |
|GSPEC |Biopsy, Gastric |Tissue | |
|SKBP |Biopsy, Skin |Tissue | |
|CONE |Biospy, Cone |Tissue | |
|BITE |Bite |Conditions | |
|CBITE |Bite, Cat |Conditions | |
| |Bite, Dog |Conditions | |
| |Bite, Human |Conditions | |
| |Bite, Insect |Conditions | |
| |Bite, Reptile |Conditions | |
|BLEB |Bleb |Fluid/Tissue |Condition |
|BLIST |Blister |Fluid/Tissue |Condition |
|HBLUD |Blood, Autopsy |Blood | |
|CSVR |Blood, Cell Saver |Transfusion | |
|FBLOOD |Blood, Fetal |Blood | |
|WB |Blood, Whole |Blood | |
|BOIL |Boil |Condition | |
|BOWL |Bowel contents |Condition | |
|BRSH |Brush |Product | |
|EBRUSH |Brush, Esophageal |Product | |
| |Brushing |Product | |
|GASBR |Brushing, Gastric |Product | |
|BUB |Bubo |Condition | |
|BULLA |Bulla/Bullae |Condition | |
|CARBU |Carbuncle |Condition | |
|CAT |Catheter |Device | |
| |Catheter Insertion Site |Device | |
|ANGI |Catheter Tip, Angio |Device | |
|ARTC |Catheter Tip, Arterial |Device | |
|CVPT |Catheter Tip, CVP |Device | |
|ETTP |Catheter Tip, Endotracheal |Device | |
|FOLEY |Catheter Tip, Foley |Device | |
|HEMAQ |Catheter Tip, Hemaquit |Device | |
|HEMO |Catheter Tip, Hemovac |Device | |
|IDC |Catheter Tip, Indwelling |Device | |
|INTRD |Catheter Tip, Introducer |Device | |
|IVCAT |Catheter Tip, IV |Device | |
|MAHUR |Catheter Tip, Makurkour |Device | |
|SCLV |Catheter Tip, Subclavian |Device | |
|SPRP |Catheter Tip, Suprapubic |Device | |
|SWGZ |Catheter Tip, Swan Gantz |Device | |
|VASTIP |Catheter Tip, Vas |Device | |
|VENT |Catheter Tip, Ventricular |Device | |
|GROSH |Catheter, Groshong |Device | |
|HIC |Catheter, Hickman |Device | |
|PORTA |Catheter, Porta |Device | |
|SPRPB |Cathether Tip, Suprapubic |Device | |
|TLC |Cathether Tip, Triple Lumen |Device | |
|CLIPP |Clippings |Condition | |
|LENS1 |Contact Lens |Device | |
|LENS2 |Contact Lens Case |Device | |
|BCYST |Cyst, Baker's |Condition | |
|ICYST |Cyst, Inclusion |Condition | |
|PILOC |Cyst, Pilonidal |Condition | |
|RENALC |Cyst, Renal |Condition | |
| |Dialysate |Condition | |
|DISCHG |Discharge |Condition | |
|DIV |Diverticulum |Condition | |
|DRN |Drain |Device | |
|HEV |Drain, Hemovac |Device | |
|GTUBE |Drainage Tube, Drainage (Gastrostomy) |Condition | |
|GASD |Drainage, Gastric |Condition | |
|ILEO |Drainage, Ileostomy |Condition | |
|JP |Drainage, Jackson Pratt |Condition | |
|JEJU |Drainage, Jejunal |Condition | |
|NASDR |Drainage, Nasal |Condition | |
|NGAST |Drainage, Nasogastric |Condition | |
|PND |Drainage, Penile |Condition | |
|DRNGP |Drainage, Penrose |Condition | |
|RECT |Drainage, Rectal |Condition | |
|SUMP |Drainage, Sump |Condition | |
|DRNG |Drainage, Tube |Device | |
|EFFUS |Effusion |Condition | |
|AUTOC |Environment, Attest |Environment | |
|ISL |Environmental, Autoclave Capsule |Environment | |
| |Environmental, Isolette |Environment | |
| |Environmental, Solution (Sterile) |Environment | |
|SPS |Environmental, Spore Strip |Environment | |
|STER |Environmental, Sterrad |Environment | |
| |Environmental, Autoclave Ampule |Environment | |
|EFF |Environmental, Effluent |Environment | |
| |Environmental, Eye Wash |Environment | |
| |Environmental, Food |Environment | |
| |Environmental, Other Substance |Environment | (Substance is Known but not in code |
| | | |Table) |
| |Environmental, Soil |Environment | |
|ENVIR |Environmental, Unidentified Substance |Environment | |
| |Environmental, Water |Environment | |
|DEION |Environmental, Water (Deionized) |Environment | |
| |Environmental, Water (Tap) |Environment | |
|FAW |Environmental, Water (Well) |Environment | |
| |Environmental, Water (Ocean) |Environment |Suzanne cooker |
| |Environmental, Whirlpool |Environment | |
|EXUDTE |Exudate |Condition | |
|FLUID |Fluid |Fluid | |
|FGA |Fluid, Abdomen |Fluid | |
|CSMY |Fluid, Cystostomy Tube |Fluid | |
| |Fluid, Acne |Fluid | |
|CST |Fluid, Cyst |Fluid | |
|HYDC |Fluid, Hydrocele |Fluid | |
|IVFLD |Fluid, IV |Fluid | |
|JNTFLD |Fluid, Joint |Fluid | |
|KIDFLD |Fluid, Kidney |Fluid | |
|LSAC |Fluid, Lumbar Sac |Fluid | |
|FLD |Fluid, Other |Fluid | |
|PCFL |Fluid, Pericardial | | |
|RENC |Fluid, Renal Cyst |Fluid | |
|FRS |Fluid, Respiratory |Fluid | |
|SHUNT |Fluid, Shunt |Fluid | |
|FUR |Furuncle |Condition | |
|GRAFT |Graft |Condition | |
|GRAFT |Graft Site |Condition | |
|POPGS |Graft Site, Popliteal |Condition | |
|POPLG |Graft, Popliteal |Condition | |
|GRANU |Granuloma |Condition | |
|IMP |Implant |Device | |
|INFIL |Infiltrate |Condition | |
| |Insect |Object | |
|IUD |Intrauterine Device |Device |Common Usage |
|KELOI |Lavage |Product | |
|LAVG |Lavage, Bronhial |Product | |
|LAVGG |Lavage, Gastric |Product | |
|LAVGP |Lavage, Peritoneal |Product | |
| |Lavage, Pre-Bronch |Product | |
|LESN |Lesion |Condition | |
|ORL |Lesion, Oral |Condition |Common Usage |
|PENIL |Lesion, Penile |Condition |Common Usage |
| |Liquid, Other | | |
| |Liquid, Unspecified | | |
|MASS |Mass |Condition | |
|SMM |Mass, Sub-Mandibular |Condition | |
|MUCOS |Mucosa |Condition | |
|MUCUS |Mucus |Condition | |
|NEDL |Needle |Device | |
|NODUL |Nodule(s) |Condition | |
|CYN |Nodule, Cystic |Condition | |
|PACEM |Pacemaker |Device | |
| |Plant Material |Object |Suzanne Cooker |
|POL |Polyps |Condition | |
|PROST |Prosthetic Device |Device | |
| PSC |Pseudocyst |Condition | |
|PUST |Pus |Condition |Might change to Exudates, Pus |
|PUSFR |Pustule |Condition | |
|QC3 |Quality Control |Environment | |
|RES |Respiratory |Condition |Suzanne Cooker - Ambiguous |
|FSCLP |Scalp, Fetal |Condition |Suzanne Cooker - Ambiguous |
| |Scratch, Cat |Condition | |
|SECRE |Secretion(s) |Fluid/Secretion | |
|NSECR |Secretion, Nasal |Condition | |
|ASERU |Serum, Acute |Blood | |
|CSERU |Serum, Convalescent |Blood | |
|PLEVS |Serum, Peak Level |Blood | |
| |Serum, Trough |Blood | |
|SHUNT |Shunt |Condition | |
|EXS |Shunt, External |Condition | |
|SITE |Site |Site | |
|CVPS |Site, CVP |Site | |
|INCI |Site, Incision/Surgical |Site | |
|NGS |Site, Naso/Gastric |Site | |
|NEPH |Site, Nephrostomy |Site | |
|PIS |Site, Pacemaker Insetion |Site | |
|PDSIT |Site, Peritoneal Dialysis |Site | |
|PDTS |Site, Peritoneal Dialysis Tunnel |Site | |
|PINS |Site, Pin |Site | |
|POPLV |Site, Popliteal Vein |Site | |
|SHU |Site, Shunt |Site | |
|TRAC |Site, Tracheostomy |Site | |
|TZANC |Smear, Tzanck | | |
|GSOL |Solution, Gastrostomy |Product | |
| |Source of Specimen Is Illegible | | |
| |Source, Other | | |
| |Source, Unidentified | | |
| |Source, Unspecified | | |
|DCS |Sputum, Deep Cough |Condition | |
|SPUTIN |Sputum, Inducted |Condition | |
|SPUT1 |Sputum, Simulated |Condition | |
|SPUTSP |Sputum, Spontaneous |Condition | |
|STONE |Stone, Kidney |Condition | |
|SUP |Suprapubic Tap |Product |Additional Discussion |
|SUTUR |Suture |Object | |
|ACNE |Tissue, Acne |Tissue | |
|HERNI |Tissue, Herniated |Tissue | |
| |Tissue, Keloid (Scar) |Tissue | |
|TRANS |Transudate |Condition | |
|ETTUB |Tube, Endotracheal |Device | |
|GT |Tube, Gastric |Device | |
|TUBES |Tubes |Device | |
|IVTIP |Tubing Tip, IV |Device | |
|TUMOR |Tumor |Condition | |
|DEC |Ulcer, Decubitus |Condition | |
|URINB |Urine, Bladder Washings |Condition | |
| |Urine, Catheterized |Condition | |
|USCOP |Urine, Cystoscopy |Condition | |
|URINM |Urine, Midstream |Condition | |
| |Urine, Nephrostomy |Condition | |
| |Urine, Pedibag |Device | |
|RANDU |Urine, Random |Condition | |
|WRT |Wart |Tissue | |
| WASH |Wash |Product | |
| |Washing |Product | |
|WEN |Wen |Tissue | |
| |Worm |Object | |
|PUNCT |Wound, Puncture |Condition | |
Current Table
The following table is the current table 0070 as it appears in v 2.4 with the addition of a Category column and re-organization of the value description so that the keyword appears first; both of these modifications were agreed upon at St. Louis.
HL7 Table 0070 - Specimen source codes
|Value |Description |Category |Comment |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 | | |Brush or brushing |
| |separate entries as 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 | | |Pleural fluid |
| |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| | |To be specified in another|
| |the message | | |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 | | |Wash or washing e.g. |
| |washing | | |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 |
Disposition
Jim Case indicated that 7.4.1.15 reference to veterinary medicine should be replicated in 4.5.3.15. That is a technical fix and will be done. Joann et.al. from OO working on Specimen Source will coordinate with Stan. We did not reach a conclusion on this topic and tabled the discussion for this session.
38: Specimen Handling, 39: Additive
Disposition
These proposals are being pursued as part of the specimen source discussion.
45: Clarify MDM vs ORU Usage
Short Description:
Add language to chapters 7 and 9 clarifying when the MDM message should be used rather than the ORU.
Justification:
Continuation of a portion of a proposal originally submitted by Kaiser Permanente to the Fall 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the suggested change that should reduce the current ambiguity regarding the MDM and the ORU.
Subcommittee Findings:
The second hearing of this proposal occurred via teleconference on 12/13/00. The proposal is supported and will be resubmitted with changes per below discussion.
Participants included Jim Kingsland (HBOC), Thanh-Le Nguyen (Kaiser), Joann Larson (Kaiser), Scott Robertson (Kaiser), Frank Howard (Kaiser), Susanne Nagami (Kaiser), Paul Gudmundsson (Kaiser).
The subcommittee focused its discussion on what was the best approach to clarify the distinction between the ORU and the MDM. It was agreed that pursuing a common language between chapters 7 and 9 was a good first step. Thus the “bullet points” in the indroductory sections of chapters 7 and 9 continued to be very crucial.
The assumption was made that the clinical content in MDM messages is dictated and/or transcribed; clinical content in the ORU message might or might not be transcribed, usually it is not. The fact that clinical content is dictated and/or transcribed could not be the sole criterion to differentiate the two. It was agreed that the third bullet should be removed.
It was then agreed that the clarifying language needed to spell out how the dictated/transcribed messages differed from each other. Hence, the decision to start all of the bullet points with the phrase “Dictated and/or transcribed reports where the whole” meets certain criteria. It was agreed that if one or more of these remaining criteria were met, the appropriate message to use is the MDM. It was also pointed out that the typical reader might not know what was meant by the terms “succession management” and “security status”. These should be defined.
It was agreed that changes to the remaining sections of the chapters would be minimal. Most of the proposed changes were put on hold.
The first discussion of this proposal occurred in the12/6/00 OO Teleconference. Participants at that time were Thanh-Le Nguyen (Kaiser), Joann Larson (Kaiser), Austin Kreisler (HBOC), Scott Robertson (Kaiser), Daphne Young (HBOC), Frank Howard (Kaiser), Susanne Nagami (Kaiser), Greg Thomas (Kaiser), Paul Gudmundsson (Kaiser)
Issue 1: Need definition of the terms “succession management” and “security status”.
Issue 2: Chapter 7 talks about reports; chapter 9 talks about documents. Is more clarification needed?
Original Problem Statement:
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.
Solution:
An earlier version of this proposal was accepted by the Medical Record TC contingent upon approval by Orders and Observation TC.
7.2 - 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 one or more 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.
• Reports where the whole requires a signature as part of the message.
• Reports where the whole requires authentication as part of the message.
• Reports requiring succession management (of both document addenda and replacement documents) as part of the message.
• Reports where the content requires a security status applying to the whole as part of the message.
9.2 - 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.
• Dictated and/or transcribed reports where the whole requires a signature
• Dictated and/or transcribed reports where the whole requires authentication
• Dictated and/or transcribed reports requiring succession management (of both document addenda and replacement documents).
• Dictated and/or transcribed reports 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.
Disposition
We agreed to carry the proposal to MR with the modifications incorporated for further review. If Jim Case cannot work their use of MDM into ORU, he will come up with a proposal. The proposal was accepted for forwarding: Favor: 12; Against: 0; Abstain: 0
47: NTE Clarification Proposal
Short Description:
Add language to the NTE segment narrative to clarify the placement of the NTE segment relative to its target segment.
Justification:
Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
There does not seem to be a standard way of associating NTE segments with the target segment. Some messages have the NTE segment inserted immediately after the target segment; some have it inserted several segments later at the end of the group. This leads to confusion as to which segment is really being noted or if the NTE applies to the entire segment group. This is especially true if clarifying language has not been added to the end of the NTE description “for the ”.
OO is in the process of adding NTE segments to a number of messages and would like to have a standard method declared.
Additionally, it is recommended that all chapters should be reviewed for consistency with this proposal.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• NTE consistency of use issue noted in St. Louis Orders and CQ TC’s. This proposal addresses this inconsistency. Discussion of range of impact – NTEs are used widely with varying degrees of clarity. Recommend that all chapters review the use and clarity of NTE in their messages
• Action item: add line “Chapters define the meaning of NTE segments within the context of the messages in the chapter.” Add to justification statement suggestion to review all chapters
• Outcome: Group concurs to endorse with changes and submit to Orders and CQ in Orlando.
Solution:
2.16.10 NTE - notes and comments segment
The NTE segment is defined here for inclusion in messages defined in other chapters. It is commonly used for sending notes and comments.
The Chapters define the meaning of the NTE segments within the context of the messages in the chapter. For each NTE, the description in the message attribute table should include an indication of the segment associated with the NTE, for example “Notes and Comments for the PID”.
Disposition
CQ sees no problem and no further comments were made. The proposal was accepted: Favor: 13; Against: 0; Abstain: 0
48: Order Control Code Proposal
Short Description:
Add an order control code to table 119 to indicate an informational order (record but do not act upon order).
Justification:
Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Currently there is no way to satisfactorily indicate that an ordered drug will be dispensed at an outside pharmacy. The Clinical System wishes to communicate this to the internal Pharmacy for purposes of tracking drug profiles and potential drug interactions. If Control Code “NW” is used, there would be no way for the pharmacy to know that they were not supposed to dispense the prescription.
Use Case: The patient elects to take a prescription to a pharmacy not connected with the provider’s health care enterprise. The health care enterprise wishes to include this prescription in the patient’s drug profile regardless of where the prescription is filled.
NOTE: We believe that a new order control code “OP” was accepted at the Cleveland meeting, but the minutes are unclear.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on October 18, 2000. Six persons participated in the discussion: Gary Meyer (PIXIS); Daphne Young (HBOC); Austin Kreisler, (HBOC); Heather Von Allmen, (SMS); Frank Howard, (KP); and Joann Larson, (KP).
There was some concern expressed as to whether or not a new order control code was the best method for indicating to the receiving system that the order was informational only and not to be filled by the receiver. KP responded that the code needed to be at a high level and that an action such as updating the patient’s drug profile would potentially be taken. The group inquired if there then would need to be a whole set of new control codes to handle holds, replaces, cancels, etc that would also be informational only?
Action item: KP to clarify how future orders stemming from this original order would be interpreted by the receiving system. Also need to determine if a new RIM attribute will be needed.
Action Item Response:
In this proposal, the Placing system sends an order with ORC-1 of ‘OP’ to instruct the Filling system to encode an order but the ordered service is not to be performed. The use case proposes that the Filling system would use this encoded-but-not-performed-order to maintain a complete clinical profile for the patient, which may impact other current or future orders.
Once such an order has been encoded, most other defined OCCs would, in most cases, still be relevant. Subsequent messages indicating Cancel (CA), Discontinue (DC), Hold (HD), Release (RL), or Change (XO) could still be logically applied to an order that originated as Notification of order for outside dispense (OP). The fact that the Filler was previously told not to perform the service does not preclude that the status or content of the order might not change over time. These changes may be relevant to a Filling system that is maintaining a complete clinical profile.
On the other hand, a Refill order request (RF) message could not be logically applied to an “outside dispense” order as the Placer previously informed the Filler never to perform the service. The Filler would respond to this request with Unable to refill (UF).
An exceptional case appears with a subsequent Replace (RP/RO) message. The replacement order (RO) portion would be considered as an imperative to perform the service as would a New order (NW) (assuming that other message content does not preclude the Filler from ever performing the service). This is acceptable when the intent is to have the Filler perform the service. However, if the Placer intends this as an informational message (as with OP), then the Placer needs some means to communicate this. Options include (1) define another OCC to perform the same function as OP in the RP/RO construct, or (2) allow for the construction of an RP/OP message.
Implementation of the OP message in v3.0 should not require addition of an attribute to the RIM. If Order Control Codes are converted to Mood or Service attributes of Act, the OP would be another define value for the appropriate attribute. If OCCs are represented as Messages in v3.0 then, again, OP would be another defined value rather than an additional attribute.
Outcome:
This proposal was reviewed in the OO teleconference on October 18, 2000. Six persons participated in the discussion: Gary Meyer (PIXIS); Daphne Young (HBOC); Austin Kreisler, (HBOC); Heather Von Allmen, (SMS); Frank Howard, (KP); and Joann Larson, (KP).
There was some concern expressed as to whether or not a new order control code was the best method for indicating to the receiving system that the order was informational only and not to be filled by the receiver. KP responded that the code needed to be at a high level and that an action such as updating the patient’s drug profile would potentially be taken. The group inquired if there then would need to be a whole set of new control codes to handle holds, replaces, cancels, etc that would also be informational only?
Action item: KP to clarify how future orders stemming from this original order would be interpreted by the receiving system. Also need to determine if a new RIM attribute will be needed.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Response to prior action items. In general, additional “down-stream” Order Control Codes do not need to be replicated in the style of OP. One exception was noted in RO, where two options were presented and discussed. The Group agreed that another Order Control Code was necessary to extend the OP concept to RO.
• Action item: Revise proposal to include another OCC replicating OP in the context of RO.
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando
4.4.1.1 ORC-1 Order Control Code (ID) 00215
HL7 Table 0119 - Order control codes and their meaning
|Value1 |Event/Message Type |Description |Originator2 |Field Note3 |
| | | | | |
|OP |OMP^O09^OMP_O09 |Notification of order for outside dispense |P |w |
|PY |OMP^O09^OMP_O09 |Notification of replacement order for outside |P,F |w |
| | |dispense | | |
Table notes for order control codes of ORC
…
w) OP, PY
These order control codes are used to communicate an order between systems where the order is intended for informational purposes. For example, an order that will be performed by a vendor outside the enterprise of communicating systems. The communicating systems may need to maintain information relative to the order for clinical continuity, but no actions to perform the ordered service are intended.
OP represents an informational version of NW, PY represents the informational-only version of RO. NW and RO table notes also apply to OP and PY, respectively.
Disposition
No additional discussion. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
49: RDE^ONN - Pharmacy Refill Authorization Request
Short Description:
Define a new trigger event (ONN) for Refill Authorization Request.
Justification:
Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
After some experience with using the RDE for a request for Refill Authorization, we find we have a need for a unique trigger event for this process. This event is as distinct as the other pharmacy triggers of order, encode, dispense and administer. While this event is as distinct as other pharmacy triggers, the content of the message does not deviate significantly from the RDE message as presently defined. We need to be able to determine at the MSH-9 level what the message is for routing purposes.
We considered creating a new message type (e.g., RDA), but the required structural content was the same as the RDE message. Creating a new message type appeared to be unwarranted. Creating a new trigger event appears to satisfy our operational needs.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Review of action item response. Review of message structure did not reveal any non-functional segments to be deleted
• Outcome: Group concurs to endorse and submit to Orders in Orlando.
Outcome:
This proposal was reviewed in the OO teleconference on November 13, 2000. Seven persons participated in the discussion: Helen Stevens, (HBOC); Austin Kreisler, (HBOC); Gary Meyer, (PYXIS); Daphne Young, (HBOC); Frank Howard, (KP); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee supports the definition of a new trigger event for Refill Authorization Request. The subcommittee asked KP to evaluate the segments to see if the message could be pared down.
Action Item: Scott Robertson to investigate if any of the segments can be deleted.
Action Item Response:
Review of the message structure did not reveal any non-functional segments within the context of a refill authorization request. While some segments, such as OBX, are not currently used in our implementation they do have functionality that others might be using or that we may use in the future.
Additionally, deleting segments would require a new message structure definition (e.g., RDE_Onn). While that is not a significant change, it would seem unnecessary. The RDE_O11 message structure provides a single model that appears to work well for a variety of pharmacy/treatment encoded order messages.
Suggested Solution:
One possible chapter 4 revision to accommodate this new trigger code would be to define another trigger pair to the present RDE definition in section 4.12.5. The narrative would then include the specification that the specific trigger event implies a specific message context. However, we could not find this formatting concept elsewhere in the standard.
The revision we are presenting is to add another section to chapter 4, essentially duplicating the current RDE message with narrative indicating that the purpose of this message/trigger is to communicate a refill authorization request.
Revise 4.12.5 Pharmacy/treatment encoded order message to indicate the specific case of refill authorization request messages.
4.12.5 RDE - pharmacy/treatment encoded order message (O11)
This message communicates the pharmacy or treatment application’s encoding of the pharmacy/treatment order (ORM message with RXO segment, see above). It may be sent as an unsolicited message to report on either a single order or multiple pharmacy/treatment orders for a patient.
The RDE/RRE is also used to communicate a refill authorization request originating with the pharmacy. The RDE/RRE message pair can also be used to communicate a refill authorization request, however, a specific trigger event has been assigned. See section 4.12.N Pharmacy/treatment refill authorization request message.
As a site-specific variant, the original order segments (RXO, RXRs, associated RXCs, and any NTEs) may be sent optionally (for comparison).
Define a new trigger, Onn, for Refill Authorization and a trigger for its acknowledgement.
4.12.N RDE - Pharmacy/treatment refill authorization request message (Onn)
The RDE/RRE is used to communicate a refill authorization request originating with the pharmacy. This message replicates the standard RDE message with a different trigger event code to indicate the specific use case of a refill authorization request.
|RDE^Onn^RDE_O11 |Pharmacy/Treatment Refill Authorization Request |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 | |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
|[ | | |
| RXO |Pharmacy/Treatment Prescription Order |4 |
| [{NTE}] |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component (for RXO) |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
|] | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| [{NTE}] |Notes and Comments (for RXE) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component (for RXE) |4 |
| { | | |
| [OBX] |Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| } | | |
| [{FT1}] |Financial Detail |6 |
| [BLG] |Billing Segment |4 |
| {[CTI]} |Clinical Trial Identification |7 |
|} | | |
4.12.N RRE - Pharmacy/Treatment Refill Authorization Request Acknowledgment (Onn)
|RRE^Onn^RRE_O12 |Pharmacy/Treatment Refill Authorization Request Acknowledgment Message |Chapter |
|MSH |Message Header |2 |
|MSA |Message Acknowledgment |2 |
|[ERR] |Error |2 |
|[{NTE}] |Notes and Comments (for Header) |2 |
|[ | | |
| [PID |Patient Identification |3 |
| [{NTE}] |Notes and Comments (for PID) |2 |
| ] | | |
| { | | |
| ORC |Common Order |4 |
| [ | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| ] | | |
| } | | |
|] | | |
Version 3.0 Considerations:
(added to proposal 12/19/00) This request for a new trigger event would appear to be supported in v3.0 as a specific value of Message.interaction_id. Further consideration of this assumption and the Message.interaction_id value assigned for this purpose are pending discussion and definition of the orders messages in v3.0.
Disposition
Only question raised was whether changes were needed to the RDE. That did not turn out to be necessary. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
51: Add NTE to RDE Message
SHORT DESCRIPTION:
Add an NTE segment associated with the RXE segment in the RDE Message.
JUSTIFICATION:
Pursuant to ballot question originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis, the Orders TC requested a proposal be developed. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
The available attributes in the RXE segment of the RDE message do not provide a means to communicate notes associated with the encoded order. The addition of an NTE segment relative to the RXE segment would allow for such notes without adding attributes to the RXE segment. Functionally, this emulates the NTE associated with the RXO, but in the context of the encoded order rather than the requested order.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Noted that the use of NTE needs to be specific per recommendation of NTE Clarification proposal. Discussion of best means to include clarification. Addition of table footnote may not be compatible to standards database. Note following table appears to be best option.
• Action item: Correct reference to RDE message. Add note following table clarifying NTE use.
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando.
SUGGESTED CHANGE:
RDE - pharmacy/treatment encoded order message (event O11)
This message communicates the pharmacy or treatment application’s encoding of the pharmacy/treatment order (ORM message with RXO segment, see above). It may be sent as an unsolicited message to report on either a single order or multiple pharmacy/treatment orders for a patient.
The RDE/RRE is also used to communicate a refill authorization request originating with the pharmacy.
As a site-specific variant, the original order segments (RXO, RXRs, associated RXCs, and any NTEs) may be sent optionally (for comparison).
|RDE^O11^RDE_O11 |Pharmacy/Treatment Encoded 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 | |
| [IN2] |Insurance Additional Info |6 |
| [IN3] |Insurance Add’l Info - Cert. |6 |
| }] | | |
| [GT1] |Guarantor |6 |
| [{AL1}] |Allergy Information |3 |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy/Treatment Prescription Order |4 |
| [{NTE}] |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component (for RXO) |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| ] | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| [{NTE}] |Notes and Comments (for RXE) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component (for RXE) |4 |
| [{ | | |
| OBX |Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| }] | | |
| {[CTI]} |Clinical Trial Identification |7 |
|} | | |
Note: The RXCs which follow the RXO may not be fully encoded, but those that follow the RXE must be fully encoded.
Note: The NTE segment(s) following the PD1 segment are intended to communicate notes and comments relative to the patient.
The NTE segment(s) following the RXO segment are intended to communicate notes and comments relative to the pharmacy/treatment order.
The NTE segment(s) following the RXE segment are intended to communicate notes and comments relative to the encoded order.
The NTE segment(s) following the RXC segment are intended to communicate notes and comments relative to the component(s).
The NTE segment following the OBX segment is intended to communicate notes and comments relative to the results.
Disposition
There was no additional discussion. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
52: Add NTE to RDS Message
SHORT DESCRIPTION:
Add NTE segments associated with the RXE and RXD segments in the RDS Message.
JUSTIFICATION:
Pursuant to ballot question originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis, the Orders TC requested a proposal be developed. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
The available attributes in the RXE segment of the RDS message do not provide a means to communicate notes associated with the encoded order. The addition of an NTE segment relative to the RXE segment would allow for such notes without adding attributes to the RXE segment. Functionally, this emulates the NTE associated with the RXO, but in the context of the encoded order rather than the requested order.
Similarly, he available attributes in the RXD segment of the RDS message do not provide a means to communicate notes associated with the dispense event. The addition of an NTE segment relative to the RXD segment would allow for such notes without adding attributes to the RXD segment. Functionally, this emulates the NTE associated with the RXO, but in the context of the dispense event rather than the requested order.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Noted that the use of NTE needs to be specific per recommendation of NTE Clarification proposal.
• Action item: Add note following table clarifying NTE use.
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando.
SUGGESTED CHANGE:
RDS - pharmacy/treatment dispense message (event O13)
…
|RDS^O13^RDS_O13 |Pharmacy/Treatment Dispense 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 PID) |2 |
| [{AL1}] |Allergy Information |2 |
| [ | | |
| PV1 |Patient Visit |3 |
| [PV2] |Patient Visit - Additional Info |3 |
| ] | | |
|] | | |
|{ | | |
| ORC |Common Order |4 |
| [ | | |
| RXO |Pharmacy /Treatment Order |4 |
| [ | | |
| {NTE} |Notes and Comments (for RXO) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [ | | |
| {RXC} |Pharmacy/Treatment Component |4 |
| [{NTE}] |Notes and Comments (for RXC) |2 |
| ] | | |
| ] | | |
| ] | | |
| [ | | |
| RXE |Pharmacy/Treatment Encoded Order |4 |
| [{NTE}] |Notes and Comments (for RXE) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| ] | | |
| RXD |Pharmacy/Treatment Dispense |4 |
| [{NTE}] |Notes and Comments (for RXD) |2 |
| {RXR} |Pharmacy/Treatment Route |4 |
| [{RXC}] |Pharmacy/Treatment Component |4 |
| [{ | | |
| OBX |Results |7 |
| [{NTE}] |Notes and Comments (for OBX) |2 |
| }] | | |
| [{FT1}] |Financial Transaction segment |6 |
|} | | |
Note: The NTE segment(s) following the PD1 segment are intended to communicate notes and comments relative to the patient.
The NTE segment(s) following the RXO segment are intended to communicate notes and comments relative to the pharmacy/treatment order.
The NTE segment(s) following the RXE segment are intended to communicate notes and comments relative to the encoded order.
The NTE segment(s) following the RXD segment are intended to communicate notes and comments relative to the dispense event.
The NTE segment(s) following the RXC segment are intended to communicate notes and comments relative to the component(s).
The NTE segment following the OBX segment is intended to communicate notes and comments relative to the results.
Disposition
There was no additional discussion. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
53: RXD add Dispensing Pharmacy fields
SHORT DESCRIPTION:
Add Dispensing Pharmacy and Dispensing Pharmacy Address fields to the RXD segment
JUSTIFICATION:
Continuation of a component of proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Problem 1: We have discovered that specifying the Dispensing Pharmacy needs to be comparable to the Initiating Location and the Packaging/Assembly Location. Burying it in the RXD-13 Dispense-to-Location is confusing, contains unnecessary components, and is also a problem if we need to include the pharmacy responsible for the dispense and the prescription is to be delivered to the patient’s home.
We also have found it difficult or at least awkward to specify if the dispense 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 add fields that can more accurately specify the pharmacy identifier if the location is a pharmacy and an address if necessary
Note: This proposal was presented as part of a larger proposal in St. Louis. This portion, the addition of Dispensing pharmacy location and address, was accepted but the remaining proposal elements were referred to the OO Teleconference for further discussion. These two fields have been separated from the remainder of the original proposal for acceptance.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Note that this proposal was contained in within a proposal heard in St Louis. This portion of the original proposal was accepted but the other part was deferred for further work in subcommittee. At this time, only this portion is being brought forward, remainder will be submitted in the future. Inconsistency between attribute table names and narrative names, to be corrected.
• Action item: Correct proposed table attribute names for consistency with remainder of proposal
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando.
SUGGESTED CHANGE:
Add Dispensing Pharmacy and Dispensing Pharmacy Address fields to the RXD segment.
RXD - pharmacy/treatment dispense segment
HL7 Attribute Table - RXD
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
|28 |180 |CE |O | | | |Dispense to Pharmacy |
|29 |106 |XAD |O | | | |Dispense to pharmacy address |
4.13.5.28 RXD-28 Dispense to pharmacy (CE)
Components: ^ ^ ^ ^ ^
This field specifies the pharmacy that will dispense the prescription.
4.13.5.29 RXD -29 Dispense to 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 or the patient’s location.
Disposition
There was no additional discussion. The proposal was accepted: Favor: 14; Against: 0; Abstain: 2
54: Add RXR-6 Site Modifier to RXR Segment
SHORT DESCRIPTION:
Add Administration Site Modifier as a new field (RXR-6) to the RXR Segment
JUSTIFICATION:
Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee and the Specimen Source Task Force reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension as delineated in the Proposed Solution below.
The extensive review of HL7 Table 0163 – Body Site as related to Specimen Source has resulted in the development of a new HL7 Table ???? – Body Site Modifier. Table 0163 has been simplified to some degree by removing compound references (e.g., left arm) and retaining simple designations (e.g., arm). The new table of modifiers (e.g., left, right, etc) is used in conjunction with Table 0163 to specify a body site. Since RXR-2 – Administration Site utilizes Table 0163 a new field needs to be added to the RXR segment to support the concepts contained within HL7 Table ???? – Body Site Modifier.
Request for changes to Table 0163 were heard in both Orders and Vocabulary TCs at St. Louis. They directed that proposal be prepared to add a new field to RXR to maintain accommodate the site modifiers that are being removed from Table 0163.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Required as a result of changes to Table 0163. Current proposal may pose a backward compatibility problem. Alternative discussed: change RXR-2 and RXR-6 to CWE, leave reference to 0163 for backward compatibility, recommend two new fields (that are replacing 0163) as standard usage.
• Action item: Advise group working on table 0163 of need to create two new tables rather than replacing 0163 with new content
• Action item: Create new proposal to change RXR-2 data type to CWE and deprecate 0163 in favor of two new tables in development.
• Action item: Revise RXR-6 proposal, change data type to CWE, update narrative
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando.
SUGGESTED CHANGE:
RXR - pharmacy/treatment route segment
The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed as they apply to a particular order. The pharmacy, treatment staff and/or nursing staff has a choice between the routes based on either their professional judgment or administration instructions provided by the physician.
HL7 Attribute Table – RXR – Pharmacy/Treatment Route
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
|6 |250 |CWE |O | |???? |????? |Administration Site Modifier |
RXR field definitions
…
2 RXR-6 Administration site modifier (CWE) ?????
Components: ^ ^ ^ ^ ^
Definition: This field contains the site modifier, used in conjunction with RXR-2, of the administration route. Refer to HL7 Table ???? – Body Site Modifier for valid values.
As this field modifies the meaning of RXR-2 Administration Site, this field should only be populated if RXR-2 is populated. However, population of RXR-2 does not require RXR-6 to be populated.
When RXR-2 Administration Site is populated from HL7 Table 0163 – Body Site, RXR-6 Administration site should not be populated with values from HL7 Table ???? – Body Site Modifier.
Disposition
This proposal is tied to specimen source discussion. We agreed that if approved it would still depend on the resolution of the other discussions in progress.. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
55: RXR-2 Data Type Change to CWE
SHORT DESCRIPTION:
Change RXR-2 Administration Site data type to CWE, update narrative.
JUSTIFICATION:
Continuation of a proposal originally submitted by Kaiser to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee and the Specimen Source Task Force reviewed the original response and offers this extension. The subcommittee has reviewed and supports this extension as delineated in the Proposed Solution below.
The extensive review of HL7 Table 0163 – Body Site as related to Specimen Source has resulted in the development of a new HL7 Table ???? – Body Site Modifier. Table 0163 has been simplified to some degree by removing compound references (e.g., left arm) and retaining simple designations (e.g., arm). The new table of modifiers (e.g., left, right, etc) is used in conjunction with Table 0163 to specify a body site. Since RXR-2 – Administration Site utilizes Table 0163 a new field needs to be added to the RXR segment to support the concepts contained within HL7 Table ???? – Body Site Modifier.
Request for changes to Table 0163 were heard in both Orders and Vocabulary TCs at St. Louis. They directed that proposal be prepared to add a new field to RXR to maintain accommodate the site modifiers that are being removed from Table 0163.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Required as a result of changes to Table 0163. Current proposal may pose a backward compatibility problem. Alternative discussed: change RXR-2 and RXR-6 to CWE, leave reference to 0163 for backward compatibility, recommend two new fields (that are replacing 0163) as standard usage.
• Action item: Advise group working on table 0163 of need to create two new tables rather than replacing 0163 with new content
• Action item: Create new proposal to change RXR-2 data type to CWE and deprecate 0163 in favor of two new tables in development.
• Action item: Revise RXR-6 proposal, change data type to CWE, update narrative
• Outcome: Group concurs to endorse with changes and submit to Orders in Orlando.
SUGGESTED CHANGE:
RXR - pharmacy/treatment route segment
The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed as they apply to a particular order. The pharmacy, treatment staff and/or nursing staff has a choice between the routes based on either their professional judgment or administration instructions provided by the physician.
HL7 Attribute Table – RXR – Pharmacy/Treatment Route
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
| | | | | | | | |
|2 |250 |CE CWE |O | |0163 |00310 |Administration Site |
| | | | | | | | |
RXR field definitions
…
2 RXR-2 Administration site (CE CWE) 00310
Components: ^ ^ ^ ^ ^
Definition: This field contains the site of the administration route. Refer to HL7 Table 0163 ???? – Body Site for valid values. RXR-6 Administration site (HL7 Table ???? – Body Site Modifier) may be used to modify the meaning of this field.
HL7 Table ???? – Body Site is the preferred reference source for this field. References to HL7 Table 0163 – Body Site be used for backward compatibility only. When HL7 Table 0163 – Body Site is used, RXR-6 Administration site should not be populated with values from HL7 Table ???? – Body Site Modifier.
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).
Disposition
This proposal is tied to specimen source discussion. We agreed that if approved it would still depend on the resolution of the other discussions in progress. Agreed it is better to replace then fix up and turn into two tables. The proposal was accepted: Favor: 14; Against: 0; Abstain: 1
56: Update Figure 7.2 Example
Short Description:
Change the example in figure 7.2 to reflect that it is an MDM message and copy to chapter 9.
Justification:
Continuation of a portion of the MDM vs ORU proposal originally submitted by Kaiser Permanente to the Fall 2000 Working Group meeting in St. Louis. The OO General Subcommittee reviewed the proposal on December 13 and supports this portion regarding changes to figure 7.2.
The example in figure 7.2 of chapter 7 meets criteria for when the MDM message should be used. The MSH-9 should be changed accordingly and required segments should be present. Because the example goes on to demonstrate usage of the OBX-4, it is appropriately placed in the OBX definition section of chapter 7 and should not be removed. However, it should also be copied to chapter 9 because it is a good example of an MDM message using the new OBR/OBX segments.
Solution:
7.4.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 the message fragment in Figure 7-2. This construct may be used in an MDM or ORU message.
Figure 7-2. Example of sub-identifier usage
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...
9.7 Example Message
A single surgical pathology report that describes the examination of gallbladder and appendix tissue would be transmitted roughly as shown below.
OBR|1|||88304^SURG PATH REPORT^|...
TXA
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...
Disposition
This topic is related to the use of MDM/ORU. We modified the text as reflected in the proposal. This will be forwarded to MR TC. Favor: 11; Against: 0; Abstain: 1
57-60: OM2-6 through OM2-9 Data Type Change
Disposition
Proposals 57 through 60 were tabled until the RFR proposal is ready for CQ.
68: IV Bottle Type Proposal
Short Description:
Add a new field, IV Bottle Type, to the RXG segment.
Justification:
Continuation of a proposal originally submitted by HBOC to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Problem Statement
Rotating IV orders that are submitted using the parent /child paradigm can be multi-layered, for example, there can be one order message with multiple ingredient sets (children), known as bottles or bags; each with multiple give occurrences. The current give messages do not have a field identified to communicate the bottle or bag type that is to be given only the occurrence level or Give-Sub-Id Counter is sent. Systems need the ability to identify bottle types along with their give-sub-id associations.
Use Case
The following use case provides an example of the reason for this proposal:
A pharmacy enters a rotating IV order which contains 3 different bottle types.
However, with a large volume IV order where as part of the single instance of treatment, there are physical bottles with different compositions of base and additives, the level of uniqueness is commonly associated with the physical bottle number. Depending on the pharmacy system’s method of defining and processing IV orders, multiple placer order numbers or a single placer order number may be generated to accommodate different bottle types (unique composition of base and additives for the IV order). For example, if there are 16 physical bottles associated with an IV order and there are 2 bottle types, RXG-1-Give sub-ID counter would be incremented for each physical bottle in the whole order. This would yield Give sub-ID and Dispense sub-ID counters that may not start with 1 nor increment by 1 with each additional scheduled give date/time for a bottle.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on October 18, 2000. Six persons participated in the discussion: Gary Meyer (PIXIS); Daphne Young (HBOC); Austin Kreisler, (HBOC); Heather Von Allmen, (SMS); Frank Howard, (KP); and Joann Larson, (KP).
There was consensus that the rotating IV bottles concept needs to be clearly addressed. However, it is not clear which segment should carry the information. HBOC’s recommendation to add a new field to the RGV segment addresses the issue for those who need the information at the scheduling level. It may also need to be at a higher level i.e., at the ordering level. SMS has been using component 10 of the TQ data type in ORC-7 to convey similar information as a cyclical order. It is not clear if “fixing” TQ by developing the new TQ2 with this scenario in mind would obviate the need for a new field in the RGV segment. It would also be good to sort out if the recommended method for handling this type of order is as separate orders or as a parent/child order.
Action Item: Daphne Young to investigate how her "bottle type" use case (parent/child relationship) would be handled in the new TQ2 segment.
Action Item: Heather Von Allmen to supply a use case regarding rotating IV bottles, non-parent/child relationship, at the Order level.
Suggested Solution:
Add a new field, IV Bottle Type.
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 |11 |ST |O | | | |Barcode Identifier |
|26 |5 |IS |O | | | |IV Bottle Type |
IV Bottle Type
For pharmacy systems that support bottle type this field is used to pass the bottle type for this give instance. Each distinct set of ingredients in an IV order would receive its own bottle type identifier.
A repeating bag pattern within a given IV order is indicated by the RXG segment, identifying a specific bottle type, repeating as often as necessary to complete a single iteration of the administration array. If there is a rotating bottle type order with type ‘A’, ‘B’, and ‘C’ but the first bottle type to be administered is B, this field in the first give message would be populated with ‘B’.
RXG|1…….|B
RXG|2…….|C
RXG|3…….|A
Version 3.0 Requirements
The bottle type would need to be accounted for in the version 3 message instances of the Material Class for pharmacy IV messages. We would need to identify the components that comprise an IV bag and tie them to the bottle type identifier which will need to be expressed in pharmacy scheduling messages.
Disposition
Mark S. contents it is already covered. Could further clarify that filler “children” should be unique. Agreed to re-look at the issue. Tabled.
69: OM2 Attribute Table Change
Short Description:
Revise OM2 Attribute Table for consistency with narrative.
Justification:
Continuation of a proposal originally submitted by Japan to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on November 13, 2000. Seven persons participated in the discussion: Helen Stevens, (HBOC); Austin Kreisler, (HBOC); Gary Meyer, (PYXIS); Daphne Young, (HBOC); Frank Howard, (KP); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee supports this proposal which would allow OM2-6 and OM2-7 to repeat. The narrative for field 6 clearly states, and the examples show, that multiple ranges can be transmitted. The narrative for field 7 indicates that it should be formatted as OM2-6. Hence, it should also repeat.
Note: In the course of reviewing this proposal the subcommittee discovered that the narrative for field 7 and its component model are not consistent. A new data type needs to be defined both for it and OM2-6 which has a CM data type assigned but is missing its component model.
Action Item: Joann Larson to prepare a proposal for a new data type for Range with Associated Detail. This is in addition to the Numeric Range data type. Numeric Range would be a sub component of the new data type.
Suggested Solution:
Proposes to change:
HL7 Attribute Table – OM2
SEQ = 6 RP# =(No)
SEQ = 7 RP# =(No)
to
HL7 Attribute Table – OM2
SEQ = 6 RP# =Y
SEQ = 7 RP# =Y
Comments
The benefit to the multiple reference & critical range by the sexuality, age.
Disposition
There was no further discussion. The proposal was accepted: Favor: 12; Against: 0; Abstain: 1
70: OM2-7 Critical Range
Short Description:
Revise content for OM2-7 for consistency with OM2-6.
Justification:
Continuation of a proposal originally submitted by Japan to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on November 13, 2000. Seven persons participated in the discussion: Helen Stevens, (HBOC); Austin Kreisler, (HBOC); Gary Meyer, (PYXIS); Daphne Young, (HBOC); Frank Howard, (KP); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee supports this proposal that the OM2-7 Critical Range…should be formatted the same as the OM2-6 Normal Range. This is clearly stated in the narrative of OM2-7 “When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6-reference (normal) range-ordinal & continuous obs)”.
Note similar proposal: OM2-7 Data Type Change Proposal
Suggested Solution:
8.7.4.7 Proposes to change
Components:
Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18-nature of service/test/observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6-reference (normal) range-ordinal & continuous obs)
To
Components: ^ ^ ^ ^ ^ ^
Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18-nature of service/test/observation) with numeric results. When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6-reference (normal) range-ordinal & continuous obs)
Comments
It is changed to the same components as OM2-6.
Disposition
To be reviewed as potential duplicate of 58.
71: OM3 Attribute Table Change
Short Description:
Revise OM3 attribute table for consistency with narrative.
Justification:
Continuation of a proposal originally submitted by Japan to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on November 13, 2000. Seven persons participated in the discussion: Helen Stevens, (HBOC); Austin Kreisler, (HBOC); Gary Meyer, (PYXIS); Daphne Young, (HBOC); Frank Howard, (KP); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee supports this proposal which would allow OM3-5 Abnormal text… and to repeat. The narrative for field 5 states that field can contain a list as does the narrative for field 6.
Suggested Solution:
8.7.5 Proposes to change
HL7 Attribute Table – OM3
SEQ = 5 RP# =(No)
SEQ = 6 RP# =(No)
to
HL7 Attribute Table – OM3
SEQ = 5 RP# =Y
SEQ = 6 RP# =Y
Comments
It is necessary for the abnormal text & critical text that it can be repeated.
Disposition
No further discussion took place. The proposal was accepted: Favor: 9; Against: 0; Abstain: 3
72: OM4-6 Specimen Change
Short Description:
Revise OM4-6 definition for consistency with message structure.
Justification:
Continuation of a proposal originally submitted by Japan to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on November 13, 2000. Seven persons participated in the discussion: Helen Stevens, (HBOC); Austin Kreisler, (HBOC); Gary Meyer, (PYXIS); Daphne Young, (HBOC); Frank Howard, (KP); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee believes the author of this proposal has uncovered a significant inconsistency in the OM4 segment. Currently the narrative in OM4-6 indicates that the field can repeat, but this is not reflected in the Attribute table. This is a complex issue to straighten out because care must be taken regarding backwards compatibility, but the subcommittee believes that this proposal offers the best solution for the following reasons:
In version 2.3 new narrative was added at the beginning of the OM4 section explicitly stating that it is the segment that repeats if there are multiple specimens. The message structure has shown, even in version 2.2, that the OM4 can repeat. This strongly suggests this is the current intent.
The solution is consistent with version 3.
If the field were to repeat, there is no way to tie the other fields in the segment to the appropriate specimen.
Action Item: Joann Larson to bring this item to the attention of the Specimen Source subcommittee.
Suggested Solution:
Proposes to change
Definition: This field reports the specimen as one of the specimen codes described in ASTM Table 14 of 1238-91. If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), separate them with repeat delimiters.
to
Definition: This field reports the specimen as one of the specimen codes described in ASTM Table 14 of 1238-91. If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), multiple segments may be included, one for each specimen type.
Comments
It is corrected to use OM4 segment for every specimen because the description of 8.7.6.6 OM4-6 Specimen contradicts the description of 8.7.6 OM4.
Disposition
Need to consider this a technical correction and as part of specimen discussion ALL references to specimen type/kind/source/etc. need to be reviewed. This proposal was accepted: Favor: 10; Against: 0; Abstain: 1
73: Pharmacy Dispense Query Proposal
Short Description:
Add a general use pharmacy dispense query example to Chapter 5.
Justification:
Continuation of a proposal originally submitted by Kaiser Permenente to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Problem statement:
In version 2.4 a new style of Query /Response message pairs was developed. The pharmacy queries in chapter 4 were deprecated and the reader was referred to chapter 5. The OO TC has not yet developed new pharmacy queries using the new methodology.
Subcommittee Findings:
Discussed in 12/6/00 OO Teleconference. Attendees: Thanh-Le Nguyen (Kaiser), Joann Larson (Kaiser), Austin Kreisler (HBOC), Scott Robertson (Kaiser), Daphne Young (HBOC), Frank Howard (Kaiser), Susanne Nagami (Kaiser), Greg Thomas (Kaiser), Paul Gudmundsson (Kaiser)
Introduction by Joann. History of problem/name and the new style of Query with Conformance Statement. Query by Parameter (QBP) based upon RDS_O01. Responses can include multiple patients, so the response structure based upon RDS is repeatable. Description of columns in the Response structure table. Introduction of Input Parameter Specification.
Discussion on how additional query parameters (additional) fields can be added to the input specification. (Greg) The advantage/disadvantage of the Conformance Statement is that is very specific, analogous to a stored procedure. As such, additional input parameters would have to be defined in another (new) Query.
What about v3.0? Mark Tucker has been working on the query concept for v3.0.
The request is not to approve the concept of the query. The proposal is that this particular query is broadly applicable and would also serve as a good example of a pharmacy query in the context of the Conformance-based Query model.
Input Parameter Field Descripton: Description of PatientList is unclear “…combination of values for PatientListID and PatientAssigningAuthority . . . PatientListIdentifierTypeCode is useful for further filtering….” Action Item: Scott/Joann to clarify description of Input Parameter Field PatientList, if ID is populated then AssigningAuthority and IdentTypeCode are required. Consider including other components of CX. Generalizing narrative may be better, itemizing all CX components
Conclusion: With description changes, group agrees to proposal.
Suggested Solution:
The following query/response message pair with its Conformance Statement is an example used in the Query chapter. We are recommending that OO review it and after making any necessary modifications adopt it as a standard pharmacy query to be published in chapter 4.
NOTE: Since the new queries begin with a Conformance Statement and the query and response messages are embedded in that, the format looks different than other message syntaxes. It is not entirely settled as to how this should look in the technical chapters.
Pharmacy/Treatment Trigger Events & Messages
Pharmacy Query/Response message pair
Conformance Statement
|Query Statement ID (Query ID=Z81): |Z81 |
|Type: |Query |
|Query Name: |Dispense History |
|Query Trigger (= MSH-9): |QBP^Z81^QBP_Q11 |
|Query Mode: |Both |
|Response Trigger (= MSH-9): |RSP^Z82^RSP_Z82 |
|Query Characteristics: |May specify patient, medication, a date range, and how the response is to be sorted. |
|Purpose: |To retrieve patient pharmacy dispense history information from the Server. |
|Response Characteristics: |Sorted by Medication Dispensed unless otherwise specified in SortControl. |
|Based on Segment Pattern: |RDS_O01 |
|QBP^Z81^QBP_Q11 |Query Grammar: QBP Message |Section Reference |
|MSH |Message Header Segment |2.15.9 |
|QPD |Query Parameter Definition |5.4.3 |
|RCP |Response Control Parameter |5.4.6 |
|[ DSC ] |Continuation Pointer |2.15.4 |
|RSP^Z82^RSP_Z82 |Response Grammar: Pharmacy |Group |Comment |Support |Sec Ref |
| |Dispense Message |Control | |Indicator | |
|MSH |Message Header | | | |2.15.9 |
|MSA |Message Acknowledgement | | | |2.15.8 |
|[ERR] |Error | | | |2.15.5 |
|QAK |Query Acknowledgement | | | |5.4.2 |
|QPD |Query Parameter Definition | | | |5.4.3 |
|RCP |Response Control Parameter | | | |5.4.6 |
| | | | | | |
|{ | | |Query Result Cluster | | |
| [ | |PIDG |Begin PID Group | | |
| PID |Patient Identification | | | |3.3.2 |
| [PD1] |Additional Demographics | | | |3.3.9 |
| [{NTE}] |Notes and Comments (for PID) | | | |2.15.10 |
| [{AL1} |Allergy Information | | | |3.3.6 |
| [PV1 |Patient Visit | | | |3.3.3 |
| [PV2]] |Patient Visit – Additional Info | | | |3.3.4 |
| ] | | |End PID Group | | |
| { | |ORCG |Begin ORC Group | | |
| ORC |Common Order | |Each ORC/RXD | | |
| | | |combination | | |
| | | |constitutes a “hit.” | | |
| [ | |RXOG |Begin RXO Group | | |
| RXO |Pharmacy/Treatment Order | | | | |
| [{NTE}] |Notes and Comments (for RXO) | |We changed the syntax | |2.15.10 |
| | | |because we believe | | |
| | | |there is an error. The| | |
| | | |RXR should not be | | |
| | | |optional. | | |
| {RXR} |Pharmacy/Treatment Route | | | | |
| [ | |RXCG |Begin RXC Group | | |
| {RXC} |Pharmacy/Treatment Component | | | | |
| [{NTE}] |Notes and Comments (for RXC) | | | |2.15.10 |
| ] | | |End RXC Group | | |
| ] | | |End RXO Group | | |
| [ | |RXEG |Begin RXE Group | | |
| RXE |Pharmacy/Treatment Encoded Order | | | | |
| {RXR} |Pharmacy/Treatment Route | | | | |
| [{RXC}] |Pharmacy/Treatment Component | | | | |
| ] | | |End RXE Group | | |
| RXD |Pharmacy/Treatment Dispense |RXDG |Begin RXD Group | | |
| {RXR} |Pharmacy/Treatment Route | | | | |
| [{RXC}] |Pharmacy/Treatment Component | |End RXD Group | | |
| { | |OBXG |Begin OBX Group | | |
| [OBX] |Results | | | | |
| [{NTE}] |Notes and Comments (for OBX) | | | |2.15.10 |
| } | | |End OBX Group | | |
| } | | |End ORC Group | | |
|} | | |End Query Results | | |
|[ DSC ] |Continuation Pointer | | | |2.15.4 |
Input Parameter Specification
|Field Seq |Name |Key/ |Sor|LEN |TYPE |Opt |Rep |Match Op |TBL |Segment |Service |ElementName |
|(Query | |Search |t | | | | | | |Field Name |Identifier | |
|ID=Z81) | | | | | | | | | | |Code | |
|1 |MessageQueryNa| | |60 |CE |R | | | | | | |
| |me | | | | | | | | | | | |
|2 |QueryTag | | |32 |ST |R | | | | | | |
| |PatientList |S |Y |20 |CX |O | | | |PID.3 | |PID-3: Patient|
| | | | | | | | | | | | |Identifier |
| | | | | | | | | | | | |List |
| |MedicationDisp|S |Y |100 |CE |O | |= | |RXD.2 | |RXD-2: |
| |ensed | | | | | | | | | | |Dispense/Give |
| | | | | | | | | | | | |Code |
| |DispenseDate.L|S |Y |26 |TS |O | |> | |RXD.3 | |RXD-3: |
| |L | | | | | | |= | | | |Date/Time |
| | | | | | | | | | | | |Dispensed |
| |DispenseDate.U|S |Y |26 |TS |O | |< | |RXD.3 | |RXD-3: |
| |L | | | | | | |= | | | |Date/Time |
| | | | | | | | | | | | |Dispensed |
Input Parameter Field Description and Commentary
|Input Parameter |Comp. Name |DT |Description |
|(Query ID=Z81) | | | |
|MessageQueryName | |CE |Must be valued Z81^Dispense History^HL7nnnn. |
|QueryTag | |ST |Unique to each query message instance. |
|PatientList | |CX |The combination of values for PatientList.ID, and PatientList.AssigningAuthority, |
| | | |are intended to identify a unique entry on the PATIENT_MASTER table. The |
| | | |PatientList.IdentifierTypeCode is useful for further filtering or to supply |
| | | |uniqueness in the event that the assigning authority may have more than one coding |
| | | |system. (The PATIENT_MASTER table contains a constraint that prevents multiple |
| | | |patients from being identified by the same combination of field values.) This |
| | | |PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION |
| | | |table to retrieve the rows fulfilling the query conditions. |
| | | | |
| | | |If this field is not valued, all values for this field are considered to be a match.|
| | | | |
| | | |If one PID.3 is specified, only 1 segment pattern will be returned. |
| |ID |ID |If this field, PID.3.1, is not valued, all values for this field are considered to |
| | | |be a match. |
| |Assigning |HD |If this field, PID.3.4, is not valued, all values for this field are considered to |
| |Authority | |be a match. |
| |Identifier |IS |If this field, PID.3.5, is not valued, all values for this field are considered to |
| |type code | |be a match. |
|MedicationDispensed | |CE |If this field is not valued, all values for this field are considered to be a match.|
|DispenseDate.LL | |TS |This is the earliest value to be returned for Date/Time Dispensed. If this field is |
| | | |not valued, all values for this field are considered to be a match. |
|DispenseDate.UL | |TS |This is the latest value to be returned for Date/Time Dispensed. If this field is |
| | | |not valued, all values for this field are considered to be a match. |
Example
Example: The user wishes to know all the medications dispensed for the patient whose medical record number is “555444222111” for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.
MSH|^&~\|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Z81^QBP_Q11|ACK9901|P|2.4||||||||
QPD|Z81^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|
RCP|I|999^RD|
The pharmacy system identifies medical record number “555444222111” as belonging to Adam Everyman and locates 4 prescription dispenses for the period beginning 5/31/98 and ending 5/31/99and returns the following RSP message:
MSH|^&~\|PIMS|Gen hosp|PCR||199811201400-0800||RSP^Z82^RSP_Z82|8858|P|2.4||||||||
MSA|AA|ACK9901|
QAK|Q001|OK|Z81^Dispense History^HL7nnnn|4|
QPD|Z81^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|
PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||
ORC|RE||89968665||||||199805121345-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^BID^^19980529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm||||||||||||||||||||||||||
RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|||1331665|3|||||||||||||||||
RXR|PO||||
ORC|RE||89968665||||||199805291030-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^^D100^^20020731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19980821|||
RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR||||||||||||
RXR|PO||||
ORC|RE||235134037||||||199809221330-0700|||88^Semmelweis^Samuel^^^DR^MD||^^^^^510^ 2673900||||||
RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|199809221415-0700|10|||235134037|5|AS DIRECTED||||||||||||
RXR|PO||||
ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||
RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||
RXR|PO
Disposition
We agreed to start with a simple example and solicit more complicated, real live-based examples as we progress. The proposal was accepted: Favor: 13; Against: 0; Abstain: 1
74: Table 0080 Nature of Abnormal Testing - Additions
Short Description:
Add 3 items to HL7 Table 0080 - Nature of Abnormal Testing.
Justification:
Continuation of a proposal originally submitted by Bruce Wood to the October 2000 Working Group meeting in St. Louis. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
HL7 has been updated to accommodate animal/veterinary testing. I have experienced that some vet labs have used different set of normal ranges by race or breed of the animal in addition to age and sex. To accommodate Veterinary testing the PID record has added fields for Species (PID-35), Breed (PID-36) and Strain (PID-37). To accommodate the possibility of reference ranges being specified by these variables, these values should be added to the HL7 table 0080-Nature of abnormal testing:
Subcommittee Findings:
This proposal from Bruce Wood was reviewed in the OO teleconference on November 1, 2000. Three persons participated in the discussion: Heather Von Allmen, (SMS); Scott Robertson, (KP); and Joann Larson, (KP).
The subcommittee supports this proposal to add the requested items to table 0080 - Nature of Abnormal Testing
Suggested Solution:
7.4.2.10 Nature of Abnormal Test
HL7 Table 0080 Nature of abnormal testing
|Value |Description |
|A |An age-based population |
|N |None - generic normal range |
|R |A race-based population |
|S |A sex-based population |
|SP |Species |
|B |Breed |
|ST |Strain |
Add to definition in separate proposal:
The constraints on the use of the codes in this table must be consistent with those defined in the PID segment. Specifically Species PID:35, Breed PID:36 and Strain PID:37.
Disposition
Jim Case will provide with constraint definition between breed, species, and strain. The proposal was accetped: Favor: 9; Against: 0; Abstain: 1
75: Combine Tables 0286 and 0443
Short Description:
Combine Tables 0286 and 0443 and change table type to HL7.
Justification:
Continuation of a v2.4 ballot review issue. This proposal was requested by the Orders TC to resolve the issue. Kaiser Permanente submits this proposal in response to the issue and Orders TC request. The OO General Subcommittee has reviewed and supports the proposal as delineated in the Proposed Solution below.
Table 0443 – Provider role, as defined in section 12.4.3.3, seems to overlap with User-defined table 0286-Provider Role as used in PRD-1 as defined in section 11.6.3.1. This was pointed out in the KP response to the v 2.4 membership ballot. The resolution was to note the overlap in v 2.4 and to correct the problem in the next release.
Chapter 12, and we believe the PAFM TC, intend that this table be an HL7 table. Chapter 11 defines the table as user-defined.
Subcommittee Findings:
This proposal was reviewed in the OO teleconference on December 20, 2000. Five persons participated in the discussion: Austin Kreisler, (HBOC); Frank Howard, (KP); Roger Lee (KP); Scott Robertson, (KP); and Joann Larson, (KP).
• Background: table 0443 added in v2.4. During ballot review, noted that 0443 looked like table 0286. Suggestion to TC collapse 0443 into 0286, Orders TC responded that a proposal was needed. PAFM suggested that resulting table should be an HL7 Table. Changes may affect Chapters 3, 4, 11, and 12. Proposal brings together 0443 and 0286 as an HL7 Table.
• Outcome: Group concurs to endorse proposal and submit to Orders and PAFM in Orlando.
Solution:
11.6 SEGMENTS
11.6.3 PRD - provider data segment
11.6.3.1 PRD-1 Provider Role (CE) 01155
Components: ^ ^ ^ ^ ^
Definition: This field contains the contact role that defines the relationship of the person described in this segment to the patient being referred. When a referral is inter-enterprise in nature, there are several important relationships that must be identified. For example, the proper identification of both the referring and the referred-to provider is critical for proper processing of a referral. In addition, some enterprises may want information regarding a consulting provider or the identity of the person who actually prepared the referral. This contact role may also expand to represent affiliated persons to whom information regarding this referral must be forwarded or copied. Refer to HL7-defined User-defined Table 0286 - Provider role for suggested values.
User-defined Table 0286 - Provider role
|Value |Description |
|RP |Referring Provider |
|PP |Primary Care Provider |
|CP |Consulting Provider |
|RT |Referred to Provider |
HL7-defined Table 0286 - Provider role
|Value |Description |Used with |
|AD |Admitting |PV1-17 Admitting doctor |
|AT |Attending |PV1-7 Attending doctor |
|CP |Consulting Provider | |
|FHCP |Family Health Care Professional | |
|PP |Primary Care Provider | |
|RP |Referring Provider |PV1-8 Referring doctor |
|RT |Referred to Provider | |
12.4 MESSAGE SEGMENTS
8 ROL - role segment
1 ROL-3 Role-ROL (CE) 01197
Components: ^ ^ ^ ^ ^
Definition: This field indicates the functional involvement with the activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.). Refer to HL7 table 0443 0286– Provider role for valid values. When the ROL segment is used in conjunction with the Attending, Referring, or Admitting physician in the PV1 segment, the HL7 specified table values must be used. Additional site negotiated values are allowed.
Note: Table 0443 is intended to have the same use and values as Table 0286. The plan is to coordinate the numbering of these two tables across chapters in the next ballot cycle.
HL7 User-defined Table 0443 0286 - Provider role
|Value |Description |Used with |
|AD |Admitting |PV1-17 Admitting doctor |
|AT |Attending |PV1-7 Attending doctor |
|CP |Consulting Provider | |
|FHCP |Family Health Care Professional | |
|PP |Primary Care Provider | |
|RP |Referring Provider |PV1-8 Referring doctor |
|RT |Referred to Provider | |
*The positional location of the ROL segment in ADT and Finance messages indicates the relationship. When the segment is used following the IN3 segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the health plan. When the segment is used following the PID segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the person. When the segment is used following the PV2 segment, and the role-ROL value is PCP or FHCP, the PP or FHCP is related to the patient visit.
Disposition
There was no further discussion. The proposal was accepted: Favor: 7; Against: 0; Abstain: 4
78: Reformat OO Master Trigger Events
Short Description:
Reformat Service/Test/Observation Master Trigger Events at Heading 3 level.
Justification:
The Master File Notification (MFN) message syntax as defined in chapter 8, section 8.8.2, has 5 trigger events resulting in 5 different message syntaxes. These are hard to locate because they are not formatted at the 8.8.N level. They are simply presented as tables.
Subcommittee Findings:
This proposal is new and has not been reviewed by the OO general subcommittee.
Solution:
8.8.2 MFN/MFK - service/test/observation master file
The usage of the OMx segments in the Master Files MFN and MFR messages is described in Sections 0, “8.8.3 MFN/MFK - master files notification,” and Error! Reference source not found., “Error! Reference source not found.,” above. Basically the segment groupings described below follow the MFI and MFE segments in those messages (replacing the [Z...] section as follows:
Note: MFN^M03 is retained for backward compatibility only.
|MFN^M03^MFN_M03 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
|??? |[other segments(s)] | |
| } | | |
where other segments can be any of the following combinations:
8.8.3 MFN/MFK - master files notification (event M08)
MFI-1-master file identifier = OMA, for numeric observations (second component of MSH-9 - message type = M08).
[
[OM2] Numeric Observation Segment
[OM3] Categorical Service/Test/Observation Segment
[OM4] Observations that Require Specimens
]
|MFN^M08^MFN_M08 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM2] |Numeric Observation Segment |8 |
| [OM3] |Categorical Service/Test/Observation Segment |8 |
| [OM4] |Observations that Require Specimens |8 |
| } | | |
8.8.4 MFN/MFK - master files notification (event M09)
MFI-1 - master file identifier = OMB, for categorical observations (second component of MSH-9 - message type = M09).
[OM3 Categorical Service/Test/Observation Segment
[{OM4}] Observations that Require Specimens
]
|MFN^M09^MFN_M09 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM3 |Categorical Service/Test/Observation Segment |8 |
| [{OM4}] |Observations that Require Specimens |8 |
| ] | | |
| } | | |
8.8.5 MFN/MFK - master files notification (event M10)
MFI-1 - master file identifier = OMC, for observation batteries (second component of MSH-9 - message type = M10).
[OM5 Observation Batteries
[{OM4}] Observations that Require Specimens
]
|MFN^M10^MFN_M10 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM5 |Observation Batteries |8 |
| [{OM4}] |Observations that Require Specimens |8 |
| ] | | |
| } | | |
8.8.6 MFN/MFK - master files notification (event M11)
MFI-1 - master file identifier = OMD, calculated observations (second component of MSH-9 - message type = M11).
[OM6 Observations Calculated from Other Observations
OM2] Numeric Observation Segment
|MFN^M11^MFN_M11 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM6 |Observations Calculated from Other Observations |8 |
| OM2] |Numeric Observation Segment |8 |
| } | | |
8.8.7 MFN/MFK - master files notification (event M12)
MFI-1 - master file identifier = OME, Additional basic observation/service attributes (second component of MSH-9 - message type = M12).
[OM7] Other basic observation/service attributes
|MFN^M12^MFN_M12 |Master File Notification |Chapter |
|MSH |Message Header |2 |
|MFI |Master File Identification |8 |
| {MFE |Master File Entry |8 |
| OM1 |General Segment (Fields That Apply to Most Observations) |8 |
| [OM7] |Other Basic Observation/Service Attributes |8 |
| } | | |
Note: A service/test/observation definition may have both an OM2 (numeric) and OM3 (categorical) segment included in case the value may be either numeric and/or categorical.
Disposition
We agreed that this can be fixed. No issue. Deferred to CQ.
82: Hard-Stop Indicator Proposal
Short Descrption:
Add Hard-Stop Indicator field for use in Pharmacy messages.
Justification/Problem Statement
This is a resubmission of a proposal heard by the OO TC in St. Louis. It includes the response to the outstanding action item.
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. Currently we have no use cases for non-pharmacy use of the hard stop indicator. During the St. Louis conference, we were asked to review the use of this field in the new TQ segments rather than the pharmacy specific segments.
Proposed Solution
Add a new field to the RXO, RXC and RXE segments called Hard-Stop Indicator. Alternately, add the new field to the TQ-1. 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 |
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.
Alternate Solution
Add a new field to the TQ1- segment 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 - TQ1
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM# |ELEMENT NAME |
| |4 |SI |O |N | | |Set ID - TQ1 |
| | |NM |B |N | | |Quantity |
| | |CE |C |N | | |Quantity units |
| | |IS |O |Y | | |Repeat Pattern |
| | |TM |O |Y | | |Explicit Time |
| | |CQ? |??? |??? | | |Relative Time and units |
| | | | | | | |Days of week |
| | |NM | | | | |Days on |
| | |NM | | | | |Days off |
| | |TX | | | | |Frequency text |
| | | | | | | |Reset indicator |
| | |NM |O |N | | |Duration |
| | |CE |C |N | | |Duration units |
| | | | | | | |Duration variance |
| | |TS |O |N | | |Start date/time |
| | |TS |O |N | | |End date/time |
| | |CWE |R |Y | | |Priority |
| | |NM |O |Y | | |Priority integer of criticality (NM) (restored) |
| | |ID |O |Y | | |Priority unit of criticality (ID) (restored) |
| |250 |ST |O |N | | |Condition text |
| |250 |TX |O |N | | |Text instruction |
| | |ID |C |N | | |Conjunction |
| | |CE |O |N | | |Occurrence duration |
| | | | | | | |Occurrence duration numeric |
| | | | | | | |Occurrence duration units |
| | |NM |O |N | | |Total occurrence's |
| | |ID |O |N | | |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.
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.
Disposition
Mark Shafarman is uncomfortable that the use case is not specific enough and the lack of a mandatory response when an order was actually extended. Additionally, it must be recognized that a soft stop with auto extend may not be allowed in every state/country. Follow-up by Daphne Young to refine definitions to address the concerns and further refine when to use what message and by what time an order actually stops.
84: Pharmacy Order Type Proposal
Problem Statement
Pharmacy order entry and processing are generally separated into three broad categories; Medication, Piggyback / Solutions as Medications and Large Volume IV Orders. These three categories may determine the processing that sending and receiving systems will perform. Pharmacy orders have broad functional differences based on the order types described herein. Packaging, dispensing, retrieving, ordering, administering and charging can be vastly different between these order types. There currently are no triggers, segments or fields defined in HL7 to identify these basic categories that most systems, whether sending or receiving, require to appropriately process pharmacy orders. This proposal was submitted and discussed in St. Louis during the Fall 2000 Conference. It was approved pending the move of the new field from the originally proposed ORC to the individual pharmacy segments. This proposal is an amendment to the original with the requested changes.
Proposed Solution
Add a field in RXO, RXE, RXG, RXA, RXD segments that identifies the type of Pharmacy Order being processed. This field is required for all pharmacy messages including RDE, ORM, RGV, RDS and RAS transactions.
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 | |0161 |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 |
| |1 |ID |R | | | |Pharmacy Order Type |
| | | | | | | | |
Pharmacy Order Type (ID)
Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. The three categories are Medication, Solution as Medication and Large Volume IV. Generally Medications include tablets, capsules, powders, puffs as examples. Solutions as Medications include the more granular categories of piggybacks and syringes. The Large Volume IVs can extend to TPNs, admixtures, solutions and drips depending on system functionality.
Useage Rule: This field is required for all Pharmacy transactions.
Valid values in this field are:
|Value |Description |
|M |Medication |
|S |IV Large Volume Solutions |
|O |Other solution as medication orders which includes piggybacks, and syringes. |
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 | |0167 |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 | |0321 |01222 |Dispense Package Method |
|31 |60 |CE |O |Y | |01476 |Supplementary Code |
| |1 |ID |R | | | |Pharmacy Order Type |
| | | | | | | | |
Pharmacy Order Type (ID)
Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. The three categories are Medication, Solution as Medication and Large Volume IV. Generally Medications include tablets, capsules, powders, puffs as examples. Solutions as Medications include the more granular categories of piggybacks and syringes. The Large Volume IVs can extend to TPNs, admixtures, solutions and drips depending on system functionality.
Useage Rule: This field is required for all Pharmacy transactions.
Valid values in this field are:
|Value |Description |
|M |Medication |
|S |IV Large Volume Solutions |
|O |Other solution as medication orders which includes piggybacks, and syringes. |
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 |
| |1 |ID |R | | | |Pharmacy Order Type |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
Pharmacy Order Type (ID)
Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. The three categories are Medication, Solution as Medication and Large Volume IV. Generally Medications include tablets, capsules, powders, puffs as examples. Solutions as Medications include the more granular categories of piggybacks and syringes. The Large Volume IVs can extend to TPNs, admixtures, solutions and drips depending on system functionality.
Useage Rule: This field is required for all Pharmacy transactions.
Valid values in this field are:
|Value |Description |
|M |Medication |
|S |IV Large Volume Solutions |
|O |Other solution as medication orders which includes piggybacks, and syringes. |
HL7 Attribute Table - RXD
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |4 |NM |R | | |00334 |Dispense Sub-ID Counter |
|2 |100 |CE |R | |0292 |00335 |Dispense/Give Code |
|3 |26 |TS |R | | |00336 |Date/Time Dispensed |
|4 |20 |NM |R | | |00337 |Actual Dispense Amount |
|5 |60 |CE |C | | |00338 |Actual Dispense Units |
|6 |60 |CE |O | | |00339 |Actual Dosage Form |
|7 |20 |ST |R | | |00325 |Prescription Number |
|8 |20 |NM |C | | |00326 |Number of Refills Remaining |
|9 |200 |ST |O |Y | |00340 |Dispense Notes |
|10 |200 |XCN |O |Y | |00341 |Dispensing Provider |
|11 |1 |ID |O | | |00322 |Substitution Status |
|12 |10 |CQ |O | | |00329 |Total Daily Dose |
|13 |200 |CM |C | | |01303 |Dispense-to Location |
|14 |1 |ID |O | |0136 |00307 |Needs Human Review |
|15 |200 |CE |O |Y | |00330 |Pharmacy/Treatment Supplier’s Special Dispensing |
| | | | | | | |Instructions |
|16 |20 |NM |O | | |01132 |Actual Strength |
|17 |60 |CE |O | | |01133 |Actual Strength Unit |
|18 |20 |ST |O |Y | |01129 |Substance Lot Number |
|19 |26 |TS |O |Y | |01130 |Substance Expiration Date |
|20 |60 |CE |O |Y | |01131 |Substance Manufacturer Name |
|21 |200 |CE |O |Y | |01123 |Indication |
|22 |20 |NM |O | | |01220 |Dispense Package Size |
|23 |60 |CE |O | | |01221 |Dispense Package Size Unit |
|24 |2 |ID |O | | |01222 |Dispense Package Method |
|25 |60 |CE |O |Y | |01476 |Supplementary Code |
|26 |180 |HD |O | | |01477 |Initiating Location |
|27 |180 |HD |O | | |01478 |Packaging/Assembly Location |
| | | | | | | |Pharmacy Order Type |
| | | | | | | | |
Pharmacy Order Type (ID)
Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. The three categories are Medication, Solution as Medication and Large Volume IV. Generally Medications include tablets, capsules, powders, puffs as examples. Solutions as Medications include the more granular categories of piggybacks and syringes. The Large Volume IVs can extend to TPNs, admixtures, solutions and drips depending on system functionality.
Useage Rule: This field is required for all Pharmacy transactions.
Valid values in this field are:
|Value |Description |
|M |Medication |
|S |IV Large Volume Solutions |
|O |Other solution as medication orders which includes piggybacks, and syringes. |
Figure 4-19. RXA attributes
|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 | | |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 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 |
|22 |26 |TS |O | | |01225 |System Entry Date/Time |
| |1 |ID |R | | | |Pharmacy Order Type |
Pharmacy Order Type (ID)
Definition: The Pharmacy Order Type field defines the general category of pharmacy order which may be used to determine the processing path the order will take. The three categories are Medication, Solution as Medication and Large Volume IV. Generally Medications include tablets, capsules, powders, puffs as examples. Solutions as Medications include the more granular categories of piggybacks and syringes. The Large Volume IVs can extend to TPNs, admixtures, solutions and drips depending on system functionality.
Useage Rule: This field is required for all Pharmacy transactions.
Valid values in this field are:
|Value |Description |
|M |Medication |
|S |IV Large Volume Solutions |
|O |Other solution as medication orders which includes piggybacks, and syringes. |
Version 3.0 Requirements
We need a way to identify the type of medication orders being processed in 3.0 as we do in 2x versions of HL7. Perhaps the METHOD CODE in Medications can be used to describe the method for processing the drugs, however, this may warrant its own attribute in Medications, since all pharmacy orders require this description.
Disposition
There was no further discussion. The proposal was accepted: Favor: 15; Against: 0; Abstain: 1
General
Action Item: Helen Stevens will follow-up on Chapter 4/7 discrepancies to synchronize. A solution proposed is to work with hyper-links to link Chapter 7 back to the source and then expand with Chapter 7 specific explanation/definition.
PM Pre-Cookies – Blood Bank
The second quarter focused on a review of Blood Bank SIG initiatives to provide guidance and feedback on the work done to date. The Blood Bank SIG has performed significant work to identify missing areas within V2.x and has started to identify potential solutions through V2.x proposals during the May/September 2001 meetings. The following are specific topics of note raised during the discussion.
❑ ISBT 128 is already listed in V2.4.
❑ Blood Bank SIG should be part of Specimen Source discussions between and during working meetings. LAPOCT should be part of the same discussions.
❑ We suggested to create a separate segment for Blood Product (copy fields from OBR and RX.... as necessary) and to create a separate message structure as needed. Use OML structures as example for message structure.
❑ The Pharmacy segments provide good examples for TQ. We suggested to use the TQ segments being developed instead of TQ data type. Blood Bank should follow that discussion.
❑ We suggested to use OBXs for clinically relevant data rather then the OBR field.
❑ When creating separate product messages, draw from OBX/RXA, but avoid using non-specific names. Consider using the Product Action Code for the identification of what the state change was/supposed to be.
❑ For queries, consider the Product Action Code values for instance vs. cumulative content.
❑ Consider combining Commercial Product and Blood Product segments. Fields that can only be used based on message or type of product can be identified through conditional statements.
❑ Consider creating a small repeating segment around lot number if not too many field values need to change based on a different lot origination.
❑ Need to look at IAM and OBX for additional patient information.
Daphne Young will coordinate with Patti Larson to drive proposal definition for V2.x messages/segments. Initial proposal review is targeted for the May meeting.
Tuesday, January 9, 2001
Co-Chair Election
Tuesday morning was kicked off with election of two co-chairs as the term for Clem McDonald and Hans Buitendijk expired. Hans Buitendijk, Clem McDonald, and Ken McCaslin ran for the two open positions. After the votes were counted once, Hans Buitendijk and Clem McDonald got the most votes and accepted the position for the next two years. Ken McCaslin offered and will provide facilitation with the Micro group and Blood Bank SIG to guide them through V2.x and V3.0 efforts.
Blood Bank
We reviewed with the Blood Bank SIG an initial interaction diagram:
Blood Bank SIG will create a similar diagram for complex scenarios involving separate lab and donor centers.
Scope Statements
We reviewed the scope statements related to Version 3.0. Updates were made to reflect the potential for a clinical trials SIG and correcting the omission of Dietary messages. The following are the scope statements:
❑ Phase One
Project Initiation Date: 1/1/2001
Project Name: 3.0 Phase One
Project Description:
Development of limited number of foundation orders / observations messages. These will encompass:
❑ Lab Order (Provider to Laboratory)
❑ Lab Intent (Laboratory to Provider)
❑ Observation
❑ Medication Order Request (Provider to Pharmacy)
❑ Medication Intent - Structured (Pharmacy to Provider)
❑ Medication Dispense Request
❑ Medication Dispense Notification
❑ Medication Administration
Additionally we will address simple state changes such as hold, resume, cancel, discontinue, as well as initiating message definitions dealing with content changes and master file updates. Lastly, we will define initial CMETs as they arise through the definition process.
Project Objective(s):
Non-normative: CMETs for Order, Observation ?
Normative: initial HMDs for Laboratory orders, observations, and medication orders and administration .
Target Delivery Date(s): Fall Meeting 2001
Project Dependencies: PAFM CMET for Patient, Location, Provider
❑ Phase Two
Project Initiation Date: 6/1/2001
Project Name: 3.0 Phase Two
Project Description:
The second phase for V3 messages will encompass the following activities:
❑ Completion of content change messages for Laboratory and Pharmacy
❑ Completion of messages not covered in phase one necessary to complete the typical use cases for Laboratory and Pharmacy
❑ Completion of Master File Update messages around Laboratory and Pharmacy.
❑ Integration of Blood Bank and Lab Automation concepts into the Lab messages.
❑ Integration of Clinical Documentation Architecture
Project Objective(s):
Non-normative: CMETs for Order, Observation ?
Normative: complete HMDs for Laboratory orders, observations, and medication orders and administration, .
Target Delivery Date(s): Winter Meeting 2001
Project Dependencies: Completion of Phase One
❑ Phase Three
Project Initiation Date: 1/1/2002
Project Name: 3.0 Phase Three
Project Description:
The third phase for V3 messages will encompass the following activities:
❑ Integration of Images into Observation messages
❑ Creation of General Order messages
❑ Creation of Dietary messages
❑ Creation of Supply messages
❑ Creation of Referral messages
Project Objective(s):
Non-normative: CMETs for Order, Observation ?
Normative: HMDs for General Order, Supply, Dietary, and Referrals.
Target Delivery Date(s): Fall Meeting 2002
Project Dependencies: Completion of Phase Two
❑ Phase Four
Project Initiation Date: 6/1/2002
Project Name: 3.0 Phase Four
Project Description:
The fourth phase for V3 messages will encompass the following activities:
❑ Definition of Clinical Trials messages (pending other committee's progress)
❑ Creation of Product Experience messages
❑ Clean-up of all initial V3 messages based on experience to date
Project Objective(s):
Non-normative: CMETs for Order, Observation ?
Normative: HMDs for Product Experience and any cleanup
Target Delivery Date(s): Winter Meeting 2003
Project Dependencies: Completion of Phase Three
A motion was accepted to accept the scope statements and move them to the ARB for further review/finalization. It is understood that the scope statements may require adjustments as we monitor actual progress. This proposal was accepted: Favor: 13, Against: 0, Abstain: 2.
RIM Harmonization Update
Gunther Schadow reviewed the RIM changes since our last meeting:
❑ Most changes that occurred were significant for PAFM.
❑ Plants are type of non_person_living_subject.
❑ Scheduling has been “removed” and made part of act. Enables more easily scheduling encounters and orders.
❑ Introduction of the message_interaction class will require further consideration when developing status change messages, e.g., cancel order. Similar to the EVN concept in V2.x.
❑ Act_context introduced to build complex structures. Presentation aspects of the relationship, whereas the act_relationship reflects the semantic relationships.
❑ Change of body_site_cd to anatomical_site_cd did not make it. Will be resubmitted.
❑ Various attributes moved from Act to different specializations to avoid inheritance into administrative specializations, e.g., anatomical site is not relevant for patient encounter.
We agreed to stick with name change (body site to anatomical site) and wait for vocabulary progress before suggesting any other name changes specific to the specializations. Favor: 12, Against: 0, Abstain: 0.
Edgar Glück, Norway, presents European message development of which we could use R-MIMs and other material. The presentation is available on the list server.
Joint CDA/MDM/Integration/O&O
The joint session was kicked off with an explanation by Wayne of MDM purpose. We agreed that specific OO and MDM discussion will take place to resolved specific use of MDM vs. ORU. MDM must have specific required fields to avoid confusion.
We continued with review of specific CDA issues related to the RIM that required OO input.
❑ Document Transformation.
Need code of transformation in act_relationship:type_cd. Favor 25, Against 0, Abstain 13.
❑ Region of interest
Need ability to reference a region of interest on an image from a document. Region of interest as a specialization of Act.
Need for O&O to resolve with II the location of images in the RIM.
Need to keep II, CDA, and O&O in sync as it is not only from documents that one wants to reference region of interest.
❑ Language Code
As part of restructuring Document RIM section it appeared that there was no place for the language code to describe the language code after removing Caption. Language code in Text datatype does not cover all aspects of language. Proposal to add to act_context. Favor 20, Against 0, Abstain 16
Wednesday, January 10, 2001
Joint II/O&O
The objective of the joint session was to review a specific V2.x proposal and to review the current thoughts II has around V3.0.
V2.x discussion
Image Integration SIG proposes addition of an IIS segment to the OMG message.
Imaging Information Segment (IIS) Definition
|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 |
| [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 |
| } | | |
| } | | |
| }] | | |
| [{IIS}] |Imaging Information Segment |4 |
| [{FT1}] |Financial Transaction |6 |
| [{CTI}] |Clinical Trial Identification |7 |
| [BLG] |Billing Segment |4 |
| } | | |
IIS - Imaging Information Segment
The IIS segment contains information about tasks that need to be performed in order to fulfill the request for imaging service. The information includes location, type and instance identification of equipment (acquisition modality) and stages (procedure steps). This information is used in communication between the information systems involved in the fulfillment of the request, such as Radiology Information System (RIS) and Picture Archiving and Communication System (PACS). For the purpose of the following discussion these systems will be identified as Imaging Department Information Systems (IDIS). Information contained in the IIS segment allows multiple IDIS to share the context of Imaging Studies (collections of images acquired, processed, stored, and interpreted) in Image Management tasks.
The order for the imaging service is communicated between the order placer and the Order Filler. The Order Filler may break the order down into one or more internal imaging service requests, each identified by a different accession number. In the imaging department environment, the Order Filler also identifies the set of procedures (studies) and sub-procedures (procedure steps) that have to be performed in the process fulfilling the order. Each sub-procedure is performed using a single device (station). The Order Filler identifies the type of device and either a specific device or group of devices (for example, by geographic location) one of which is to be used in performing the procedure step. Thus, the system performs an aspect of workflow management in the department.
Another information system in the department may be managing storage and distribution of the images within the department as well as providing them to the enterprise. This system will have to share context with the system managing the workflow. This includes identifiers, content of the order, and details of procedures and procedure steps that have to be performed to fulfill that particular order.
It is expected that the IIS segment will typically be used in communication between IDIS as depicted in the figure below.
[pic]
The IDIS performing the workflow management for the department can handle single orders each containing multiple Imaging Service requests by assigning each of the requests a separate accession numbers. For example, IDIS may receive an order for the X-ray examination of the patient daily at 8 am for the next three days. As Order Filler, the IDIS would associate the order with a single Filler Order Number. However, for the purposes of fulfilling the order, it will handle each of the daily exams as a separate Imaging Service Requests each with a unique accession number.
Each of the Imaging Service Requests may contain one or more Requested Procedures that it will identify with the Requested Procedure ID. The Requested Procedure is the most granular unit of work that leads to the creation of the procedure report. Each procedure report contributes into the results for the order. To support communication with the instances of equipment in a department (acquisition modalities), IDIS also generates the Study Instance UID, a globally unique identifier for each Requested Procedure. Unlike the Study Instance UID, the Requested Procedure ID must only be unique within the scope of the encompassing Imaging Request.
Each of the Requested Procedures may be further broken down by the IDIS into the Scheduled Procedure Steps based on the timing and equipment requirements and identified with the Scheduled Procedure Step ID. Single Procedure Step may only be performed on a single type and instance of the equipment. Thus, while the Requested Procedure may identify multi-modality examination (such as ones common in Nuclear Medicine), single Procedure Step has to correspond to the operations performed on a single modality.
An example of the hierarchy of Accession Number, Requested Procedure ID, Study Instance UID and Scheduled Procedure Step is depicted in the figure below:
[pic]
The context will be shared between all IDIS within a department in a course of fulfilling an order.
HL7 Attribute Table – IIS – Imaging Information Segment
|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |
|1 |22 |EI |R | | | |Accession Number |
|2 |22 |EI |R | | | |Requested Procedure ID |
|3 |64 |HD |R | | | |Study Instance UID |
|4 |22 |EI |R | | | |Scheduled Procedure Step ID |
|5 |16 |CE |O | | | |Modality |
|6 |261 |CE |O |Y | | |Protocol Code |
|7 |261 |IS |O | | | |Scheduled Station Name |
|8 |261 |IS |O |Y | | |Scheduled Procedure Step Location |
IIS-1 Accession Number (EI)
Components: ^ ^ ^
Definition: A RIS generated number that identifies the order for the Imaging Study. Reference DICOM Attribute (0008,0050).
IIS-2 Requested Procedure ID (EI)
Components: ^ ^ ^
Definition: Identifier which identifies the Requested Procedure in the Imaging Service Request. Reference DICOM Attribute (0040,1001)
IIS-3 Study Instance UID (HD)
Components: ^ ^
Definition: Unique identifier for the Study. Reference DICOM Attribute (0020,000D)
IIS-4 Scheduled Procedure Step ID (EI)
Components: ^ ^ ^
Definition: Identifier which identifies a particular sub-procedure (Scheduled Procedure Step) within a requested procedure. The DICOM Value Representation (VR) for Scheduled Procedure Step ID is Short String (SH). Only the first component of is used to populate the HL7 EI data type. Reference DICOM Attribute (0040,0007).
IIS-5 Modality (CE)
Definition: Type of equipment used to create the images for this Study. Table below for Defined Terms. Reference DICOM Attribute (0008,0060).
Populate with entries from the table from Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions, section C.7.3.1.1.1. (This table is included at the end of this submission for reference purposes.)
IIS-6 Protocol Code (CE)
Components: ^ ^ ^ ^ ^
Definition: One or more coded entries identifying the protocol according to which the Scheduled Procedure Step shall to be performed. Protocol Code(s) may identify particular equipment settings as well as operator’s manipulations. Reference DICOM Attribute (0040,0008).
IIS-7 Scheduled Station Name (IS)
Definition: This field contains the ID number and name of the modality resource being requested for performance of particular Scheduled Procedure Step. If the Scheduled Procedure Step is to be preformed by an unspecified member of a pool of resources, this element is empty and IIS-8, Scheduled Procedure Step Location us used to identify the customer-defined resource pool specified. Reference DICOM Attribute (0040,0010).
IIS-8 Scheduled Procedure Step Location (IS)
Definition: This field is used to specify a customer defined resource pool from which the modality resource is chosen. Reference DICOM Attribute (0040,0011).
Reference: DICOM Modality List
|Value |Description |
|AU |Audio |
|BI |Biomagnetic Imaging |
|CD |Color Flow Doppler |
|CR |Computed Radiography |
|CT |Computed Tomography |
|DD |Duplex Doppler |
|DG |Diaphanography |
|DX |Digital X-Ray |
|ECG |Electrocardiography |
|ES |Endoscopy |
|GM |General Microscopy |
|HC |Hard Copy |
|HD |Hemodynamic Waveform |
|IO |Intra-oral Radiography |
|LS |Laser Surface Scan |
|MA |Magnetic Resonance Angiography |
|MG |Mammography |
|MR |Magnetic Resonance |
|MS |Magnetic Resonance Spectroscopy |
|NM |Nuclear Medicine |
|PR |Presentation State |
|PT |Positron Emission Tomography (PET) |
|PX |Panoramic X-Ray |
|RF |Radio Fluoroscopy |
|RG |Radiographic Imaging (conventional film/screen) |
|RTDOSE |Radiotherapy Dose |
|RTIMAGE |Radiotherapy Image |
|RTPLAN |Radiotherapy Plan |
|RTRECORD |RT Treatment Record |
|RTSTRUCT |Radiotherapy Structure Set |
|SM |Slide Microscopy |
|SR |SR Document |
|ST |Single-Photon Emission Computed Tomography (SPECT |
|TG |Thermography |
|US |Ultrasound |
|XA |X-Ray Angiography |
|XC |External-camera Photography |
|OT |Other |
Above table is from Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions, section C.7.3.1.1.1. Copyright 2000 by the National Electrical Manufacturers Association
Disposition
We agreed to take a straw vote and to insert the IIS proposal into the V2.x proposal review process. Straw vote 12 Favor, 0 Against, 9 Abstain. The proposal will be on the May V2.x agenda for formal committee vote for inclusion in V2.x.
V3 discussion
Fred Behlen provided a brief overview of the DICOM “hierarchy” involving Study, Series, Images. DICOM publishes yearly. The modality equipment list is desired to be referenced to DICOM Modality List (C.7.3.1.1.1). Question to be resolved is how to point to them.
There is a desire for a modality sub-class under Device. Draft attributes have been identified. Additionally there is a desire for an image sub-class under Observation. The objective is to model the set of attributes necessary to communicate the image information object as part of an HL7 message. It is not yet clear what the resulting overlap is between data within the DICOM information object and the rest of the HL7 message. Questions were raised whether it is possible/appropriate/feasible to eliminate all overlap.
Use cases and trigger events still require definition. The objective is to use HL7 messages for communication outside the Radiology environment (inter-departmental), while DICOM messages are used within Radiology (intra-departmental).
The question was posed to the participants whether it is the sense that the basic direction of adding image support in the RIM, specifically Device and Observation specialisation plus potential attributes to other classes to be determined, is the right approach. Favor 17, Against 0, Abstain 6.
Lab Messages Continuation
We started with a review of the state transition diagram and identified the subset appropriate for Lab.
[pic]
❑ A concern was raised with the use of the word “abort”. We agreed that this term is commonly used in the industry for this purpose and agreed not to change it.
❑ Suspended under Observation is the suspension of the information flow steps. Need to clarify the notion.
❑ We need to consider splitting Active into Test and Delivery.
❑ We need to clarify language for Active in the context of Observation that some tests can be suspended, or “delivery” can be suspended.
❑ We need to consider adding a preliminary status somehow.
❑ How do we distinguish between correction vs. amendment? Revisions?
❑ The Abort transition is not applicable to all lab order situations.
We continued with a review of a lab interaction diagram and arrived at the following:
We agreed that LAPOCT is going to focus on the interactions around Lab and Analyzer. We probably can use the diagrams already in place with some level of summarization.
The following represents a block diagram of the R-MIM for a general order message with micro capabilities.
The observation block diagram appears as follows on the next page:
Joint LAPOCT
Authoritative Statement
Charlie Hawker and Andrzej Knafel presented a need for an authorization letter to address an NCCLS need for two trigger events for 2.3.1 and 2.4. This is considered an urgent request because NCCLS intends to fast track the overall standards process.The following is the proposal:
In order to utilize the HL7 standard for the EDI part of point of care testing, the LAPOCT SIG, working with the Connectivity Industry Consortium (CIC), has determined that two additional message trigger events should be added to Chapter 7. These trigger events are:
ORU – unsolicited observation message (event Rxx)
This is for laboratory results reported by a testing device to the LIS for which there is no existing order in the LIS.
ORU – unsolicited observation message (event Ryy)
This is for laboratory results reported by a testing device to the LIS for which there is an existing order in the LIS.
It is proposed that Orders and Observations approve this request for these two trigger events and submit a proposal for an Authoritative Statement for approval by the Technical Steering Committee and the Board of Directors at their regularly scheduled meetings in May 2001. Issuance of this Authoritative Statement will permit the CIC and NCCLS to publish implementation guides for HL7 versions 2.3.1 and 2.4, which will enable Point of Care Testing vendors and users to effectively utilize the HL7 standard, without waiting for these new message trigger events to be published in HL7, version 2.x. NCCLS will not publish any portion of the actual HL7 standard in their POCT standard, only these guides on how to implement HL7. This emergency request was made because of the intent of CIC and NCCLS to publish the approved POCT standard in six months (July, 2001), well before these proposed trigger events could be balloted and added to the HL7 standard.
After discussion to clarify the purpose, we agreed that further review was required. However, we did take a straw vote to get an initial impression of how the committee is leaning: Preliminary acceptance of direction - 13 in Favor, 0 Against, and 5 Abstain.
We agreed to the following follow-up with 14 in Favor, 0 Against, and 4 Abstain:
❑ CIC makes wording proposal: Jeff Perry and Andrzej Knafel and Nils Graversen
❑ CIC organizes call: Jeff Perry
Before 29 January initial phone conversation with minimum participation
One or more Co-chairs O&O
One or more Co-chairs LAPOCT
One or more from CIC
Any other interested party
❑ Final language for final review at Monday May Meeting
❑ Final TSC blessing plus HL7 Board
V3.0
LAPOCT identified various questions regarding SAC’s container and specimen information.
Observation/Attribute
During harmonization various issues were raised whether certain characteristics of container and specimen should be treated as attributes or observations. LAPOCT proposes to use the following guidelines:
❑ Characteristics of container should be attribute
❑ Characteristics of specimen should be observation, unless elsewhere specified.
The proposal was accepted: Favor: 14, Against: 0, Abstain: 6.
Specimen Attributes
❑ Additives were coded element. LAPOCT suggests to make additive a material and use relationship with specimen to identify additives part of the specimen.
Question: Are additives associated with container rather then specimen? After discussion we agreed to the following relationships:
1. Container contains Specimen
2. Specimen has Additive
3. Container contains Additive
Prior to the specimen being present in the container then relationship one and three applies. After specimen is in the container, then relationship one and two applies. The proposal was accepted: Favor: 15, Against: 0, Abstain: 6.
❑ Vocabulary submission needed for material.handling_cd with Table 0376. Charlie Hawker volunteers to merge Table 0376 V2.4 and Table 36 USAM. The following table was provided by Charlie:
Proposed Replacement Table
|Concept |Implies |Code |If 0376 |Definition |
| | | |appr. | |
|Body temperature | |C37 |* |Critical to keep specimen at body temperature: 36 - |
| | | | |38( C. |
|Ambient temperature | |AMB | |Keep specimen at ambient (room) temperature, |
| | | | |approximately 22 ( 2 °C. Accidental refrigeration or |
| | | | |freezing is of little consequence. |
|Critical ambient temperature | |CAMB |* |Critical ambient – specimen must not be refrigerated |
| | | | |or frozen. |
|Refrigerated temperature | |REF | |Keep specimen at refrigerated temperature: 4-8( C. |
| | | | |Accidental warming or freezing is of little |
| | | | |consequence. |
|Critical refrigerated temperature | |CREF |* |Critical refrigerated – specimen must not be allowed |
| | | | |to freeze or warm until immediately prior to |
| | | | |testing. |
|Frozen temperature | |FRZ | |Keep specimen at frozen temperature: -4( C. Accidental|
| | | | |thawing is of little consequence. |
|Critical frozen temperature | |CFRZ |* |Critical frozen – specimen must not be allowed to thaw|
| | | | |until immediately prior to testing. |
|Deep frozen | |DFRZ | |Deep frozen: -16 to -20( C. |
|Ultra frozen | |UFRZ | |Ultra cold frozen: ~ -75 to -85( C. (ultra cold |
| | | | |freezer is typically at temperature of dry ice). |
|Liquid nitrogen | |NTR | |Keep specimen in liquid nitrogen. |
|Protect from light | |PRTL |* |Protect specimen from light (e.g., wrap in aluminum |
| | | | |foil). |
|Protect from air | |CATM |* |Critical. Do not expose specimen to atmosphere. Do not|
| | | | |uncap. |
|Dry | |DRY | |Keep specimen in a dry environment. |
|No shock | |PSO | |Protect specimen from shock. |
|Do not shake | |PSA | |Do not shake specimen. |
|Upright | |UPR | |Keep specimen upright. Do not turn upside down. |
❑ LAPOCT is not sure what to do with specimen component (Table 0372). Some values are materials (whole blood, platelet rich plasma, etc.), others not (supernatant, sediment).
❑ Suggestion to add supernatant, extract, sediment, precipitate, distillate as new vocabulary to material.form_cd.
❑ Need language to indicate how the Act can be used to indicate how the specimen was “created”, e.g., centrifuged.
❑ Suggestion to integrate whole blood through plasma (six values) into the material.type_cd vocabulary using Blood Bank terminology as the base.
Suzanne will forward BB list to Jim. The proposal was accepted: Favor: 12, Against: 0, Abstain: 5.
❑ Previous harmonization meeting proposal for new attributes was rejected.
1. Material.initial_qty > observation
2. Material.current_qty > observation
3. Material.available_qty > observation
4. Material.consumption_qty > observation
The proposal to treat these four attributes as observations was accepted: Favor: 14, Against: 0, Abstain: 3
1. Material.first_used_dttm > incorporate into stability_time attribute of Re-Agent sub-class of Manufactured_Material
2. Material.on_board_stability_duration_time > incorporate into stability_time of Re-Agent Manufactured_Material.
The proposal to treat these four as part of stability time was accepted: Favor: 10, Against: 0, Abstain: 4
Thursday, January 11, 2001
Joint Vocab/O&O
We started the discussion with a review of the the proposal to create a Pharmacy SIG under Vocabulary. OO had started to create a focus group to focus on Pharmacy issues. Both initiatives attempt to achieve the same to further review RIM classes, vocabulary, use cases, trigger events, R-MIM, and HMD development. A concern of SIG vs. Focus Group was raised related to visibility. Initiators no issue with Focus Group as long as they get air time. There is agreement that the group being part of OO is most appropriate. We agreed to deal with the organizational structure outside the meeting, prior to the next working meeting.
Dan Russler provided an overview of a Pharmacy Use Case Storyboard. The following two slides
[pic]
aClinical Team Order Entry refers to the use of order entry by physicians, nurses, pharmacists, respiratory therapists, physical therapists, and all other allied health personnel as well as the traditional order entry unit clerk. Today, the full scope of clinical order entry is only available in PCM Provider Order Entry, although other HIS and departmental products have order entry for some of the clinical orders.d,e,f
bToday, only the departmental pharmacy systems have Order Entry Drug Screening, which depends on subroutines during the order entry process that call out to either the First Data Bank drug-interaction tables or the Micromedix drug-interaction tables. Order Entry Drug Screening 1 by clinicians at the bedside is oriented towards screening out major drug errors against classes of drugs rather than screening against the specific NDC preparation taken from the pharmacy shelf as in gDrug Screening 2. Drug screening at the bedside should include major drug-drug, drug-diet, drug-allergy, and drug-disease interactions as well as dosage calculations based on age, sex, size parameters, renal and hepatic function laboratory tests, and other drug monitoring laboratory tests found in the clinical database. Drug screening in the pharmacy is oriented towards screening against secondary ingredients in the drug that may be present in a particular commercial preparation that is used to fill a drug order. Although drug screening at the bedside is ideal, drug screening in the pharmacy provides a partial safety net when drug screening at the bedside is not available.
cOrder Management tracks the progress of the order through the order lifecycle, communicating with the appropriate placer and filler systems at the appropriate times. Laboratory, radiology, and pharmacy are examples of filler systems, although other clinical and administrative systems that participate in the order lifecycle are considered placer and filler systems as well. Each filler system tends to have departmental order entry and order management functions that are used to modify, add, and track orders and need to communicate with the master order management system at the appropriate times. The current order status is always available from the master order management system.
[pic]
Stan Huff provided an overview of the current status on Clinical Drug discussions. See Vocabulary minutes for details.
Gunther Schadow provided an overview of the RIM structures that support Pharmacy.
Upon completing the overviews and discussions in the afternoon we agreed on:
❑ Order Application allow non-specific drug specifications or more specific. When translated into message, break out “name/substance”, units, route, dose, and form. Question is what is in “name/substance”? Heterogeneity could be handled by the terminology or through R-MIM.
❑ Agreed to have greatest flexibility if we have the individual attributes available to “separate” while vocabulary is developed that could encapsulate all aspects in a single code.
❑ Agreed we need to be able to handle from vague to specific through one name field to multiple attributes. That means we need to agree on the respective attributes relevant to the various use cases. This should be a subset of the attributes that vocabulary ascribes to a clinical drug.
❑ Creating terminology introduces similar issue as LOINC, but not seen as a concern.
❑ Pre-coordination should be feasible as well as post-coordination.
❑ We can have variants of messages where certain attributes are eliminated since the vocabulary is assumed to be more specific/refined.
Pharmacy RIM/Messages
A discussion took place on the need to add volume qty/unit to the model since Material:type_cd may not be valued. Daphne Young will prepare discussion for the next meeting, if not as part of the discussions between sessions.
Need examples:
❑ Diluted
Administration
❑ Do we need an order associated with an administration.
❑ Where to put financial information, e.g., charge, don’t charge.
❑ Does a message indicating non-administration need to be created separately from administration.
Interim V3 Message Definition Effort
Woody Beeler announced that March 19-22, somewhere, four committees (O/O, PAFM, PtCare, MedRec) will be asked to participate in an effort to accelerate V3 message definitions. HL7 will fund co-chairs/facilitators, recruit note-takers, other participants $50/day. Addl CQ (3), Vocab (ch), MnM (ch), ARB (ch).
Friday, January 12, 2001
Referral
Australian representatives reviewed an initiative to create a referral/discharge message. The scenario involves a message from the hospital to the GP with discharge information as well as possible orders and/or recommendations and/or guidelines for follow-up care. We need to look at it as a Transfer of Responsibility Agreement between providers. The data requirements from Hosp to GP may be different then GP to GP or GP to specialist. The specific questions were:
1. Where does Act Context apply?
2. Where does CDA apply?
3. How does Template apply?
4. Do we use ORD or INT or both? Discharge Summary may even be EVN.
5. Do we use LOINC or SNOMED for the heading?
This generated a discussion on the need for additional mood codes as well as it appears that Order and Intent may not be enough.
❑ The meaning of Intent is not clear to everybody since some see it as the state around scheduling while others as the state around creating an order that is not quite finalized in its authoring.
❑ It becomes clear that Order is a specialization of Intent and we use the mood intent in situations where it is not clear what specialization to use or there is no specialization, e.g., recommendation, schedule, etc.
❑ Distinctions are made between recommendation, promise, consideration.
❑ While further discussion is necessary, it seems that there is a need to create additional specializations of Intent with a guideline that a particular mood for a message should reflect one of the specializations rather then Intent itself. Intent can then be used for grouping purposes.
Regarding the specific questions we concluded:
1) We are still learning, but it seems that specific structures use the act relationship and the Act Context is still being defined.
2) When the discharge summary/referral requires the attributes identified in CDA, then it applies equally.
3) Templates may help with the structure of the components. Next session we will be spending time on this topic in a joint session.
4) Depending on the component within the message, either could be used. Pending outcome of the above discussion the use of INT and ORD will become clearer.
5) Could request for LOINC codes.
TQ
Austin Kreisler provided an overview of the progress made in the TQ discussion, as well as requested other committees to embrace deprecating the use of TQ in their respective segments. While the TQ discussion has not been concluded, the proposal is to have a statement of intent that when the new TQ1/TQ2 segments are finalized (possibly requiring additional segments to avoid introduction of new data types or continued use of undesirable data types), committees will deprecate TQ and introduce the new segments. Where committees only used (sub)components of TQ they would start to work with the new attributes from the TQ1/TQ2 segments.
Concerns were raised that the current state of TQ1/TQ2 makes them non-parse-able. That is recognized and there is agreement that we will address this before finalizing the segments.
There is a strong request from CQ to not introduce new V2.x data types.
The proposal was accepted with Scheduling, CQ, PtCare, and OO represented: Favor: 22, Against: 0, Abstain: 2.
-----------------------
[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 download
- section iii all provider manuals arkansas
- appendix 2 16 status codes defense logistics agency
- the official web site for the state of new jersey
- scope what include and exclude in 3
- ncpdp payer sheet template prescryptive
- 8 health level seven international homepage
- appendix 2 1 document identifier codes
- current contract information form washington
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