Scope: What Include and Exclude in 3

Minutes of January 2001

Orders/Observations Worksession

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 / / √ /
Judy Audin / / √
Kay Avant / / √
Steve Baranowski / √
Calvin Beebe / / √
Fred Behlen / / √ / √
Noah Bentley / / √ / √
Jeff Blair / / √
Chris Brown / / √
Nicholas Brown / / √ / √
Hans Buitendijk / / √ / √ / √ / √ / √ / √ / √ / √ / √
Eric Cannon / / √
Jim Case / / √ / √ / √ / √ / √
Carmella Couderc / / √
Miklos Csore / / √ / √
Bob Dolin / / √
Tammy Dugan / / √
Dav A. Eide / / √ / √ / √ / √ / √
Al Figler / / √ / √
Edgar Glück / / √
Louis R. Gordon / / √ / √
Erik Grimmelmann / / √
Nils Graversen / / √
Paul Gudmundsson / / √ / √ / √
Mary Hamilton / / √
Charles Hawker / / √
Ann Hueber / / √ / √
Stan Huff / / √
Gaby Jewell / / √ / √
Anne Jolly / / √ / √
Bert Kabbes / / √
Martin Kernberg / / √ / √
Jim Kingsland / / √
Andrzej J. Knafel / / √
Helmut König / / √ / √
Austin Kreisler / / √ / √ / √ / √ / √
Rebecca Kush / / √
Joann Larson / / √ / √
Patti Larson / / √ / √ / √ / √
Andrei Leontiev / / √
Rupert Lugg / / √
Tony Mallia / / √
Tom Marley / / √
Ken McCaslin / / √ / √ / √ / √
Lloyd McKenzie / / √
Jeff McNiel / / √
Gary Meyer / / √
Jason Mimick / / √
Galen Mulrooney / / √
Suzanne Nagami / / √ / √ / √ / √ / √
Manish Narang / / √
Thanh-Le Nguyen / / √ / √ / √ / √
Karen Nocera / / √ / √ / √
Rory O’Connor / / √
Vassil Peytchev / / √
Connie Pinkley / / √ / √
Kamran Rastgooy / / √
Melvin Reynolds / / √
Scott Robertson / / √ / √ / √ / √
Angelo Rossi Mori / / √
Alan Rowberg / / √ / √
Dan Russler / / √ / √ / √
Rhonda Sato / / √
Gunther Schadow / / √ / √ / √
Mark Shafarman / / √ / √
Karen Sieber / / √ / √ / √ / √
David Snavely / / √ / √
Harry Solomon / / √ / √
Mary Stehlin / / √ / √
Helen Stevens / / √ / √ / √
Sadamu Takasaka / / √
Greg Thomas / / √
Alfredo Tirado-Ramos / / √
Wayne Tracy / / √
Cheryl Tyus / / √ / √
Bruce Wood / / √ / √ / √ / √
Daphne Young / / √ / √ / √ / √ / √

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 . You can sign up on this list through HL7’s home page www.hl7.org.

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 <low value (NM)> ^ <high value (NM)>

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: <specimen source name or code (CE)> ^ <additives (TX)> ^ <freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^ <collection method modifier code (CE)> ^ <specimen role (CE)>

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: <specimen source name or code (CWE)> ^ <additives (CWE)> ^ <freetext (TX)> ^ <body site (CWE)> ^ <site modifier (CWE)> ^ <collection method modifier code (CWE)> ^ <specimen role (CWE)>

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: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)> ^ <coding system version ID (ST)> ^ alternate coding system version ID (ST)> ^ <original text(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)

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)

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)

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.