scope: what include and exclude in 3€¦ · web viewattendee company/e-mail mon am mon pm tue am...

April 2002 Minutes

Orders/Observations WorksessionTable of Contents

ATTENDEES....................................................................................................................................................... 2

GENERAL........................................................................................................................................................... 4

VERSION 2.X REVIEW..................................................................................................................................... 4

Chapter 4 Ballot Review............................................................................................................................. 5Chapter 7 Ballot Review........................................................................................................................... 33Chapter 8 Ballot Review........................................................................................................................... 50Chapter 11 Ballot Review......................................................................................................................... 53Proposal One: SPM/SAC Structure........................................................................................................... 55Proposal Two: CQ.................................................................................................................................... 55Proposal Three: CDA............................................................................................................................... 57Proposal Four: LAPOCT.......................................................................................................................... 58

VERSION 3 REVIEW....................................................................................................................................... 59

Introduction.............................................................................................................................................. 59Background.............................................................................................................................................. 60Scenario for Laboratory comments provide by Patrick Mitchell-Jones:.....................................................64Ballot Review........................................................................................................................................... 66Action Items........................................................................................................................................... 149

AttendeesAttendee Company/E-Mail Mon

AMMon PM

Tue AM

Tue PM

Wed AM

Wed PM

Thu AM

Thu PM

Fri

Nick Apperley [email protected] Fred Behlen [email protected] Hans Buitendijk [email protected]

Jim Case [email protected]

Danyemg Chen [email protected] Michelle Clements [email protected] Michele Colahan [email protected] Carmela Couderc [email protected] Corbett [email protected] Karen Covey [email protected] Maureen Donahoe [email protected] Lou Dunka [email protected] Heath Frankel [email protected] Lisa Glaspie [email protected] Hugh Glover [email protected] Nils Graversen [email protected] Rick Haddorff [email protected] Robert Hausam [email protected] Andrew Hinckley [email protected] Frank Howard Frank.w. [email protected] Julie James [email protected] Rose Jenkins [email protected] Bert Kabbes [email protected] Rosemary Kennedy [email protected] Andrzej J. Knafel [email protected]

Sara Korpak [email protected]

Austin Kreisler [email protected]

Patti Larson [email protected] Ken McCaslin [email protected]

Clem McDonald [email protected] Lloyd McKenzie [email protected]

Patrick Mitchell-Jones

[email protected]

Hugh Morgan [email protected] Manish Narang [email protected] Robert Nleski [email protected] Norman [email protected] Scott Robertson [email protected]

David Robinson [email protected] David Rowed [email protected] Gunther Schadow [email protected]

Benjamin C. Schoenbrun

[email protected]

Karen Sieber [email protected]

Harry Solomon [email protected] Robert Stegwee [email protected] Helen Stevens [email protected] Phil Taggart [email protected] Sadamu Takasaka [email protected] Mead Walker [email protected] Sherri Walter [email protected] Martin Whittaker [email protected] Eric Wilkinson [email protected]

Communication with declared O&O participants can be done through [email protected]. You can sign up on this list through HL7’s home page www.hl7.org. Related list servers for specific order/observation domain discussions

http://www.hl7.org/

mailto:[email protected]


























are [email protected], [email protected], [email protected], and [email protected], and [email protected].






GeneralOn Tuesday we held elections for a new co-chair. Helen Stevens’ term had expired. She decided not to go for re-election due to her Publishing committee commitments and changes in her personal life as she is expecting a baby. Congratulations!! We thank her for all the hard work and dedication.

Austin Kreisler ran unopposed and was elected the new co-chair. Over the last few years Austin has made tremendous contributions in the areas of V2.x and took on many responsibilities related to V3. We are looking forward to his leadership contributions, in particular helping us guide through the first V3 ballot rounds.

Karen Sieber accepted the editor responsibilities for Chapter 7 as Helen Stevens will no longer be able to do so either. We thank Karen for her volunteering to take on this responsibility.

Version 2.x ReviewOn Monday and Friday we reviewed ballot feedback related to Version 2.5. Due to the volume we were not able to complete the review during the Atlanta work sessions. We will continue review during weekly conference calls as announced through the orders list serve.

The following pages provide the complete set of ballot responses with the specific resolutions for those items we were able to address during the work sessions.

Chapter 4 Ballot Review

We were able to review only those ballot items that have notes in the Disposition Comment column.

Name General CommentJM - Joan Miller / Siemens PS - Peter Scholz MB - Maree Bellamy GG - Grahame Grieve FO - Frank Oemig KH - Kai Heitmann not in all cases segment group names are assigned in the abstract message diagram - Negative vote without further info.DM - David Markwell Contact for these comments in HL7UK is Patrick Mitchel-Jones of iSoft ([email protected]) who will attend the Atlanta

meeting representing the HL7UK v2 Subgroup. SR - Scott Robertson / Kaiser GT - Gavin Tong AK - Austin Kreisler / McKesson

RH - Richard HardingVP – Vasil Peytchev

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentDM Proposal 198 4 N Mj The removal of the SAC segment in OML

(Proposal 198) causes problems in relating work to a specific container. This has been pre-adopted in the proposals for the UK Lab - Lab messaging. We would support the removal if it is replaced with the SPM (specimen) as an optional segment.

Suggestions: Propose direction to have new trigger.12 in Favor, 1 Against, and 5 Abstain.Helen needs to address backwards comp.

DM Proposal 249 4 N Mj The Addition of a Specimen segment SPM (Proposal 249) below the ORC/OBR does not meet the requirements of the UK. Its availability does not compromise our use as it is optional but the inclusion of a SPM segment above the original SAC above the ORC/OBR would meet our requirements.

Continuation of previous.Question – Can you send an empty segment to avoid two structures?Agreed to three structures as described in Proposal One immediately following this table.15 in Favor, 0 Against, and 1 Abstain

RH Segment Tables generally

4 A Mi Some segment tables eg 4.14.4 use "N" inconsistently for No Repeats. In most of V2.x the N is omitted.

Chapter 2 addresses. There is no difference between N vs. blank. Deferred to publishing

AK 4 N Mi General query relating to all chapters and sections

It seems that since the components were removed for all data types, there should be a hyperlink to the data type definition in chapter 2. Otherwise, it is difficult to

Withdrawn and defer to publishing.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentknow what the data type components actually are. There are no hyperlinks in the current ballot. Additionally, it is now very cumbersome to use the hard copy since it involves flipping back and forth to determine the components if required.

AK 4 A Q General query relating to all chapters and sections

What is the status and group names that have been added to the message definition tables? The group name appears to be a group name for the segment grouping, but these group names are not consistantly identified throughout chapter 6 and missing from chapter 3.

Publishing already addressing this.

SR 4 4 N T <Note to ballotters>The segment group names have not been consistently applies throughout this chapter

<Note to ballotters>The segment group names have not been consistently applied throughout this chapter

Publishing will address this.

SR 4 4 N Q <Hyperlink style>default paragraph + font: 8pt, blue

<Hyperlink style>default paragraph + font: 810pt, blue

The hyperlink style has a font size of 8 pt, which is too small. Can this be increased to 10 pt? Is this a problem with this chapter or all chapters?

Withdrawn and refer Publishing.

FO 4 4 N Mi A lot of group names are mssing: O05, O06, O07, O09, O13, O14, O15, O16, O17, O18, O19, O20,O23, RAR, RDR, RER, RGR, V03, V04

Deferred to Publishing.

FO 4 4 N Mi 00576: OBX-8: data type ID or IS? 5 OBXs are not consistent. We agree that it should be an IS.17 in Favor, 0 Against, and 0 Abstain

FO 4 4 N Mi 00584: OBX-16: data type CN or XCN? 5 OBXs are not consistent. We agree that it should be an XCN.17 in Favor, 0 Against, and 0 Abstain

FO 4 4 N Mi 00286: RQ1-2: INV-17 refer to table 0385 defer Both Segment/Field needs to refer to the same table or not at all.We agreed that this needs to be corrected. Scott will initiate a proposal with Andrezj and Manish to consolidate.

FO 4 + 2 N Mi table 0100 has two different meanings: when to charge invocation event or when to charge

We will change Chapter 4 to be same as Chapter 2 and adjust in references.17 in Favor, 0 Against, and 0 Abstain

FO 4 + 6 A T OBR-45, PR1-16, FT1-26: table 0340 is not introduced in form of a table

Referred to editor.

FO 4 + 7 4 A Q two different data element ids for OBR-29: Change Chapter 4 from 222 to 261.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentparent (00222 and 00261)

FO 4 + 7 N Mi 00246: OBR-12: SPM-16 refers to table 0489?

SPM 16 should get a new item instead of 246.17 in Favor, 0 Against, and 0 Abstain

FO 4 + 7 N Mi 00249: OBR-15: other segments (TCC-3, SAC-6, SPM-4) refer to tables 0070/0163/0369!

Same item number in multiple segments referring to different table? CQ? SPM 4 needs to get new item number. 17 in Favor, 0 Against, and 0 Abstain

FO 4 + 7 N Mi 00310: RXR-2/SPM-8: what is the description of this data element?

SPM 8 needs to get new item number and table reference 016317 in Favor, 0 Against, and 0 Abstain

FO 4 + 7 7 A T table 0074 (Diagnostic service section ID) is defined twice: refer to the first occurence

Reformat in Chapter 4 and take out of chapter 7.

FO 4 + 7 7 A T table 0369 (Specimen Role) is defined twice: refer to the first occurence

Reformat in Chapter 4 and take out of chapter 7.

FO 4 + 13 + 8 N Mj 00647: Additive:CE or CWE? Ask Frank Oemig. OM4-7, SAC-27.FO 4 + 13 N Mi 01330: IPC-1/SAC-2: What is the correct

length? 22 or 80? Defer to CQ. CQ will provide minimum

and maximum lengths for data types.Proposal is to go with maximum length once provided.17 in Favor, 0 Against, and 0 Abstain

RH 4.1.5.29 4 N Mj If this is a HL7 Table it neeeds additional values.Eg what value is used if the prescription is written by a GP for dispensing at the local drug-store?

Value would be OP. If that is not sufficient submitter should suggest another through a proposal. The negative vote is found not persuasive.14 in Favor, 0 Against, and 2 Abstain

AK 4.2 4 N Mi All the new Blood Bank messages need to be modified to use the TQ1/TQ2 segments (insert following the ORC segments). If Bloodbank doesn't need Quantity/Timing data with their orders, and don't feel the TQ1/TQ2 segments are necessary, then they can introduce a new version of the ORC segment, with the ORC-7 (Timing/Quantity) marked as X - Not Supported.

We agreed to insert [{ TQ1 [{TQ2}] }] after ORC.13 in Favor, 0 Against, and 3 Abstain.The negative vote was withdrawn.

SR 4.2. 4 N Mi ... This is described in Chapter 2, Section 2.11, “Message construction rules.”

... This is described in Chapter 2, Section 2.116, “Message construction rules.”

Correct reference We accepted the edit12 in Favor, 0 Against, and 4 AbstainThe negative vote was withdrawn

GT 4.3 4 A S Remove this section completely in the final publication of 2.5. This will help chapter 4 match the construct of other chapters more

We agreed to take it out. 7 voted to take it out, 2 voted to leave it in, and 7 abstained

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentclosely.

SR 4.3. 4 A Q No strong opinion to keep or remove this section. Do we need to keep it in terms of a backward compatibility statement until TQ is removed from the Standard?

We agreed to take it out. 7 voted to take it out, 2 voted to leave it in, and 7 abstained

GT 4.4 4 N Mi Need to add STF segment to all message constructs. Also need to be consistent with where the STF is added. Check with CQ if this should always be immediately following the MSH.

Referred to CQ. We agree accept whatever outcome CQ arrives at.10 in Favor, 0 Against, and 6 Abstain

VP 4.4.1 4 N Mj MSH[{NTE}]

MSH [SFT] [{NTE}]

The SFT segment has not been consistently added to the messages. This same comment applies to many (but not all) of the message definitions. (sections: 4.4.2, 4.4.3, 4.6.2, 4.13.15, 4.13.16, 4.13.17, 4.13.18, 4.13.19, 4.13.20) Please also note the overall negative vote for adding the SFT segment in chapter 2.

Referred to CQ. We agree accept whatever outcome CQ arrives at.10 in Favor, 0 Against, and 6 Abstain

JM 4.4.1.1 4 A Mi The abstract message syntax for some order segments vary slightly. Please refer to the appropriate sections for specific examples: for supply orders (RQ), see Section 4.10 “Supply Trigger Events & Messages”

When you hold your mouse over one of the changed items, e.g., “Supply Trigger Events & Messages”, the note indicates that I made the change where I clearly did not. There are some change codes that do not appear to be using the proper field codes. It displays the current user, as the individual who performed the insert.

Refer to Publishing.

SR 4.4.3.1 4 N Mi The QRD and QRF segments are defined in Chapter 2, Section 2.16, “Message Control Segments.”

The QRD and QRF segments are defined in Chapter 2, Section 2.1615, “Message Control Segments.”

Correct reference We agreed to updated to update accordingly.14 in Favor, 0 Against, and 2 AbstainThe negative vote was withdrawn

SR 4.4.8 4 N Mj <OMI Message Schematic> <OMI Message Schematic>add TQ1/TQ2 segment group in similar fashion as other messages

The TQ1/TQ2 segment group is missing from this message. It should be added in the same fashion as the other messages.

We confirmed with ISIG that[{TQ2}] }] is appropriate to be included.11 in Favor, 0 Against, and 5 AbstainThe negative vote was withdrawn

AK 4.4.8 4 N Mi Since this new OMI^O23 message utilizes the ORC/OBR segments, it should be modified to utilize the new TQ1/TQ2 segments.


ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentAK 4.4.9 4 N Mi Since this new ORI^O24 message utilizes

the ORC/OBR segments, it should be modified to utilize the new TQ1/TQ2 segments.


GT 4.5.1 4 A S The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message.

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested).

The ORC is required in a lot of other messges as well (ORI, OMI, ORM, OSR, OMG, ORG, OML). You need to either list them all or remove this part of the sentence. I suggest removing the statement as it is redundent (information is available in the message structure) and is duplicate information to maintain.

We considered this outside scope of ballot, but would welcome submission of a formal proposal for next V2.x round.

GT 4.5.1 4 A S ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

ORC is required in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

Use term required consistently, using mandatory instead just adds confusion in understanding the difference between mandatory and required.


AK 4.5.1 4 A S ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

ORC is required in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

Use term required consistently, using mandatory instead just adds confusion in understanding the difference between mandatory and required.


VP 4.5.1 4 N mi The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise.

The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM/OMG/OML/OMI) message. ORC is mandatory in Order Acknowledgment (ORR/ORG/ORL/ORI) messages if an order detail segment is present, but is not required otherwise.

The current section says that the ORC is only required for the ORM/ORR pair, which isn't true and is doubly confusing since the ORM/ORR pair isn't the recommended message sequence anyway.

We considered this outside scope of ballot, but would welcome submission of a formal proposal for next V2.x round.The negative vote was withdrawn.

VP 4.5.1 4 N mi The ORM (SN type) message can be acknowledged by two methods:

The ORM/OMG/OML/OMI (SN type) message can be acknowledged by two methods:

This isn't the only location where the ORM/ORR message pair are referenced in scenarios exsclusively, even though that isn't the recommended message pair to use. This should be updated to be more general and inclusive of the other messages.

We considered this outside scope of ballot, but would welcome submission of a formal proposal for next V2.x round.The negative vote was withdrawn.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentSR 4.5.1.2 4 N Mi This field is a case of the Entity

Identifier data type (See Section 2.8.13, “EI - Entity Identifier”). … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).

This field is a case of the Entity Identifier data type (See Section 2.8.1316.28, “EI - Entity Identifier”) … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.1816.36, “HD - Hierarchic designator”).

Correct references We agreed to accept the edit.14 in Favor, 0 Against, and 2 AbstainThe negative vote was withdrawn

SR 4.5.1.3 4 N Mi This field is a case of the Entity Identifier data type (See Section 2.8.13, “EI - Entity Identifier”). … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).


Correct references We agreed to accept the edit.14 in Favor, 0 Against, and 2 AbstainThe negative vote was withdrawn

SR 4.5.1.26 4 N Mi (add user-defined table with no suggested values)

No table for a CWE. Shouldn't there be a user-defined table in all cases of CWE?

We agreed to insert a blank table as place holder for future use.16 in Favor, 0 Against, and 0 Abstain

GT 4.5.1.26 4 A S Condition: This field is required if ORC-20 - (Advanced Beneficiary Notice Code) indicates the patient did not sign the Advanced Beneficiary Notice with a value of 3 or 4 (based on User-defined Table 0339 - Advanced beneficiary notice code User defined table xxx values documented in HL7 specification).

Condition: This field is required if ORC-20 - Advanced Beneficiary Notice Code indicates the patient did not sign agreement of responsibility for uninsured services.

Conditionality rule is based on values in a user defined table. Suggest remofing th reference to the table. Use of table must also allow for international requirments.

Check out font size change.Expand suggested phrasing with values 3 and 4 as specific examples, plus explaining that other similar concepts could be used as well.

PS 4.5.1.28 4 N Mj ORC –28 Confidentiality Code (CE) 00615

ORC –28 Confidentiality Code (IS) 00615

Item No. 615 Confidentiality code allready used with DT IS in OM1-30 in chapter 8.8.8.30 (Harmonization needed)

Review with Lloyd/ Come back on Friday. Pending review by Lloyd

MB 4.5.1.28 4 N Mi Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 – Confidentiality Code for allowed values

New words needed to add clarity. Both HL7 Version 2.4 and draft HL7 Version 2.5 show Table 0177 as a User-defined table, not an HL7 Table.(See 8.8.8.30)Cross references should also be made to the various alternative places in the HL7 standard which encode or imply confidentiality and how they are intended to be used (eg DG1-18; PV1-16; TXA-18).


SR 4.5.1.28 4 N Mi Note: Two additional values for Confidentiality Codes that map to the V3 vocabulary domain are recommended to

Code values should be present in table 0177 in Chapter 8 for balloting.


ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentbe added to HL7 Table 0177 - Confidentiality Code. These are

SR 4.5.1.28 4 N Mi 4.5.1.28 ORC -28 Confidentiality Code (CE) 00615

4.5.1.28 ORC -28 Confidentiality Code (CNE) 00823616

Aren't all new coded attribute to use CWE and CNE?


RH 4.5.1.28 4 A Q What is the difference between the new value N (Normal) and the value U (Usual Control) from the existing table.


RH 4.5.1.28 4 A Mi A more appropriate basis for this table is Table 272 - Document Confidentiality Status.


RH 4.5.1.28 4 A Mi Need a lot of explanatory text to explain how this should be used and what is expected of a receiving system if this field assumes "Sensitive" values.Without such info, this field is useless and should be omitted.


RH 4.5.1.28et al

4 A S Suggest systematic review of confidentiality across all chapters


MB 4.5.1.29 N Mj Definition: This field indicates whether the order is an inpatient order or intended to be filled in a community pharmacy an outpatient order. If this field is not valued, the system default is assumed. Refer to HL7 table 0482 – Order type for suggested values.

Table 0482 seems restricted to hospital use. Community context does not use the terms "inpatient/ outpatient". The usefulness of this field in practice is unclear - presumably it is intended to permit orders on inpatients for inpatient use to be distinguished from orders on inpatients to be dispensed on discharge. At least, there should be an additional table value to indicate community prescriptions, which are neither inpatient or outpatient. A user-defined table is suggested.

Unclear what is intended with this and difference between community. Return to Maree, follow-up with Med SIG.

SR 4.5.1.29 4 N Mi 4.5.1.29 ORC - 29 Order Type (CE) 01643

4.5.1.29 ORC - 29 Order Type (CNE) 01644


Agreed to change to CNE.

SR 4.5.1.29 4 A Q 4.5.1.29 ORC - 29 Order Type (CE) 01643

Is there a conflict between this concept and the concept of PV1-2 Patient Class? Can a PV1-2 Outpatient receive a ORC-29 Inpatient order (and the other conbinations)? Are additional values needed in 0482 (e.g., Pre-Op) to coordinate these concepts?

Unclear what is intended with this and difference between community. Return to Maree, follow-up with Med SIG.

GT 4.5.1.29 4 N Mi M = Inpatient Order I = Inpatient Order Why was M used instead of I in the table We agreed to use I for Inpatient Order.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentvalues. I has been consistently used elsewhere to indicate Inpatient as opposed to Outpatient.

11 in Favor, 0 Against, and 2 Abstain

SR 4.5.1.30 4 N Mi 4.5.1.30 ORC - 30 Enterer Authorization Mode (CE) 01644

4.5.1.30 ORC - 30 Enterer Authorization Mode (CNE) 01645


Agreed with CNE as data type.13 in Favor, 0 Against, and 0 Abstain (Check with 01645 should be 01644)

GT 4.5.1.30 4 A S Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. E.g. paper Rx, electronic Rx, fax, phone call. Refer to HL7 Table 0aai0483 Authorization Mode for suggested values.

Definition: This field indicates the form of authorization a recorder had from the responsible practitioner to create or change an order. Refer to HL7 Table 0aai0483 Authorization Mode for suggested values.

Remove the examples - they are not necessary and they conflict with the HL7 table values.

Agreed.

PS 4.5.2.4 4 N Mi 4.5.2.4 BLG-4 Charge type Justification4.5.2.4 BLG-4 Charge type (Justification?) | (Reason?)

HL7 Attribute Table – BLG – Billing Names Element 4 as "Charge type reason" please adjust appropriate

Agreed to use Charge Type Reason11 in Favor, 0 Against, and 1 Abstain

PS 4.5.2.4 4 A T User-defined Table 0475– Charge Type Reason

User-defined Table 0475 – Charge Type Reason

missing blank after table # Typo. Agreed.

MB 4.5.2.4 A T Charge type justification Charge type reason Inconsistent naming See above. Agreed to Charge Type ReasonSR 4.5.2.4 4 N T Such as 'cho charge' or 'bill to research'

charge type as represented in the charge record.

Such as 'no charge' or 'bill to research' charge type as represented in the charge record.

Agreed with correction12 in Favor, 0 Against, and 0 Abstain

GT 4.5.2.4 4 A T Definition: This optional field explains the choice of the charge type identified in BLG-2. Refer to User-defined Table 0aaa0475 – Charge type reason for suggested values. This field provides the clinical justification/rationale for the selected charge type identified in BLG-2. Such as 'cho charge' or 'bill to research' charge type as represented in the charge record.

Definition: This field explains the choice of and provides the clinical justification/rationale for the selected charge type identified in BLG-2. Refer to User-defined Table 0475 – Charge type reason for suggested values.

Remove the examples - they are not necessary and they conflict with the table values. Also reformat the description into a single cohesive sentence. Remove word "optional" as it is redundant.

We agreed on the following definition: This field explains the choice of and provides the clinical rationale for the selected charge type identified in BLG-2. Refer to User-defined Table 0475 – Charge type reason for suggested values.

SR 4.5.3 4 A Q entire section related to OBR Should this section be repeated in both Chapters 4 & 7? This poses an ongoing synchronization problem.

All edits to this section must be validated against chapter 7.

We agreed to take it out of Chapter 7.7 to take it out, 0 to keep it in, 5 Abstain

SR 4.5.3 4 N Mi Attribute table optionality for OBR-14 (C) and OBR-15 (O)

Attribute table optionality for OBR-14 (B) and OBR-15 (B)

With the inclusion of the SPM segment, these attributes should be deprecated.

We agreed with the correction11 in Favor, 0 Against, and 2 Abstain

SR 4.5.3.2 4 N Mi This field is a case of the Entity Identifier data type (See Section 2.8.13,

This field is a case of the Entity Identifier data type (See Section

Correct references We agreed with the corrections.13 in Favor, 0 Against, and 0 Abstain

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment“EI - Entity Identifier”). … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).

2.8.1316.28, “EI - Entity Identifier”) … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.1816.36, “HD - Hierarchic designator”).

SR 4.5.3.3 4 N Mi This field is a case of the Entity Identifier data type (See Section 2.8.13, “EI - Entity Identifier”). … The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).


Correct references We agreed with the correction.13 in Favor, 0 Against, and 0 Abstain

PS 4.5.3.9 4 N S OBR-9 Collection Volume (CQ) 00243

OBR-9 - Specimen Colletion Amount (CQ) 00243

see Note on Section 7.4.3.12 Change name to Specimen Collection AmountChange definition to: For laboratory tests, the specimen collection amount is the amount of a specimen collected. The default unit is ML. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISOis a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 for full details about units.)Editor must improve on the first sentence.10 in Favor, 0 Against, and 2 Abstain

Separate question: Should this be deprecated with OBR 10 as well? If so, then do not change the OBR-9 definition, but rather get a new item number for SPM-12. Conference calls to resolve.

SR 4.5.3.14 4 N Mi Definition: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

Definition: This field has be retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present then the use of SPM-xx Specimen Received Date/Time is favored over this field.

For observations requiring a specimen,

More explict statement of deprecation. We agreed with the additional statement.12 in Favor, 0 Against, and 0 Abstain

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment

As of version 2.5, in messages where the SPM segment is present then the use of SPM-xx Specimen Received Date/Time would be favored over this field.

the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

SR 4.5.3.14 4 N T ... the use of SPM-xx Specimen Received Date/Time ...

... the use of SPM-18 Specimen Received Date/Time ...

We agreed with the correction12 in Favor, 0 Against, and 0 Abstain

SR 4.5.3.15 4 N Mi Definition: This field identifies the site where the specimen should be obtained or where the service should be performed

Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

As of version 2.5, in messages where the SPM segment is present then the use of SPM Segment would be favored over this field.

Definition: This field has be retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present then the use of SPM Specimen segment is favored over this field.

This field identifies the site where the specimen should be obtained or where the service should be performed

Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

More explict statement of deprecation. We agreed with the additional statement12 in Favor, 0 Against, and 0 Abstain

GT 4.5.3.15 4 A T The fith component is not documented - since you document all other components this seems like an oversight. Also for consistency, 7th should be seventh.

We’ll leave this for the editor to fix.

SR 4.5.3.24 4 N Mi <Table 0074> Table 0074 is structured wrong, side by side values

We agreed to fix the table.12 in Favor, 0 Against, and 0 Abstain

SR 4.5.3.25 4 N Mi <Table 0123> Table 0123 is structured wrong, side by side values

We agreed to fix the table.12 in Favor, 0 Against, and 0 Abstain

JM 4.5.3.44 4 A Q “This field will contain the HCPCS code associated with the order”

Unclear why this language was removed. Seemed to be necessary.

We agreed to leave the text as is.

VP 4.5.3.24 4 N mi HL7 Table 0074 There is no value or description for the last entry in the table: NRS Nursing Service Measures

The negative vote was withdrawn after clarifying a table can be empty.

GT 4.5.3.45 4 N Mi Definition: This field contains the procedure code modifier to the procedure code reported in field OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory

Definition: This field contains the procedure code modifier to the procedure code reported in field OBR-44-procedure code, when applicable. In the USA procedure code modifiers are defined by

Specify in the USA to support internationalization.

We agreed with the enhancement.13 in Favor, 0 Against, and 0 Abstain

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentagencies such as HCFA and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority accord-ing to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to user-defined table 0340 - Procedure code modifier for suggested values.

regulatory agencies such as HCFA and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to user-defined table 0340 - Procedure code modifier for suggested values.

GT 4.5.3.45 4 N Mi Usage Rule: This field can only be used if OBR-44-procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example HCPCS codes that require a modifier to be precise.

Usage Rule: This field can only be used if OBR-44-procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example in the USA HCPCS codes that require a modifier to be precise.

Specify in the USA to support internationalization.

We agreed with the enhancement.13 in Favor, 0 Against, and 0 Abstain

PS 4.5.3.46 4 A Mi OBR-46 Placer Supplemental Service Information

Placer Supplemental Service Information harmonization with AIS-11 Chapter 10.6.4.11 needed

Outside Scope. Need specific proposal.

PS 4.5.3.47 4 A Mi OBR-47 Filler Supplemental Service Information

Filler Supplemental Service Information harmonization with AIS-12 Chapter 10.6.4.12 needed

Outside Scope. Need specifice proposal.

SR 4.5.3.47 4 N T specification). specification). extra word after table in this section. Doesn't appear to relate to this section.

We agreed with the editorial fix.13 in Favor, 0 Against, and 0 Abstain

SR 4.5.3.47 4 N T Table 0411 is missing internal lines. Since there is no value, there is no missing line. The proposal was not accepted0 in Favor, 13 Against, and 0 Abstain

SR 4.5.3.49 4 N T If this field is not populated then routine handling is implied..

If this field is not populated then routine handling is implied..

extra period. We agreed with the editorial fix.13 in Favor, 0 Against, and 0 Abstain

GT 4.5.3.49 4 N Mi F = film with patient P = Give resutls to patient The table is too specific to the example given (radiology film). This could be aplicable to any type of result based on the description. Suggest table values are more generalized.

We found the proposal/argument non-compelling. Specific use cases are required to add specificity. You can always add more generic user defined values.0 in Favor, 10 Against, and 3 Abstain

PS 4.5.4 4 N Mi Atrribute Table for TQ1-Segment SEQ 10+11 have DT TX whereas items have DT ST

change appropriate We agreed to change narrative to TX11 in Favor, 0 Against, and 1 Abstain

SR 4.5.4 4 N Q Attribute table, Len for TQ1-2 shows as 20, but CQ data type has a length of 267. Also consider response ID# CH04-18.

Query noted, no change specified, len 20 is allowable. We found the question non-persuasive.

SR 4.5.4.2 4 N Mi Definition: This field specifies the numeric quantity of the service that

the narrative definition is not clear as to how the examples fit in the context of a CQ

Cases exist where units may be significant and need to be specific. We agreed to add

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentshould be provided at each service interval. For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2 or if three units of blood are to be typed and cross-matched, the quantity would be 3. The default value for this field is 1.

data type. In both cases, the units are abstract and would not be carried in the CQ form. If there are specific cases that require CQ then those cases should be included. Otherwise, the field should be changed back to the NM data type.

example: pediatric blood packs as “250ml” (|250^mL&….) or one of the examples from the beginning of the section9 in Favor, 0 Against, and 3 Abstain

SR 4.5.4.3 4 A Q <Table 0335> <Table 0335>

Note: Table 0335 is defined in Chapter 2, section 2.x.x.x. The table is duplicated here for the convenience of the reader. If discrepancies are noted between this duplicate representation and the content of Chapter 2, the Chapter 2 content is considered normative.

Table 0335 should be defined in Ch 02 with the RPT definition. If it is left in Ch 04, add a comment that this is duplicative of Ch 02 content and the Ch 02 content is normative (has precedence over Ch 04 table content)

We agreed to remove from chap 4 and include appropriate reference

SR 4.5.4.3 4 <narrative> still confusing. Can be very complex in pharmacy, less so in lab, and fairly simple in most other cases. Are multiple codes allowed, like QD HS or QID AC & HS. More examples?

Noted, examples would be QD~HS, etc. Editor will further review and add example(s).

SR 4.5.4.5 4 N Mi Note: In future versions, CQ fields should be avoided because the same data can usually be sent as two separate fields, one with the value and one with the units as a CE data type.

Note: In future versions, CQ fields should be avoided because the same data can usually be sent as two separate fields, one with the value and one with the units as a CE data type.

remove note from this section. Has been removed from CQ definition in Chap 2.

We agreed with the suggested edit.9 in Favor, 0 Against, and 0 Abstain

SR 4.5.4.5 4 N Mi Examples:Q6H||60^MQ6H||6^HQD||1^D

Examples:TQ1|1|1|Q61H||60^Mmin&&ANS+ - Q1H is defined with an interval between services of 60 minutesTQ1|1|1|Q6H||6^Hhr&&ANS+ - Q6H is defined with an interval between services of 6 hoursTQ1|1|1|QD||1^Dd&&ANS+ - QD is defined with an interval between services of 1 day

the examples are unclear. Add a narrative statement for each. Suggested changes assume that we are interpreting the intent correctly.

If the coding system is not specified, then the narrative is suppose to define the default code set. The examples are updated to have an appropriate code system.

We agreed to add examples.10 in Favor, 0 Against, and 2 AbstainThe negative vote was withdrawn.

AK 4.5.4.5 4 A Q Example under Relative time and units. Q6H 60^M Q6H 6^H QD 1^D

Shouldn't first example be QH? This was corrected through the previous item. The negative vote was withdrawn.

SR 4.5.4.6 4 N Mi Definition: This field contains the duration for which the service is requested.

Definition: This field contains the duration for which the service is requested.

The specification of a positive, non-zero number does not appear to serve any purpose. Negative values for a duration are illogical.

We found the suggestion not persuasive after a brief discussion and the negative vote was withdrawn

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentThe quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.

The quantity component of this field must be a positive, non-zero number. The unit's portion of this field is constrained to units of time.

SR 4.5.4.6 4 N Mi Definition: This field contains the duration for which the service is requested.


Definition: This field contains the duration for which the service is requested.


Example: Whirlpool twenty minutes three times per day for three days. Three days is the service duration.

The concepts of Service duration and occurance duration are easily confused. The addition of an example, derived from the current example for occurance duration, is suggested to clarify the intent of this concept.

We agreed to add example, editor will include coded form also12 in Favor, 0 Against, and 1 Abstain

GT 4.5.4.9 4A Mi "PRN" appears in both TQ1-3 and TQ1-9 - is there a better way to model this?

We found the suggestion non persausive. These are two code systems, different concepts. The codes happed to be the same but mean different things.

PS 4.5.4.11 4 N Mj TQ1-11 Text Instruction (ST) 01837 TQ1-11 Text Instruction (ST) 01637 Item 1837 used as Software Binary ID in section 2.15.12.4. I guess TQ1-11 is a typo and should have been 1637.

We agreed, but will refer to publishing13 in Favor, 0 Against, and 0 Abstain

JM 4.5.4.12 4 A T vaules Values We agreed to the editorial fix.SR 4.5.4.13 4 N Mi Definition: This field contains the

duration for which a single performance of a service is requested. The quantity component of this field must be a non-negative integer when populated. The units component is constrained to be units of time.

Definition: This field contains the duration for which a single performance of a service is requested. The quantity component of this field must be a non-negative integer when populated. The units component is constrained to be units of time.

The specification of a non-negative integer does not appear to serve any purpose. Negative values for a duration are illogical. Fractional values for duration may be valid (e.g., 1.5 hours).

After discussion we agreed that the negative note should remain, so we will change “non-negative integer” to “positive, non-zero number”13 in Favor, 0 Against, and 0 Abstain

SR 4.5.4.14 4 A S Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occur-rences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.

Definition: This field contains the total number of occurrences of a service that should result from this service request. If both the end date/time (TQ1-8) and the total occurrences are valued and the occur-rences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.

Example: Whirlpool twenty minutes

The addition of an example is suggested, especially since an example from another section is available and thus can illustrate the interrelationships of the concepts.

We agreed to add the example as supplied13 in Favor, 0 Against, and 1 Abstain

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentthree times per day for three days. The Total Occurances would be 9.

SR 4.5.5.2 4 N Mi <Table 0503> value R - Reserved for future use

<Table 0503> value R - Reserved for future use

HL7 table 0503 includes a value that is specifically labeled for future use. This appears to be at odds with general coding practice. Identifying a concept as "reserved" would require that the associated value be redefined in the future. Why redefine the value when we could just define it when the concept is required?

Reserved in previous versions so we cannot really take it out. The negative vote was withdrawn.

PS 4.5.5.7 4 A T HL7 Table 0505– Cyclic Entry/Exit Indicator

HL7 Table 0505 – Cyclic Entry/Exit Indicator

missing blank after table # Editorial fix

SR 4.5.5.9 4 N S Definition: The maximum number of repeats to be used only on cyclic groups. The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first.

Definition: The maximum number of repeats for a cyclic group to be used only on cyclic groups.

The total number of repeats is constrained by the end date/time of the last repeat or the end date/time of the parent, whichever is first. For example, if the total number or repeats is valued at 10 and the group has already repeated 5 times, the current order will not be repeated again if either the current order, or the prior order in the cycle, has reached its end date/time.

Conditional rule: This field can only be populated if TQ2-2 is valued with 'C'.

definition appears awkward, suggested revision of first sentence and addition of conditional rule. Added example to clarify note on end date/time consideration.

We agreed with the suggestion but with replacement for the conditional rule: Suggested: This field can only be populated if TQ2-2 is valued with 'C'.To be replaced by: This field is meaningful only when TQ2-2 is valued with 'C', but even in this case is optional.14 in Favor, 0 Against, and 0 Abstain

SR 4.5.5.10 4 N Mi Definition: ... It's primary intended use for Pharmacy administration service requests, ….

Definition: ... It's primary intended use is for Pharmacy administration service requests, ….

editorial correction

SR 4.5.5.10 4 N Mi <table 0506, value N, description>Nurse prerogative - RN Prerogative order. I've seen it ordered so that the nurse can chose between 3 or 4 different items, depending on which the patient can tolerate at the moment. Another example would be:Milk of Magnesia PO 30 ml qhs (at bedtime)/Dulcolax Supp R @ hs prn /Colace 100 mg capsule PO bid

<table 0506, value N, description>Nurse prerogative - RN Prerogative order. I've seen it ordered so that the nurse can chose between 3 or 4 different items, depending on which the patient can tolerate at the moment. Another example would be:Milk of Magnesia PO 30 ml qhs (at bedtime)/Dulcolax Supp R @ hs prn /Colace 100 mg capsule PO bid

The description of value N in table 0506 would be better as an example in the comment column

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentThe nurse may be giving the Colace twice daily as a stool softener, but may also give the Dulcolax Supp along with it if Colace is not producing any "results". For example give order 1 and order 2 or order 3. This can be extended to more than three orders. The old TQ did not handle this many to many scenario.

The nurse may be giving the Colace twice daily as a stool softener, but may also give the Dulcolax Supp along with it if Colace is not producing any "results". For example give order 1 and order 2 or order 3. This can be extended to more than three orders. The old TQ did not handle this many to many scenario.

SR 4.5.5.10 4 N Mi <Table 0506, value N, Comment> <Table 0506, value N, Comment>Example: three orders such as Milk of Magnesia PO 30 ml qhs prn, Dulcolax Supp PR qhs prn, and Colace 100 mg capsule PO bid. These administration of these three orders is based upon the nurses perjogative and assessment of the patient. The interrelationship of these orders and the nurse perjogative can be described using the TQ2 segment in each of the orders

The description of value N in table 0506 would be better as an example in the comment column

SR 4.5.5.10 4 N Mi <table 0506, value T, description>Tapering - A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days.For example, Decadron 0.5 mg is often ordered this way. The order would look like this: Decadron 0.5 mg qid (four times a day) for 2 days, then Decadron 0.5 mg tid (three times a day) for 2 days, then Decadron 0.5 mg bid (twice a day) for 2 days, then Decadron 0.5 mg qd (daily) for 2 days, then stop.

<table 0506, value T, description>Tapering - - A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days.For example, Decadron 0.5 mg is often ordered this way. The order would look like this: Decadron 0.5 mg qid (four times a day) for 2 days, then Decadron 0.5 mg tid (three times a day) for 2 days, then Decadron 0.5 mg bid (twice a day) for 2 days, then Decadron 0.5 mg qd (daily) for 2 days, then stop.

The description of value T in table 0506 would be better as an example in the comment column

SR 4.5.5.10 4 N Mi <Table 0506, value T, Comment> <Table 0506, value T, Comment> - A tapering order is one in which the same drug is used, but it has a declining dosage over a number of days.For example, Decadron 0.5 mg is often ordered this way. The order would look like this: Decadron 0.5 mg qid (four times a day)

The description of value T in table 0506 would be better as an example in the comment column

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentfor 2 days, then Decadron 0.5 mg tid (three times a day) for 2 days, then Decadron 0.5 mg bid (twice a day) for 2 days, then Decadron 0.5 mg qd (daily) for 2 days, then stop.

SR 4.5.5.10 4 N Mi <table 0506, value E, description>Exclusive - An exclusive order is an order where only one of the multiple items should be administered at any one dosage time. The nurse may chose between the alternatives, but should only give ONE of them. An example would be: Phenergan 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally every 6 hours as needed).

<table 0506, value E, description>Exclusive - An exclusive order is an order where only one of the multiple items should be administered at any one dosage time. The nurse may chose between the alternatives, but should only give ONE of them. An example would be: Phenergan 25 mg PO, IM or R q6h prn (orally, intramuscularly, or rectally every 6 hours as needed).

The description of value E in table 0506 would be better as an example in the comment column

SR 4.5.5.10 4 N Mi <Table 0506, value E, Comment> <Table 0506, value E, Comment>An exclusive order is an order where only one of the multiple items should be administered at any one dosage time. The nurse may choose between the alternatives, but should only give ONE of them. An example would be: Phenergan 25 mg PO q6h prn, Phenergan 25 mg IM q6h prn, or Phenergan 25 mg R q6h prn (three orders where only one is to be administered at a given time).

The description of value E in table 0506 would be better as an example in the comment column

SR 4.5.5.10 4 N Mi <table 0506, value S, description>Simultaneous - A simultaneous order is 2 or more drugs which are ordered to be given at the same time. A common example of this would be Demerol and Phenergan (Phenergan is given with the Demerol to control the nausea that Demerol can cause). The order could be:Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed).

<table 0506, value S, description>Simultaneous - A simultaneous order is 2 or more drugs which are ordered to be given at the same time. A common example of this would be Demerol and Phenergan (Phenergan is given with the Demerol to control the nausea that Demerol can cause). The order could be:Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed).

The description of value S in table 0506 would be better as an example in the comment column

SR 4.5.5.10 4 N Mi <Table 0506, value S, Comment> <Table 0506, value S, Comment>A simultaneous order is 2 or more drugs which are ordered to be given at the

The description of value S in table 0506 would be better as an example in the comment column

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentsame time. A common example of this would be Demerol and Phenergan. The order could be:Demerol 50 mg IM with Phenergan 25 mg IM q4h prn (every 4 hours as needed).

SR 4.5.5.10 4 N Mi <Table 0506, value C, Description>Compound - A compound is an extempo order which may be made up of multiple drugs. For example, many hospitals have a standard item called "Magic Mouthwash". The item is ordered that way by the physician. The extempo items will contain multiple products, such as Maalox, Benadryl, Xylocaine, etc. They will all be mixed together and will be dispensed in a single container.

delete this value? Compound products would either be ordered as a locally recognized service item, or would be described in two or more RXC segments. Alternatively, if this is meant to imply two different orders to be administered concurrently, the value of S in this table would be appropriate. Suggest this value should be deleted.

SR 4.5.6 4 N Mi multiple references to chapter 2 sections correct or omit this section contains multiple references into chapter 2 for data type definitions. These reference do not align with v2.5 Ch02 and need to be corrected. Alternatively, unless these references are also defined as hyperlinks, there is little added benefit to including the references. Suggest omitting reference to data type definitions in chapter 2

GT 4.6 4 A S All examples should include enough of the MSH segment to identify the trigger event being shown.

SR 4.5.6.1 4 A Mi The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step is depicted in a figure 4-x2. Identifiers of the entities are represented by the field names stated in square brackets.

The example of the hierarchy of Imaging Service Request, Requested Procedure and Scheduled Procedure Step is depicted in a figure 4-x24-??. Identifiers of the entities are represented by the field names stated in square brackets.

Figure reference needs to follow editorial norms. This may require renumbering of subsequent figures

SR 4.5.6.1 4 N Mi It is a case of the Entity Identifier data type (Section 2.8.13)

It is a case of the Entity Identifier data type (Section 2.8.1316.28, “EI - Entity Identifier”)

Correct reference

GT 4.5.6.1 4 A S The field notes for this field go far beyond describing this field. The information that is relevent to the segment or trigger event should be moved to those sections of the document, not hidden in a field note. The

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentinformation can be referenced by the field note if necessary.

SR 4.5.6.2 4 N Mi It is a case of the Entity Identifier data type (Section 2.8.13). … The second through fourth components contain the ID of the workflow management IDIS, in the same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).

It is a case of the Entity Identifier data type (Section 2.8.1316.28). … The second through fourth components contain the ID of the workflow management IDIS, in the same form as the HD data type (Section 2.8.1816.36, “HD - Hierarchic designator”).

Correct references



Correct references



Correct references

SR 4.5.6.5 4 N Mi Definition: The type of equipment requested to acquire data during performance of a Procedure Step. Such data will be used to create the images for the Imaging Study corresponding to the Requested Procedure.

Definition: The type of equipment requested to acquire data during performance of a Procedure Step. Such The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure.

editorial correction

SR 4.5.6.5 4 N Mi The third component of this field, if present, shall have the value of “DCMMC” (see HL7 table 0396).

add DCMMC to segment attribute table Since the definition of this field includes a specific code table requirement, shouldn't that code table be reflected in the segment attribute table?

In DICOM codes are moved under DCM. All external references consolidated in DICOM Part 16.Based on the discussion, the original proposal has been withdrawn. Follow-up: IIM-5 should reference DCM instead of DCMMC.

SR 4.5.6.7 4 N Mi It is a case of the Entity Identifier data type (Section 2.8.13). … The second through fourth components contain the ID of the workflow management IDIS, in

It is a case of the Entity Identifier data type (Section 2.8.1316.28). … The second through fourth components contain the ID of the workflow

Correct references

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentthe same form as the HD data type (Section 2.8.18, “HD - Hierarchic designator”).

management IDIS, in the same form as the HD data type (Section 2.8.1816.36, “HD - Hierarchic designator”).

SR 4.13.2 4 N Mi See Chapter 2, Section 2.10.53 OSD Order Sequence Definition, Use Case 1 Cyclic placer order groups for further details.

See Chapter 2, Section 2.1016.53 OSD Order Sequence Definition, Use Case 1 Cyclic placer order groups for further details.

Correct references We agreed with the editorial correction.The negative vote was withdrawn

AK 4.13.5, 4.13.6, 4.13.7, 4.13.9, 4.13.11, 4.13.13, 4.13.14, 4.13.20

4 N Mi The TQ1/TQ2 group following the RXE in these messages are marked as optional and repeating ([{TQ1 [{TQ2}]}]). It should only be repeating ({TQ1 [{TQ2}]}). This is because the TQ field in the RXE segment is required.

Agreed, however this will require that a v2.5 application must include the TQ1 segment in a RXE message, even if it duplicates information in the primary segment4 in Favor, 0 Against, and 0 Abstain

SR 4.13.6 4 N Mi RRE Message Schematic for consistency with the RDE message, an optional NTE segment should follow the RXE segment

We agreed with the proposal.4 in Favor, 0 Against, and 0 Abstain

SR 4.13.8 4 N Mi RRD Message Schematic for consistency with the RDS message, an optional NTE segment should follow the RXD segment

We agreed with the proposal.4 in Favor, 0 Against, and 0 Abstain

AK 4.13.9, 4.13.10

4 N Mi The TQ1/TQ2 group following the RXG in these messages are marked as optional and repeating ([{TQ1 [{TQ2}]}]). It should only be repeating ({TQ1 [{TQ2}]}). This is because the TQ field in the RXG segment is required.

Agreed, however this will require a v2.5 application must include the TQ1 segment in a RXE message, even if it duplicates information in the primary segment4 in Favor, 0 Against, and 0 Abstain

AK 4.13.13 4 A T RDEÔ19^RDE_O25 RDEÔ25^RDE_O25 O19 should be O25. Agreed.4 in Favor, 0 Against, and 0 Abstain

AK 4.13.13 4 N Mi The placement of the TQ1/TQ2 group within the RXO group in RDEÔ25 message is incorrect. Te TQ1/TQ2 group should appear within the ORC group, directly after the ORC, and prior to the RXO segment.

Agreed, however this will require that a v2.5 application must include the TQ1 segment in a RXE message, even if it duplicates information in the primary segment4 in Favor, 0 Against, and 0 Abstain

FO 4.13.20 4 A T group name without group Cannot locate issue, group names are being handled as a global issue.

GT 4.13.20 4 A T Move the comments in the comments column to be paragraphs before/after the message definition. This column is not valid in the table and is very hard to read.

Table being reformatted by publication

AK 4.13.20 4 N Mi QBP^Z81^QBP_Q11 QBP^Q11^QBP_Q11 This message is being refered to as a Z81. Editor will review to determine correct

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentShouldn't it be the QBP^Q11. It also referes to a RSP^Z82, which should be RSP^??? (not a z trigger).

trigger event.4 in Favor, 0 Against, and 0 Abstain

GT 4.14.1.25 4 N Mi Description: This numeric field defines the volume measurement in which the drug strength concentration is contained. For example, Acetaminophen 120 MG/5ML Elixir means that 120 MG of the drug is in a solu-tion with a volume of 5 ML and the solution form is elixir. Other examples include, 100 Units of Iletin is in 1 ML of solution.

This field is a NM data type, but the example in the description does not explain how 120MG/5ML should be sent as a number. What exactly is supposed to be sent in this field? This same comment applies to the other segments where this field appears.

Introduced field RXO-25 is meant to address specific issue such as 120gm/5ml. An example will be developed and included to illustrate use of this and related fields4 in Favor, 0 Against, and 0 Abstain

GT 4.14.1.26 4 N Mi Description is confusing. Does this tie to RXO:25, if so how. Show clear example. This same comment applies to the other segments where this field appears.

Introduced field RXO-25 is meant to address specific issue such as 120gm/5ml. An example will be developed and included to illustrate use of this and related fields4 in Favor, 0 Against, and 0 Abstain

JM 4.14.1.27 4 a T Useage Usage Editorial to be fixed4 in Favor, 0 Against, and 0 Abstain

MB 4.14.1.27 N Mj 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. Refer to HL7 table 0480 Pharmacy order types for valid values. Useage rule: This field is required for all pharmacy transactions.

(New words needed to reflect disposition.)

The use case for this field does not appear robust. In practice, usage of this field will depend on local business rules and the structure of the pharmacy. At least, this field should be a user-defined table with no suggested values and not an HL7 table.

SR 4.14.1.27 4 N Mi RXO-27 Pharmacy Order Type listed as Required

RXO-27 Pharmacy Order Type listed as Optional with default value of M - Medication

Is it appropriate to add a new field a 'required?' At what point does an system have to "comply" with this new field? When the standard is issued, when the

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentapplication chooses to use a field beyond the requried field? It would seem to be more appropriate to designate this field as option and define a default value. Base upon the available valued, M - Medication would appear to be the most general.

GT 4.14.1.27 4 N Mi 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 ex-amples. 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. Refer to HL7 Table 0aaf0480??? Pharmacy Order Types for valid values.

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. Refer to HL7 Table 0480 Pharmacy Order Types for valid values.

The way this is written the valid values can never be expanded. The comments should be moved to the table so that they are related directly to the table values.

MB 4.14.2.2 N Mi 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 0495 – 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 0495 – Body site modifier.

(New words needed to add clarity.) Chapter 4 shows table 0163 as a User-defined table in clause 4.5.3.15 and as an HL7 table in clause 4.14.2.2. Chapter 7 shows table 0163 as an HL7 table. The usage as described in Chapter 4 is unclear and needs to be fixed.

GG 4.14.2.2 4 A Q There is a reference to an alternative Body Site table which is not identified (or published?). The comments are difficult to understand without this reference

SR 4.14.2.2 4 N Mi Definition: This field contains the site of the administration route. Refer to HL7

Definition: This field contains the site of the administration route. Refer to HL7

Definition refers to a table that was not pulled into the chapter from the related

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentTable 0163 – Body Site for valid values. RXR-6 Administration Site (HL7 Table 0495 – 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 0495 – 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).

Table 0163 – Body Site for valid values. RXR-6 Administration Site may be used to modify the meaning of this field.

As a CWE 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).

proposal. Suggested changes are necessary until the related tables are brought into the chapter (4 or 7).

GT 4.14.2.2 4 N Mi Definition: This field contains the site of the administration route. Refer to HL7 Table ???? - 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.

This definition is very confusing. I am left unsure about what table should be used. Is the Body Site table the preferred table, or just for backward compatibility?

AK 4.14.2.2 4 A T Refer to HL7 Table 0163 – Body Site for valid values. RXR-6 Administration Site (HL7 Table 0495 – 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.

Identify the preferred HL7 Body Site table number

Several tables are noted. The one named as the preferred source is missing it's identifier.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentRH 4.14.2.2 4 N Mj There is a table reference of ????. Table

must be created, numbered and populated.

RH 4.14.2.2 4 N Mj 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).

It is permissable to use any appropriate coding scheme (including SNOMED) for Body Site Code.

Is this what this sentence was supposed to mean? Extending a field.

I suggest that this is NOT what was meant and that, for interoperability, we need to control which code sets (HL7 Tables) can be used here.

RH 4.14.2.2 4 N Mi It seems inappropriate to offer a choice of a precoordinated table (Table 0162) or optionally pairing a Body site table (Table 0163) with a modifier table (table ???).

PS 4.14.2.4 4 N Mi RXR-4 Administration Method (CE) 00312

RXR-4 Administration Method (CWE) 00312

DT should reflect change of table type, as in done in attribute table for RXR Segment

MB 4.14.2.6 N Mi Definition: This field contains the site modifier, used in conjunction with RXR-2, of the administration route. Refer to HL7 Table 0495 – 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 0495 – Body site modifier.

(New words needed to add clarity.) Chapter 4 shows table 0163 as a User-defined table in clause 4.5.3.15 and as an HL7 table in clause 4.14.2.2. Chapter 7 shows table 0163 as an HL7 table. The usage as described in Chapter 4 is unclear and needs to be fixed. The usage as described in Chapter 4 is unclear and needs to be fixed.

SR 4.14.2.6 4 N Mi Definition: This field contains the site modifier, used in conjunction with RXR-2, of the administration route. Refer to HL7 Table 0495 – 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.

Definition: This field contains the site modifier, used in conjunction with RXR-2, of the administration route. Refer to HL7 Table 0495 – 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

RXR-2 refers to a table that was not pulled into the chapter from the related proposal. RXR-6 reference to the use of 0163 and 0495 does not appear appropriate until enhanced body site table is present. Suggested changes are necessary until the related tables are brought into the chapter (4 or 7).

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment

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 0495 – Body Site Modifier.

populated.

RH 4.14.2.6Appendix A

4 N Mi need to create HL7 table 0495 in Appendix A and populate it with values, then copy it into here.

RH 4.14.3.8 4 A S Suggest adding example to show how this field is meant to be used. (I can see a lot of opportunity for creativity in the use of this field).

SR 4.14.4.2 4 A S If the substance is a pharmaceutical substance other than a vaccine, refer to User-Defined Table 0479 – Pharmaceutical Substances for valid values that are site defined. Sites typically use an internal coding scheme, National Drug codes (NDC), Generic Product Identifier (GPI), or Generic Code Number Sequence Number (GCN_SEQNO) as the coding scheme.

If the substance is a pharmaceutical substance other than a vaccine, refer to User-Defined Table 0479 – Pharmaceutical Substances for valid values that are site defined. Sites typically either use an internal coding scheme, National Drug codes (NDC), or some other external coding scheme.

change suggested to clarify intent

AK 4.14.4.2 4 A S NDC: 0006915404^Norvasc 10mg Tabs^NDC, DDID:015189^Norvasc 10 mg tab^DDID, CVX(HL70292): 30^HBIG^CVX U

Insert the examples in the existing wording into the User Defined Phamacuetical Substance Table below the examples

The examples are listed above the table. Within the table it reads no suggested values. Examples may be useful.

SR 4.14.4.10 4 N Mi Definition: This field contains the amount dispensed as encoded by the pharmacy or treatment supplier.

Definition: This field contains the amount to be dispensed as encoded by the pharmacy or treatment supplier.

editorial correction, encoded orders are not yet dispensed.

AK 4.14.4.30 4 N Mj A proposal that McKesson made in St Louis to make this a User Defined Table was accepted but is missing in addition the table values that were added in St Louis are missing.

Change table to User Defined and add these additional suggested values: CF =Cart Fill - Medications dispensed for cart fill, FD = First Dose - Medications dispensed for doses prior to cart fill, BO = Bill Only - Medications dispensed by other/foreign dispensing systems, but able to be returned to this automated dispensing system.

The table was made user-defined because the HL7 list was not exhasutive or suffienct to meet ever changing needs.

RH 4.14.4.32 4 N Mi Omit entire data item I cannot see how this field gets populated.I am unconvinced that this field can be populated by the dispensing system which

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentsends the RXE segment.

GT 4.14.4.35 4 N Mj Because some states may extend the list of drugs in a particular class and may create an additional schedule, table 0477 is user-defined.

Because some jurisdictions may extend the list of drugs in a particular class and may create an additional schedule, table 0477 is user-defined.

Desription says that the table is user defined, but the table is listed as HL7 defined. This table MUST be user defined because it is exclusively USA and is not international. Need to change word from States to Jurisdictions.

AK 4.14.4.35 4 N Mj Because some states may extend the list of drugs in a particular class and may create an additional schedule, table 0477 is user-defined.

Because some jurisdictions may extend the list of drugs in a particular class and may create an additional schedule, table 0477 is user-defined.

Desription says that the table is user defined, but the table is listed as HL7 defined. This table MUST be user defined because it is exclusively USA and is not international. Need to change word from States to Jurisdictions.

RH 4.14.4.35 4 A T Heading for table should show it is a User table as in the text. Cross-check also to Appendix A.

RH 4.14.4.35 4 This field specifies the class of the drug or other substance if it comes under the jurisdiction of the federal Controlled Substance Act (CSA) or a State Uniform Controlled Substance Act. Refer to user-defined table NNN0aac0477 – Controlled Substance Schedule for valid values.

This field specifies the class of the drug or other substance if its usage is controlled by legislation. In the USA, such leglislation includes the federal Controlled Substance Act (CSA) or a State Uniform Controlled Substance Act. Refer to user-defined table 0477 – Controlled Substance Schedule for valid values for USA usage. Other countries should create their own versions of this table.

The description of this field is very USA-specific.Australia has an alternative definition and content for this field.Suggest changing the definition as shown.

RH 4.14.4.364.14.4.37

4 N Mi omit both data items These fields define datafiles derived from the drug masterfile of the dispensing. It is irrelevant to send this to others.

RH 4.14.4.39 4 N Mi Omit data item. This requirement is adequately handled by the TQ1 datatype.

RH 4.14.4.40 4 N Mi Similar to 10 above.How does this data get to the dispensary?

RH 4.14.4.40 4 N Mj This field specifies the pharmacy that will dispense the prescription.

This field specifies the pharmacy that has dispensed the prescription.

The RXE segment is created by the Pharmacy that dispensed the prescription.

SR 4.14.4.44 4 N Mi RXE-44 Pharmacy Order Type listed as Required

RXE-44 Pharmacy Order Type listed as Optional with default value of M - Medication

Is it appropriate to add a new field a 'required?' At what point does an system have to "comply" with this new field? When the standard is issued, when the application chooses to use a field beyond

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentthe requried field? It would seem to be more appropriate to designate this field as option and define a default value. Base upon the available valued, M - Medication would appear to be the most general.

JM 4.14.4.44 4 a T Useage Usage GT 4.14.5.31 4 A S Dispense to Pharmacy Address.

Dispensing facility or the patient's location.

Dispensing Pharmacy Address. Dispensing facility or patient's location where dispensing will occur.

The name of the field is confusing with the description. This is the dispensing facility, not the dispense to facility.

AK 4.14.5.31 4 A S Dispense to Pharmacy Address. Dispensing facility or the patient's location.

Dispensing Pharmacy Address. Dispensing facility or patient's location where dispensing will occur.

The name of the field is confusing with the description. This is the dispensing facility, not the dispense to facility.

JM 4.14.5.32 4 a T Useage Usage SR 4.14.5.32 4 N Mi RXD-32 Pharmacy Order Type listed as

RequiredRXD-21 Pharmacy Order Type listed as Optional with default value of M - Medication

Is it appropriate to add a new field a 'required?' At what point does an system have to "comply" with this new field? When the standard is issued, when the application chooses to use a field beyond the requried field? It would seem to be more appropriate to designate this field as option and define a default value. Base upon the available valued, M - Medication would appear to be the most general.

AK 4.16 4 N Mi The data flow diagram still has the old ORM message displayed in the flow.

It should read 'ORM or OMP'. The new OMP is not represented here and may cause confusion.

AK 4.16.1 N Mi ORM/RXO: The Ordering application generates a pharmacy/treatment order (ORM with RXO and possibly additional RXC segments) and sends it to the pharmacy or treatment application, Nursing application, and/or other applications as appropriate at the site.

It should read 'ORM/RXO or OMP/RXO' The new OMP is not represented here and may cause confusion.

SR 4.17.2 4 N Mi The VXQ, VXX, and VXR messages defined below incorporate the QRF segment defined at 2.24.5, “QRF - original style query filter segment.” ...QRF-5-other QRY subject filter should be structured as shown in Figure 4-20 to transmit up to ten separate search “keys.” ....

The format of each of the possible

The VXQ, VXX, and VXR messages defined below incorporate the QRF segment defined at 2.24.55.10.5.4, “QRF - original style query filter segment.” ...QRF-5-other QRY subject filter should be structured as shown in Figure 4-206 to transmit up to ten separate search “keys.” ....

The format of each of the possible

Correct reference to QRF segment. Correct reference to Figure.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment“search keys” is given below, and listed in a more structured form in Figure 4-20.

“search keys” is given below, and listed in a more structured form in Figure 4-206.

FO 4.17.3 - 4.17.6

4 N Mi message structure Identifier missing

GT 4.18.1.1 4 A S Move table to end of chapter - it's too long. GT 4.18.1.2 4 A S Move table to end of chapter - it's too long. SR 4.20.2 4 N Mi <OMB message schematic> Since the OMB message includes the ORC

segment, the new TQ1/TQ2 segment structure should be included.

We agreed to insert [{ TQ1 [{TQ2}] }] after ORC.13 in Favor, 0 Against, and 3 AbstainThe negative vote was withdrawn.

SR 4.20.3 4 N Mi <ORB message schematic> Since the ORB message includes the ORC segment, the new TQ1/TQ2 segment structure should be included.


SR 4.20.4 4 N Mi <BPS message schematic> Since the BPS message includes the ORC segment, the new TQ1/TQ2 segment structure should be included.


SR 4.20.5 4 N Mi <BRP message schematic> Since the BRP message includes the ORC segment, the new TQ1/TQ2 segment structure should be included.


SR 4.20.6 4 N Mi <BTS message schematic> Since the BTS message includes the ORC segment, the new TQ1/TQ2 segment structure should be included.


SR 4.20.7 4 N Mi <BRT message schematic> Since the BRT message includes the ORC segment, the new TQ1/TQ2 segment structure should be included.


GT 4.21.1.3 4 A S Remove examples from the definition - these are already listed in the user defined table.

We agreed with the suggestion.

SR 4.21.2.2 4 N Mi <Table 0510 column structure> Table 0501has a non-standard column structure. Suggest that the column indicating Placer/Filler be incorporated into Comment column.

We agreed to move status values into comment column.12 in Favor, 0 Against, and 1 Abstain

SR 4.23.1 4 A Q <Table 0119 column structure> Table 0119 has a non-standard column structure. It does appear that the content is adaptable to the standard structure. Should

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentthis table be re-defined using "other table" styles?

SR 4.23.1 4 N Mi See table notes below for explanation of codes

See table notes in section 4.5.1.1.1 for explanation of codes


We were able to review only those ballot items that have notes in the Disposition Comment column.

Name General CommentLA - Liora Alschuler Overall, my comments and suggestions relate to completing the coordination between Ch. 9, Ch. 7 and CDA. Within CDA, we have explicit

instructions on use of OBX to encapsulate CDA. These ballot comments are intended to reflect the same within Ch. 9 (and Ch. 7 by extension because it is the source for definition of the OBXs carrying a document). It is my experience working with implementors at HIMSS that this would be a service to HL7 and to our members.In addition, I feel that clarification is required on the criteria for use of MDM vs ORU with respect to CDA. I voted negative on the change because it is unclear; I voted overall affirmative because I believe the intent is not to exclude CDA as payload of an ORU. If it turns out that is the intent, I would reconsider my overall vote, but would first like to understand the reasoning behind this change.

Thanks for your hard work on this. FYI, I have submitted substantially the same ballot for Ch. 9 regarding integration of instructions for using CDA as a valid payload and clarification of 7.2.

JM - Joan MillerPS - Peter ScholzMB - Maree BellamyGG - Grahame GrieveFO - Frank OemigKH - Kai Heitmann not in all cases segment group names are assigned in the abstract message diagrams. Negative Vote without further infoDM - David Markwell Contact for these comments in HL7UK is Patrick Mitchel-Jones of iSoft ([email protected]) who will attend the Atlanta meeting

representing the HL7UK v2 Subgroup.SR - Scott RobertsonGT - Gavin TongRH - Richard HardingJC - Jim CaseAK – Austin KreislerVP – Vassil PeytchevAKN – Andrezj Knafel

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentDM ORU

message7 N Mj ORU message adds a Specimen segment

below the ORC/OBR. This is inappropriate for the UK model. This should be prior to the ORC. We would support the removal if it is replaced with the SPM (specimen) as an optional segment.

We agreed to add three new trigger events and retire the existing OUL trigger event. See document (Proposal One) for structure. 16 in Favor, 0 Against, and 0 Abstain The negative vote was withdrawn

DM ORU – Unsolicited Point-Of-Care

7 N Mj ORU – Unsolicited Point-Of-Care Observation Message Without Existing Order – Place An Order (Event R30) does not allow for the inclusion of PV1, PD1.

We agreed to ad [PD1][PV1[PV2]] to all three PoC trigger events.13 in Favor, 0 Against, and 0 Abstain The negative vote was withdrawn

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentObservation Message Without Existing Order – Place An Order

These are seen as essential for use within the UK. If this is to be adopted, we would propose that optional PV1 and PD1 segments are included.

DM OUL message

7 N Mj OUL message removes the highest level of the SAC segment and adds a sample segment below the ORC/OBR. This is inappropriate for the UK requirement. We would support the removal if it is replaced with the SPM (specimen) as an optional segment.

See first response above. The negative vote was withdrawn.

FO 7 7 N Mi R01: message structure ID missing We agreed this should be ORU^R01^ORU_R01.13 in Favor, 0 Against, and 0 Abstain

FO 7 7 A Q 5 OBX segment definitions? The last four should be marked as examples

FO 7 7 N Mi 00241: SPM-19/OBR-7: what is the description of this data element?

We agreed that SPM-19 should be a new item number. 11 in Favor, 0 Against, and 0 Abstain

FO 7 7 N Mi 00243: SPM-12/OBR-9: what is the description of this data element?

Defer. We agreed that SPM-12 should get a new item number if OBR-9 is deprecated. To be resolved in Specimen conference call.

FO 7 7 A T TS DR DR SPM-17: use of strikethrough for data types instead of edit marks

FO 7 7 N Mj SPM-16: specimen risk code: data element 00246 is already in use by OBR-12! Pickup a new data element ID or apply the original properties.

We agreed that SPM-16 should get a new item number.13 in Favor, 0 Against, and 0 Abstain

FO 7 7 N Mj SPM-4: data element 00249 is already in use by OBR-15, TCC-3 and SAC-6

We agreed thatitem number.13 in Favor, 0 Against, and 0 Abstain

FO 7 7 A T value type value type OBX-2: Value Type: delete one of the two blanks

FO 7 7 A T SPM-4: table 0487 is not introduced in form of a table

SR 7 7 A T Missing Gunther as Chapter Chair/Editor We agreed to add his name.FO 7 + 8 A T table 0371 (Additive/Preservative) is

defined twice, but not quite the same

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentname: refer to the first occurence

LA 7.2 7 N Mj Chapter 7, section 7.2: If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message (MDM) rather than an observation message (ORU) and the payload may be a CDA document.

Chapter 7, section 7.2 If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message (MDM) rather than an observation message (ORU). CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents including the MDM and ORU.

Criteria not definitive with respoect to CDA. If intended to restrict transmission of CDA to MDM, then contradicts ANSI/HL7 CDA 1.0, section 2.5.2 which states: "CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM and ORU). "(NOTE: same vote/comment submitted for Ch.9)

We agreed with the proposed language in the attached document. Reference to CDA to be finalized.13 in Favor, 0 Against, and 2 AbstainThe negative vote was withdrawn.

See Proposal Three for detailed resolution.

Q: OBR and MDM status mappings (completion statuses) done? OBR is part of MDM which may address the issue. Mark Shafarmann will follow-up with MedRec.

LA 7.2 7 N Mi We strongly suggest that all text clinical reports be broken down into such separate analyzable entities and that these individual entities be transmitted as separate OBX segments. Because many attributes of a set of observations taken at one time will be identical, one OBR segment serves as a header for the report and carries the information that applies to all of the individual observations in the set. In the case of ordered observations, the OBR segment is a “turn-around document” like the manual request forms it replaces. It carries information about the order to the producing service; a copy of the OBR with additional fields completed is returned with the observations to the requesting service.

Add: Alternately, text documents can be encoded according to the CDA and sent within a single OBX

Wherever appropriate, first mention or glossary perhaps, CDA should be referenced and defined as ANSI/HL7 CDA R1.0-2000

We agreed.13 in Favor, 0 Against, and 1AbstainThe negative vote was withdrawn.

SR 7.2.1 7 N Mi Sections 7.1 to 7.4 document the trigger events, message definitions, segment definitions and examples for general observation reporting. Sections 7.5 to 7.8 include all information related to Clinical Trials. Sections 7.9 to 7.12 include all information related to Product Experience messaging, and sections 7.13

Sections 7.1 to 7.5 document the trigger events, message definitions, segment definitions and examples for general observation reporting. Sections 7.6 to 7.9 include all information related to Clinical Trials. Sections 7.10 to 7.13 include all information related to Product Experience messaging, and

update section references We agreed.13 in Favor, 0 Against, and 0 Abstain

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentand 7.16 includes Waveform messaging information. Outstanding issues are listed in section 7.17

sections 7.14 and 7.17 includes Waveform messaging information. Large tables can be found in section 7.18 and outstanding issues are listed in section 7.19.

SR 7.2.3 7 N Mj We have defined code suffixes for constructing observation IDs for the common components of narrative reports (see Figure 7-1). The observation identifier for each such component is obtained by concatenating the observation battery ID (the ID in OBR-4-universal service ID of the preceding OBR from any coding system) with the appropriate suffix. The observation ID for a chest X-ray impression, for example, would be the chest X-ray observation ID (if CPT4, it would be 71020), a subcomponent delimiter, and the suffix, IMP, i.e., 71020&IMP.

This language advocates a non-standard use of the CE data type. One of two things need to happen: (1) at statement that this is a non-standard use of the CE data type in OBX-3, or (2) a new data type should be introduced to support this structure. The only "legal" way to employ this structure in a CE data type would be for the ampersand to be escaped - but this in not included in the present wording.

Reject We agreed that this is outside the scope of the ballot. Appreciate the concern, which is shared, but given the rich history behind this construct we cannot change this without a major upset to widely implemented interfaces. We urge the submitters to recognize this issue and not bring it up again as a ballot comment. Rather, a formal proposal is required with an alternative.13 in Favor, 0 Against, and 0 Abstain

SR 7.2.4 7 A T The following subsections define each of the suffices except for the specialized waveform suffices, which are defined in Section (9), “.”

The following subsections define each of the suffices except for the specialized waveform suffices, which are defined in Section 7.14.1.

correct section reference

SR 7.2.4.24 7 A T It is fully described in Section 7.16.4 It is fully described in Section 7.14.1.2 correct section reference SR 7.2.4.25 7 A T It is fully described in Section 7.16.5 It is fully described in Section 7.14.1.3 correct section reference SR 7.2.4.26 7 A T It is fully described in Section 7.16.6 It is fully described in Section 7.14.1.4 correct section reference SR 7.2.5 7 A S Various fields of data type CE which are

used in segments defined both in the current chapter and other chapters, are used to transmit information about diagnoses, observation results, procedures, health outcomes, and drugs administered. Figures 7-2 and 7-3 (which were located in Chapter 2 in previous versions) list some common coding schemes for these types of information. The values in the second column of the table would be used in component 3 (and optionally, component 6) of a CE field to identify the coding

Various fields of data type CE, which are used in segments defined both in the current chapter and other chapters, are used to transmit information about diagnoses, observation results, procedures, health outcomes, and drugs administered. Refer to Chapter 2 section 2.17.5 for the contents of the HL7 Table 0396 – Coding system. The values in HL7 table 0396 would be used in component 3 (and optionally, component 6) of a CE field to identify the coding scheme used.

remove incorrect figure references, simplify. Question: Is this statement even necessary? This appears redundant to the definition of CE, CNE, and CWE.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentscheme used.

Refer to Chapter 2 section 2.17.5 for the contents of the HL7 Table 0396 – Coding system.

MB 7.3.1 N Mi The OUL message is designed to accommodate the laboratory processes of laboratory automation systems. The ORU message is still fully supported by HL7 for transmitting laboratory results to other systems.

The ORU message is for transmitting laboratory results to other systems. The OUL message is designed to accommodate the laboratory processes of laboratory automation systems.

To reduce confusion over usage of OUL and ORU.

SR 7.3.1 7 A T <ORU message table header>ORU^R01

<ORU message table header>ORU^R01^ORU_R01

add message structure component to message table header

SR 7.3.1 7 N Mj <ORU message structure>…{[OBX]{[NTE]}} …

<ORU message structure>…[{OBX{[NTE]}}] …

Current message structure would allow for an NTE segment without the target OBX, which will result is parsing irregularities. The OBX/NTE group should be collectively optional, the OBX should be required in the group.

JC 7.3.1 7 N Mi Observation/Result Observation related to order With the addition of the SPM segment to this message it is critical that the first OBX be explicitly listed as observations that pertain to the order, not to observations that might be associated with the specimen. This is consistent with the description of the OBX which follows the SPM segment.

JC 7.3.1 7 A T With the type (OBX) defined in this chapter…

With the segment (OBX) defined in this chapter…

Second paragraph of the introduction to this message

JC 7.3.1 7 N S one can construct almost any clinical report as a three-level hierarchy, with the PID segment defined in Chapter 3 at the upper level, an order record (OBR) at the next level and one or more observation records (OBX) at the bottom.

one can construct almost any clinical report as a multi-level hierarchy, with the PID segment defined in Chapter 3 at the upper level, an order record (OBR) at the next level with one or more order related observation records (OBX), followed by the specimen information (SPM) and one or more observations (OBX) directly associated with the specimen

Second paragraph of the introduction to this message. This needs to be clarified due to the inclusion of the SPM segment and the OBX segments being located in two positions of the message.

JC 7.3.1 7 N S Many report headers (OBR) may be sent beneath each patient segment, with many

Many report headers (OBR) may be sent beneath each patient segment, with many

This clarifies the use of the OBX segments based on their location in the

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentseparate observation segments (OBX) beneath each OBR. Note segments (NTE) may be inserted after any of the above segments. The note segment applies to the entity that immediately precedes it, i.e., the patient if it follows the PID segment, the observation if it follows the OBR segment, and the individual result if it follows the OBX segment.

separate observation segments (OBX) related to the order beneath each OBR. OBX segments that are related to specimens associated with the order immediately follow the SPM segment. Note segments (NTE) may be inserted after any of the above segments. The note segment applies to the entity that immediately precedes it, i.e., the patient if it follows the PID segment, the observation if it follows the OBR segment, and the individual result if it follows the OBX segment.

message.

VP 7.3.1 7 N mi MSH{[PID

MSH [SFT] [{PID

The SFT segment has not been consistently added to the messages. This same comment applies to many (but not all) of the message definitions.Please also note the overall negative vote for adding the SFT segment in chapter 2.

JC 7.3.2 7 A Q In the message definition, the SAC segment has been removed, yet it is still mentioned in the descriptive paragraphs. Is it the intent that no specimen or container information be sent in this message?

AKN

7.3.2 7 N Mj Specimen container information segments: SAC-SID-OBX are removed from the OUL message structure.

Remove only the optional OBX segment. The SAC-SID shall stay as they are, otherwise this message does not have any sense.

AK 7.3.2 7 N Mi The TQ1/TQ2 segment group is missing from the OUL^R21 message structure.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentAK 7.3.4, 7.3.5,

7.3.67 N Mi New messages that include the ORC/OBR

segments should also contain the TQ1/TQ2 segments for quantity/timing information. If POC doesn't need Quantity/Timing data with their orders, and don't feel the TQ1/TQ2 segments are necessary, then they can introduce a new version of the ORC segment, with the ORC-7 (Timing/Quantity) marked as X - Not Supported.

VP 7.3.4 & 7.3.5 & 7.3.6

7 N mi [NTE] {[NTE]} The NTE following the OBR (order level comments) should be repeating (for the ORU messages - R30, R31, R32,

SR 7.3.4 7 A S Note 1: This event occurs in response to any of the three point-of-care trigger events (R30, R31, R32), communicating an accession number if appropriate. The accession number is returned as the first component of the message text field (MSA-3).

Note 2: If desired, this acknowledgement message may also contain information returned from the Observation Recipient, such as the name of the patient corresponding to the order and result placed.

ACK^R33^ACK_R33

ACK^R33^ACK_R33 It took me awhile to realize that these comments were specific to the ACK^R33 message. Since this ACK applied to sections 7.3.4, 7.3.5, and 7.3.6, it might be better to show this ACK in a separate section. These notes would then be clearly associated with the ACK message, and a specific examples of the accession number and patient information being massed in MSA-3 could be included.

Also, the message structure is idential to the ACK structure. The specific structure, ACK_R33, is not necessary

FO 7.3.4 7 A T R30, R33: blank in message structure ID JC 7.3.5 7 N Q Why is this message an ORU and not a

query message? The definition of the message is that it is a query.

FO 7.3.5 7 A T R31: blank in message structure ID FO 7.3.6 7 A T R32: blank in message structure ID FO 7.3.6 7 A T ACK to R32, not to R33

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentFO 7.4.1 7 A T Relevant Clinical Info. Relevant Clinical Information 00247: OBR-13 SR 7.4.1 7 A Q Entire section related to OBR Should this section be repeated in both

Chapters 4 & 7? This poses an ongoing synchronization problem.

All edits to this section must be validated against chapter 4.

SR 7.4.1 7 N T OBR-15 Optionality O OBR-15 Optionality B OBR-15 has been deprecated in favor of the SPS segment.

PS 7.4.1.1 7 A T Set ID OBR Set ID - OBR consistency with chapter 4 PS 7.4.1.5 7 A T Priority Priority - OBR consistency with chapter 4 PS 7.4.1.9 7 N S OBR-9 Collection Volume (CQ)

00243OBR-9 - Specimen Colletion Amount (CQ) 00243

see Note on Section 7.4.3.12

AK 7.4.1.9 7 N Mi (See chapter 7 for more details about units.)

Since we are in Chapter 7 this reference should be more specific. A hyperlink would be helpful.

JM 7.4.1.15 A Mi The body site component specifies the body site from which the specimen was obtained, and the fifth is the site modifier. For example, the site could be antecubital fossa, and the site modifier “right.” The components of the CE fields become subcomponents. Refer to section 7.18.1 for the contents of HL7 Table 0163 – Body site.

When you hold your mouse over one of the changed items, e.g., “7.18/1”, the note indicates that I made the change where I clearly did not. There are some change codes that do not appear to be using the proper field codes. It displays the current user, as the individual who performed the insert.

GT 7.4.1.15 7 A S Attribute Table on page 20 indicates that this element no longer is supported by table 0070 however the fourth (4th) paragraph on page 7-25 indicates that it does (i.e. the paragraph that begins: “The specimen source name or code”). 2.16.76 does not indicate that table 70 is utilized with this data element, however the descriptor in 2.16.76.1 indicates that it does. This is a confusing change to the specification. I suggest leaving the reference to the table as it was in previous versions.

GT 7.4.1.15 7 A S Since the SPS data type is being replaced by the SPM segment, we suggest that this field be properly deprecated, and coded

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment"B". Section 7.4.3.4 says that this component is deprecated, but it isn't clear whether it actually is, or whether it is just advised against.

JM 7.4.1.24 7 A S Include bedside glucose monitor in table 0074

Some of the message type that will be using this segment, will be the point of care “world”. Bedside glucose monitors are one of the most frequently used devices, and do not typically fall under the heading of any of the other Diagnostic service section ID’s listed in that table. It should be included as the Bedside ICU monitor is.

SR 7.4.1.45 7 N T 7.4.1.45 OBR-46 Placer Supplemental Service Information

7.4.1.45 OBR-45 Procedure Code Modifier

Section numbering lost on OBR-45, all subsequent sections under 7.4.1 are mis-numbered.

LA 7.4.2 7 N Mi The OBX segment is used to transmit a single observation or observation fragment.

Add: The OBX can also contain encapsulated data, e.g., a CDA document or a DICOM image.

Since the OBX is used to transmit the CDA, this definition needs to be expanded, at least in reference to OBX within MDM.

We agreed with the suggestion.15 in Favor, 0 Against, and 0 AbstainThe negative vote was withdrawn

FO 7.4.2 7 A T * varies OBX-5: data type is called "varies" LA 7.4.2.2-.5 7 A S Add explanation of proper encoding for

CDA payload per CDA section 2.5.2. For reference, here is the full text describing how to insert a CDA within an OBX: CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM and ORU). Within the OBX segment, the MIME package is encoded as a V2.x encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED".

OBX 5 (Field 00573 Observation Value) contains the MIME package, encoded as an encapsulated data type. The components of the data type in OBX.5 should be valued as follows:· Set the value of the 2nd component (type of data) to equal "multipart".· Set the value of the 3rd component (data

We agreed to accept insertion of a reference to CDA 2.5.2 somewhere in OBX 7.4.2 intro though OBX-5. 13 in Favor, 0 Against, and 4 AbstainFollow-up to get correct reference language.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentsubtype) to equal "x-hl7-cda-level-one".· Set the value of the 4th component (encoding) to equal "A". (Note that a MIME package is not itself Base64-encoded. Rather, entities within the MIME package are Base64-encoded. A MIME package is sent as ASCII text. Therefore, the correct value for the 4th component of the encapsulated data type is "A", not "Base64".). Set the value of the 5th component (data) to equal the MIME package itself. Every entity within the MIME package must be Base64-encoded. As stated in HL7 V2.3.1 (Chapter 2, Section 2.8.16.5 ED.Data), "the data component must be scanned before transmission for HL7 delimiter characters (and other non-printing ASCII or non-ASCII characters such as LineFeed), and any found must be escaped by using the HL7 escape sequences defined in Section 2.9 'Use of escape sequences in text fields'. On the receiving application, the data field must be de-escaped after being parsed". As a result, CR/LF sequences required in the MIME package need to be escaped (i.e., converted to "\X0D0A\") prior to transmission. The content type of the first MIME entity is set to "application/x-hl7-cda-level-one+xml", and should contain the CDA document itself. Multimedia objects referenced by the CDA document that need to be transmitted with the CDA document are to be placed in successive entities of the MIME package.

SR 7.4.2.3 7 A S Definition: … Definition: …

For a discussion of the use of OBX-3 and suffixes as related to narrative reports, see sections 7.2.3 and 7.2.4

add reference to OBX-3 regarding narrative report considerations.

SR 7.4.2.4 7 The use of the sub ID to distinguish The use of the sub ID to distinguish correct figure references

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentrepeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-6 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX....However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-7. ...This is in fact the case of the repeats depicted in Figure 7-8, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-IDs 1, 2 etc. alternatively, sub-IDs 1.1, 1.2, 1.3 could be used, as shown in Figure 7-8. Figure 7-9 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results

repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-2 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX....However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-3. ...This is in fact the case of the repeats depicted in Figure 7-4, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-IDs 1, 2 etc. alternatively, sub-IDs 1.1, 1.2, 1.3 could be used, as shown in Figure 7-4. Figure 7-5 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results

SR 7.4.2.5 7 N T In Section 7.5.3, “CSS - Clinical Study Data Schedule Segment,” examples

In Section 7.8.3, “CSS - Clinical Study Data Schedule Segment,” examples


SR 7.4.2.6 7 N T We designate this coding system as ISO+ (see Figure 7-13).

We designate this coding system as ISO+ (see Figure 7-9).

correct figure reference

Also, a ballot comment was submitted against CH02 to have ISO+ added to table 0396.

SR 7.4.2.6 7 A Q The ISO+ abbreviations are the codes for the default coding system.

If ISO+ is the default code table for OBX-6, should ISO+ be listed under TBL# for OBX-6 in the segment attribute table?

SR 7.4.2.6(1) 7 A S In order to avoid potential ambiguity, we In order to avoid potential ambiguity, we Add and correct figure references

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commenthave defined another coding system, designated ANS+. It includes the US customary units (e.g., feet, pounds) and ISO abbreviations defined in ANSI X3.50 - 1986, as well as other non-metric units listed in Figure 7-13 and the ISO combinations of these units. Be aware that a few of the ANSI ISO unit abbreviations differ from their abbreviations in ISO (see note at bottom of Figure 7-13).

have defined another coding system, designated ANS+ (see Figure 7-7). It includes the US customary units (e.g., feet, pounds) and ISO abbreviations defined in ANSI X3.50 - 1986, as well as other non-metric units listed in Figure 7-7 and the ISO combinations of these units. Be aware that a few of the ANSI ISO unit abbreviations differ from their abbreviations in ISO (see note at bottom of Figure 7-7).

Also, a ballot comment was submitted against CH02 to have ANS+ added to table 0396.

SR 7.4.2.6(2) 7 N Mi The ISO+ table (Figure 7-13) includes the most common such units constructed from this grammar (as well as important non-ISO units).

The ISO+ table (Figure 7-9) includes the most common such units constructed from this grammar (as well as important non-ISO units).

correct figure reference

SR 7.4.2.6(2) 7 A Q <Figure 7-7> <Figure 7-7>Caution: Because the ANS+ specification includes both ISO and US customary units, as well as miscellaneous non-metric units, some of the abbreviations are ambiguous. Although there should be little confusion, in the context of a particular observation, this ambiguity is a good reason for avoiding ANS+ unit codes when possible.

add cautionary note from narrative of 7.4.2.6(1) to figure 7-7.

PS 7.4.3 7 A T HL7 Attribute Table SPM all item numbers for new items are missing

FO 7.4.3 7 N Mi SPM: Ids for data elements missing JC 7.4.3.3 7 A T If this field repeats, then SPM-xx

Specimen Role should be valued with "L" (pooled).

If this field repeats, then SPM-11 Specimen Role should be valued with "L" (pooled).

PS 7.4.3.4 7 N Mj SPM-4 Specimen Type (CWE) 00249 SPM-4 Specimen Type (CWE) nnnnn Item 249 is allready used as Specimen Source, As quoted later in the sectionl, Specimen Type should be the same as the first component of Item 249, so a new item must be used

PS 7.4.3.4 7 A S This attribute corresponds ... Specimen source name or code

The wording is a bit confusing, I would have interpreted specimen source name to be something like "venous blood" and Specimen Type to be something like

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Comment"whole blood" or "serum". Table 487 seems to contain some kind of mixture of both, wouldn't it be better to hav two distinct items, specifiing specimen source and specimen type ?

JC 7.4.3.5 7 A T This is particularly useful when the code set used in SPM.5 does not provide the precision required to fully describe the specimen.

This is particularly useful when the code set used in SPM.4 does not provide the precision required to fully describe the specimen.

PS 7.4.3.8 7 N Mj SPM-8 Specimen Source Site (CWE) 00310

SPM-8 Specimen Source Site (CWE) nnnnn

Item 310 is used in RXR-2 "Administration Site" which has table 163 body site asscociated. This is not compatible with SPM-8 so a new item must be used

JC 7.4.3.9 7 A T The use of this attribute is to modify, qualify or further specify, the entity described by SPM.12 – Specimen Source Site. This is particularly useful when the code set used in SPM.12 does not provide the precision required to fully describe the site from which the specimen originated.

The use of this attribute is to modify, qualify or further specify, the entity described by SPM.8 – Specimen Source Site. This is particularly useful when the code set used in SPM.8 does not provide the precision required to fully describe the site from which the specimen originated.

JC 7.4.3.10 7 A T This field differs from SPM-8 00310) Specimen Source Site

This field differs from SPM-8 - Specimen Source Site

JC 7.4.3.11 7 A T Pool (aliquantsaliquots of individual specimens combined...

Pool (aliquots of individual specimens combined...

JC 7.4.3.11 7 A T If the specimen role value is “G” then the Grouped Specimen Count (SPM-20) must be valued with the total number of specimens contained in the group.

If the specimen role value is “G” then the Grouped Specimen Count (SPM-13) must be valued with the total number of specimens contained in the group.

PS 7.4.3.12 7 N Mj Specimen Collection Amount (CQ) 00243

SPM-12 Specimen Collection Amount (CQ) 00243

Item 243 is allready used as Colllection Volume in OBR-9 as Colletion Volume. Suggestion: Change OBR-9 Name to "Specimen Collection Amount", which would be better even for OBR-9 (eg. solid specimen in lab orders)

JM 7.4.3.15 7 A Q Should code that would include “Deliver to performing facility within X hr’s of collection” be appropriate to add to this list ? Some non clinical sample collections are time sensitive.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentPS 7.4.3.15 7 N Mj SPM-15 Specimen Handling Code

(CWE) 01370SPM-15 Special Handling Advise (CWE) 01370

Item 1370 is used in SAC-43 "Special Handling Considerations" - Harmonisation needed see Note on Section 13.4.3.43

PS 7.4.3.16 7 N Mj SPM-16 Specimen Risk Code (CWE) 00246

SPM-16 Specimen Risk Code (CWE) nnnnn

Item 246 is allready used as "Danger Code" in OBR-12 with datatype CE and no asscociated table. Suggestion: create new data item

JC 7.4.3.18 7 A T This is fundamentally different from SPM-xx Specimen Collection date/time.

This is fundamentally different from SPM-17 Specimen Collection date/time.

PS 7.4.3.18 7 A T Specimen Receive Date/Time Specimen Received Date/Time JC 7.4.3.19 7 A T Messages instances for a specimen

created after this date and time the specimen will include an SPM-xx Specimen Unavailability Reason of 'EX' indicating ‘Expired’.

Messages instances for a specimen created after this date and time the specimen will include an SPM-21 Specimen Unavailability Reason of 'EX' indicating ‘Expired’.

PS 7.4.3.19 7 N Mj SPM-19 Specimen Expiration Date/Time (TS) 00241

SPM-19 Specimen Expiration Date/Time (TS) 01383

incomptible item usage, item 00241 is Observation Date/Time, create new item or use 01383 (Expiration Date/Time) from INV-12 (Chapter 13.4.4.12)

GG 7.4.3.27 7 A Mi It would be nice to have a table for container type. There is obvious pitfalls in this given the hypervariablility in container types, and the conceptual interaction with preservative. But that's exactly why it would be nice. I am happy to prepare a list if O-O thinks this is desirable

PS 7.4.13.12 7 A T SPM-12 Specimen Collection Amount (CQ) 00243.

SPM-12 Specimen Collection Amount (CQ) 00243

trailing garbage

SR 7.6. 7 N T Messages include OBR (Section 4.5.1, “OBR - observation request segment”), OBX (Section “”), RXA (Section 4.8.14, “RXA - pharmacy /treatment administration segment”), and RXR (Section 4.8.3, “RXR - Pharmacy/Treatment Order Segment”) segments to report observations or drug administration that are relevant to the study

Messages include OBR (Section 4.5.1, “OBR - observation request segment”), OBX (Section 7.4.2), RXA (Section 4.8.14, “RXA - pharmacy /treatment administration segment”), and RXR (Section 4.8.3, “RXR - Pharmacy/Treatment Order Segment”) segments to report observations or drug administration that are relevant to the study

missing section reference

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentAK 7.7.2 7 N Mi The Quantity/Timing Proposal modified

the message structure to include the TQ1/TQ2 segments, but the ballot does not reflect this.

AK 7.11.1 7 N Mi The PEX message contains two occurences of the RXE segment (which contains an TQ field), hence the RXE's should be followed by a repeating (but not optional) TQ1/TQ2 segment group. I jst caught this as part of the ballot review, it wasn't included in the Quantity/Timing Proposal submitted and approved by OO.

FO 7.11.2 7 N Mj segment "ED"? Perhaps OBX is meant instead?

SR 7.11.2 7 N Mj <SUR message>ED - Encapsulated Data Segment…Finally, the Encapsulated Data (ED) segment can be used to transmit images of documents, including any of the MIME (Multimedia Internet Mail Extension) support formats such as JPEG, GIF, and FAX.

This segment does not exist. An urgent technical correction is needed. Choices are: (1) define an Encapuslated Data Segment, or (2) recast this segment in this message as an OBX (where the ED data type can be employed in OBX-5).

RH 7.11.2 7 A Mi Since V2.3.1 (at least), there has been an SUR segment that uses an ED segment (see message syntax at 7.11.2, note that text refers to "the Encapsulated Data (ED) segment"). ED is a datatype and not a segment. This message is badly flawed.

RH 7.11.2 7 A Mi The SUR message structure has no optional segment (even the NTE is not optional).This seems to be inconsistent with most other messages.Australia has use cases where some of these segments should be optional.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentSR 7.16.2 7 N T The data types, lengths, optionality, and

repeat values listed do not replace the basic definition of the OBX segment in section 7.4.1.47.

The data types, lengths, optionality, and repeat values listed do not replace the basic definition of the OBX segment in section 7.4.2.


SR 7.16.3 7 N T Segment attribute table The segment attribute table is replicated from section 7.4.2, but does not contain some recent changes, e.g., OBX-12 name, OBX-8 repetitions.




MB 7.18.1 N Mi Table 0163 – Body site is shown as an HL7 table. Chapter 4 shows table 0163 asa User-defined table in clause 4.5.3.15 and as an HL7 table in clause 4.14.2.2.

Chapter 4 shows table 0163 as a User-defined table in clause 4.5.3.15 and as an HL7 table in clause 4.14.2.2. Chapter 7 shows table 0163 as an HL7 table. The usage as described in Chapter 4 is unclear and needs to be fixed.

MB 7.18.1 A Mi Referenced in 7.3.1.15 Coding schemes Reference does not exist GG 7.18.1 7 A T Referenced in 7.3.1.15 Coding Schemes Referenced in 7.4.1.15 Coding Schemes Wrong Reference. And also in 7.18.3 GG 7.18.1 7 N Q SPM segment is recommended as a

replacement for OBR-15, but SPM does not appear to have a functional replacement for the Body-Site component that references table 0163.

MB 7.18.3 A Mi Referenced in 7.3.1.15 Coding schemes Reference does not exist MB 7.18.5 A Mi Referenced in 7.3.2.6.2 – ISO and ANSI

customary units abbreviations Reference does not exist

GG 7.18.5 7 A Mi It seems odd to have a specimen type for Fetal Scalp, and not to have a specimen type for "fetus"

GG 7.18.6 7 A Q It is not clear to what degree

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition Commentcombinations of preservatives should be handled by repeating the field SPM-6 or whether combinations should be in the table. 2 common combinations are Heparin/Gel Seperator and Flouride/Oxalate. Either these should be added to Table 371, or a comment added to SPM-6 (7.4.3.6).

PS 7.18.6 7 N Mj HL7 Table 0371 this table differs from Hl7 Table 0371 specified in Chapter 8 Section 8.8.11.7, there must be some harmonisation

GG 7.18.6 7 N Mi There is no code in Table 371 for Sodium Bicarbonate which is a additive to 24 hour urines. (rare - porphyrins)

JC 7.4.1.14 7 A T As of version 2.5, in messages where the SPM segment is present then the use of SPM-xx Specimen Received Date/Time would be favored over this field.

As of version 2.5, in messages where the SPM segment is present then the use of SPM-18 Specimen Received Date/Time would be favored over this field.

JC 7.4.1.44 7 A T There is a duplication of the field definition. Both have been edited for content. One needs to be deleted

JC 7.4.2 7 A T The first paragrpah of the description of the segment referes to a Figure 7-5, which, while assumed to be the table of attributes, does not exist as a named figure in the chapter.

JC 7.18.6 7 N Mi The comment section of this table was updated for the vocabulary in Version 3. These new comments are much more meaningful regarding the nature of the preservatives. These should be harmonized.


We were not able to address any Chapter 8 ballot items during the worksession.

Name General CommentJM - Joan Miller PS - Peter Scholz FO - Frank Oemig KH - Kai Heitmann not in all cases segment group names are assigned in the abstract message diagramsJL - Joann Larson AK - Austin Kreisler

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentJM 8.8.2 8 N Mi where other segment(s) can be any of the

segment groups following the OM1 as described below for the following messages: MFN^M08, MFN^M09, MFN^M10, MFN^M11, and MFN^M12.following combinations:

Other segment(s) can be any of the segment groups following the OM1 as described below for the following messages: MFN^M08, MFN^M09, MFN^M10, MFN^M11, and MFN^M12.following combinations:

incomplete sentence

JM 8.8.2, 8.8.3, 8.8.4, 8.8.5, 8.8.6, 8.8.7, 8.10.1, 8.11.1, 8.12.1

8 N Mi { [MFA] } [ {MFA} ] format for optional and repeating is incorrect

JM 8.8.2, 8.8.3, 8.8.4, 8.8.5, 8.8.6, 8.8.7

8 A T Master file ACK segment Master File ACK segment Capitalize F in File for consistency with other fields

JL 8.8.8.25 8 S For tests that require a specimen, this field may contain two components in the format <specimen priority>^<processing priority>.

A technical correction needs to be applied to the definition for OM1-25; it is inconsistent with its data type ID. The statement allowing 2 components should be struck. Perhaps a new field Specimen Priority should be added, but it is not clear how this information would be transmitted in a request.

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentAK 8.8.8.25,

8.8.11.138 N Mi The field note refers to OBR-27,

Quantity/Timing, but should now point to TQ1 - 9 Priority.

PS 8.8.8.30 8 N Mj OM1-30 Confidentiality Code (IS) 00615

OM1-30 Confidentiality Code (IS) 00615

Item 615 used in ORC-28 Chapter 4.5.1.28 with DT CE, harmonization needed

JL 8.8.9.6 8 Q Should subcomponent desciptions be deleted? Are they not adequately defined in the RFR data type? Perhaps some of this narrative needs to be added to the RFR definition.

JM 8.8.9.7 8 N Mj Note: This field is not backward compatible from V2.5. For versions prior to V2.5, the expected format would utilize the component separator (|10^20|); however for V2.5 the format will utilize the sub-component separator (|10&20|).

Why is it valid to have one field within a segment not be backward compatiable? What is the recommended way to implement this for a 2.5 system communicating to another 2.5 system and 2.4 and lower systems?

PS 8.8.11.7 8 N Mj HL7 Table 0371 this table differs from Hl7 Table 0371 specified in Chapter 7 Section 7.18.6, there must be some harmonisation

Point to Chapter 7., N = 0, A = 0 , F = 16

PS 8.8.11.7 8 N Mj OM4-7 Additive (CE) 00647 OM4-7 Additive (CWE) 00647 Datatype conflicts with usage in Chapter 13 Section 13.4.3.27

Change to CWE.

JM 8.12.1 8 N Mi {MFE IIM} {MFE {IIM} } Are we trying to convey that MFE and IIM are repeatable within M15 or that IIM is repeatable within the MFE construct which is also repeatable?

AK 8.12.1 8 N Mj MFN/MFK - Inventory Item Master File Message (Event M15)

MFN/MFK - Service Item Master File Message (Event M15)

Current name conflicts with Inventory Item Master messages being proposed by Logistics.

JM 8.12.2 8 N Mi IIM-15 should be listed as repeating (as per the definition).

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentJM 8.12.2.1 8 A T The identifying key value. Must match

MFE-4 - Primary Key value - MFE. . The identifying key value must match MFE-4 - Primary Key value.

PS 8.12.2.1 8 N Mj IIM-1 Primary Key Value - IIM (CE) 01798

IIM-1 Primary Key Value - IIM (CE) 01798

Item 1798 used as "CON-23 Non-Subject Consenter Reason" in chapter 9.9.4.23 Harmonization needed

JM 8.12.2.4 8 A T Expiration date does not always have a “day” component; therefore, such a date may be transmitted as YYYYMM.

JM 8.12.2.9 8 A T Definition: This field specifies the unit for IIM-8 Inventory Received Quantity and IIM-10 Inventory Received Item Code.

Definition: This field specifies the unit for IIM-8 Inventory Received Quantity and IIM-10 Inventory Received Item Cost.

Code should be Cost for IIM-10

JM 8.12.2.9 8 A T Inventory Received Quantity unit Inventory Received Quantity Unit "u" in unit should be capitalized JM 8.12.2.13 8 A T Inventory on hand quantity unit Inventory on Hand Quantity Unit capitalization needed JM 8.12.2.13 8 N Mi Definition: This field specifies the unit

for IIM-12 Inventory on Hand Quantity.Definition for IIM-13 is missing

PS 8.12.2.15 8 N Mj IIM-15 Procedure Code Modifier (CE) 01812

IIM-15 Procedure Code Modifier (CE) 01316

Item No. 1802 allready used in ERR-2 Error Location in chapter 2.15.5.2 -use Item No. 1316 instead (OBR-45 Procedure code modifier). Harmonizatio n needed

FO 8 + 9 N Mj 01798: IIM-1 and CON-23 use same data element ID!

FO 8 + 2 N Mj 01812: ERR-2 and IIM-15 use the same data element ID


We were not able to address any Chapter 11 ballot items during the worksession.

Name General CommentJM - Joan MillerFO - Frank OemigRH - Richard HardingJL - Joann LarsonAK - Austin Kreisler

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentJM Referral 11 A Mi NA NA Figure 11-1 is not readable in the upper

left corner Correct Figure

JM Segments 11 N Mj

11.1.1.0 RF1-1 Referral Status (CE) 01137 Definition This field contains the status of the referral as defined by either the referred-to or the referred-by provider. Refer to User-defined Table 0283 - Referral status for suggested values

Add to the Existing Wording Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

After the RFI Figure on page 11-20 the Componetnts of the fields have been deleted. We should still display the component breakdown

Add Component Breakdown

FO 11 11 A S correct indentation of message tables

FO 11 11 A S group name conventions: upper case letters

FO 11 11 N Mi 00684: Preferred Method of Contact: CTD-6 and PRD-6: rename according to STF-16HJB: Drop “-Provider” to “Preferred Method of Contact.

FO 11 + 3 A T CTD-1 and NK1-7: table 0131 is not introduced in form of a table

JL 11.3 11 Q Does the committee wish to insert the SFT segment in the messages defined in this section?

ID # Section Ch. Vte Type Existing Wording Proposed Wording Comments Disposition Disposition CommentAK 11.3.5,

11.4.1, 11.5.111 N Mj The Quantity/Timing Proposal modified

the message structure to include the TQ1/TQ2 segments, but the ballot does not reflect this.



JL 11.6.3.7 11 S Refer to PRA-6-Practitioner ID numbers in Chapter 8 (Section 8.6.3.6, “Practitioner ID numbers”) for suggested values.

Refer to PLN data type in chapter 2, section 2.16.57, table 0338.

Editorial reference correction for PRD-7. The PLN data type is actually defined in chapter 2 now, section 2.16.57. Perhaps that is the better correction to make since the PRA-6 is being deprecated in chapter 15.

JL 11.6.4.7 11 S Refer to PRA-6-Practitioner ID numbers in Chapter 8 (Section 8.6.3.6, “Practitioner ID numbers”) for suggested values.

Refer to PLN data type in chapter 2, section 2.16.57, table 0338.

Editorial reference correction for CTD-7. The PLN data type is actually defined in chapter 2 now, section 2.16.57. Perhaps that is the better correction to make since the PRA-6 is being deprecated in chapter 15.

RH 11.8 11 A Mi The contents of this section have remained unchanged since V2.3. However reference is made to "recent development efforts" etc.Either update the content of the section with current situation OR delete Section 11.8 entirely.

Proposal One: SPM/SAC StructureWe agreed to provide the following triggers/structures to address the SPM/SAC issue:

Order Triggers

1) { SPM {[ SAC ]} { ORC OBR }}

2) { SPM { SAC { ORC OBR }}}

3) { ORC OBR [{ SPM [{ SAC }] }] }

Result Triggers

1) { SPM {[ SAC ]} { OBR [ORC] [{ OBX }] }}

2) { SPM { SAC { OBR [ORC] [{ OBX }] }}}

3) { OBR [ORC} [{ SPM [{ SAC }] }] [{ OBX }]}

Each of these variants will be made part of a message with a unique trigger event using the OML as the starting point. OML will be retained for backwards compatibility.

Proposal Two: CQThe following proposal was forwarded from CQ as a result of their V2.x ballot reconciliation process.

HL7 Attribute Table - OM2 - Numeric ObservationSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

7 205 CM RFR NR

OB Y 00632 Critical Range for Ordinal and Continuous Observations

11 205 RFR O Y Nnnn Critical Reference Range for Ordinal and Continuous Observations

8.8.4.78.8.9.7 OM2-7 Critical Range for Ordinal and Continuous Observations (CMRFRNR) 00632Components: <low value (NM)> ^ <high value (NM)>

Definition: Retained for backward compatibility, in version 2.5 and later refer to field OM2-11 Critical Reference Range for Ordinal and Continuous Observations.

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 and Continuous Observations).

Note: Since, in versions prior to version 2.5, the data types of OM2-6 and OM2-7 are different and preclude implementations from adhering to the last sentence of the definition: “… should be recorded here in the same format as the normal range ….” This resulted the deprecation of this field in favor of OM2-11 in version 2.5.

Note: This field is not backward compatible from V2.5. For versions prior to V2.5, the expected format would utilize the component separator (|10^20|); however for V2.5 the format will utilize the sub-component separator (|10&20|).

8.8.9.11 OM2-11 Critical Reference Range for Ordinal and Continuous Observations (RFR) nnnnn

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 and Continuous Observations).

Starting with version 2.5, this field replaces OM2-7 and employs the Reference Range (RFR) data type in order to support the same capabilities of OM2-6 - Reference (Normal) Range - Ordinal and Continuous Observations

Make sure that the item number is brand new!

We accepted the proposal with 16 in Favor, 0 Abstain, and 0 Against.

Proposal Three: CDA

7.2 PURPOSE

If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message (MDM) rather than an observation message (ORU). The reader is referred to the MDM message type in Chapter 9.

Documents/reports where the whole requires a signature or authentication as part of the message.

Documents/reports that require succession management to reflect the evolution of both document addenda and replacement documents. Succession management is described in Chapter 9.

Documents/reports where the Sender wants to indicate the availability of the report for use in patient care using the availability status present in the TXA segment, as described in Chapter 9.

Additional considerations that may affect the appropriateness of using an MDM message:

Documents/reports where the whole requires a signature as part of the message. While the ORU message does not support the inclusion of signature or authentication, some document content forms support these requirements. Of particular note, CDA documents provide for the inclusion of originator/signature. Thus, if a CDA document requires a signature but does not require succession management or report availability (as described above), then an ORU message may be appropriate. However, if the CDA document requires succession management or report availability, then an MDM message is required.

Documents/reports where the whole requires authentication as part of the message. As described for signatures, authentication may exist within the document content form. Again, CDA documents provide for the identification of an authenticator. Thus if a CDA document does not require succession management or report availability, then an ORU message may be appropriate. If succession management or report availability are necessary, then an MDM message is required.

Documents/reports where the content as a whole requires special confidentiality protection using the confidentiality status present in the TXA segment, as described in Chapter 9.

Documents/reports where document storage status is useful for archival and purging purposes using the storage status present in the TXA segment, as described in Chapter 9.

Using these criteria, the following examples of documents/reports would typically qualify as medical document management (MDM) messages. Note that as clinical content, the following documents/reports typically require succession management and/or report availability and thus would require an MDM message even if the payload utilizes CDA.

History and Physical

Consultation reports

Discharge summaries

Surgical/anatomic pathology reports

Diagnostic imaging reports

Cardio-diagnostic reports

Operative reports

As an international example, microbiology reports may include clinical interpretation and require authentication. This may not be the case in all jurisdictions, but is an example that the use or requirement of MDM messages may be influenced by local considerations.

7.2.2.5 Clinical Document Architecture (CDA):

The Health Level 7 specification for encoding and encapsulating clinical documents. (actual text reference will be supplied)

Proposal Four: LAPOCT

Chapter 13 ballot feedback was reviewed by LAPOCT SIG. We agreed to endorse their efforts with 14 in Favor, 0 Against, and 0 Abstain.

Version 3 ReviewWe reviewed V3 ballot feedback on Tuesday, Wednesday, and Thursday with Medication Information SIG and LAPOCT SIG.

IntroductionWe started our discussions with a review of how to make the V3 ballot ‘passable’. There is a June/July target for next Committee level ballot.

Various key questions had been raised through the ballot process specific to OO and in general:

What are we trying to achieve? What are the core issues? How much does the number of Application Roles matter? Does loosely/tightly coupled matter? How do the layers of understanding get built around the RIM down to the actual messaging?

Some of these are being addressed in MnM context to get a consistent approach across all areas, e.g., application roles and coupling.

We reviewed whether to use the following three objectives as we evaluate ballot responses with this diagram:

1. We need to reduce ambiguity of structural choices. There should be only one way to send a particular message. Need to clarify optionality; any variations should be clearly defined as to why they exist and when they are used.

2. We need to increase the understanding of the process of message communication and how the various artifacts taken from the RIM work together. Need to comfortable with the base patterns and the definitions that go with them.

3. Application roles vary; there is always going to have question of how much data to send in any situation. There is discussion of whether “how much data to be sent” in any particular message, especially in given examples, should be part of the normative ballot for the standard.

The following priorities/categories were derived from these objectives to organize ballot feedback:

1. Reduce ambiguity of structural choices; increase consistency2. Create layers of understanding3. Clarify optionality and pre-requisites on including structures

Can then feed this clearly back to MnM.

There was group discussion of this, and general agreement of how to take this forward. There was definite agreement of need to increase understanding of the message development process from the RIM, documentation of decisions and definitions.

We need to focus on simple repeatable patterns. Objective is to provide messages that support real world business practices (i.e. care of patients!).

We agreed to go through the Health and Clinical Management section ballot comments that relate to O&O (lab and pharmacy), to assign one of the three priorities/categories described above first, and then to facilitate the resolution process starting with those marked a priority/category of 1, then 2, and finally 3.

BackgroundWe reviewed an explanation of the following Artifacts in the Message Development Process of HL7 Version 3 on Tuesday:

MessagesA Message contains information about subject classes. An Act is a subject class, and an order is an act. Acts can go through state changes. In the laboratory domain, the ‘order’ or ‘observation’ is the core act and is the focal class. This decision to have the act rather than the patient as the focal class of the message was taken because it is the order that changes state through its lifecycle, but the patient does not, and the message is really about the order rather than the patient that the order is for. All patient information is contained within the Patient CMET.

Trigger Events (TE)These follow the Business Processes of the domain area. A Trigger Event causes an Interaction.A Trigger Event is associated with a state change of the focal class of a message; for example in the “Activate an Order” message, the “order” is the focal class, and any change of state of that order would require a Trigger Event.

Interactions (IN)These have Application Roles (a sender and a receiver), a single Trigger Event, a single Message Type and a Receiver Responsibility (optional). Each interaction is associated with an HMD.

Application Roles (AR)These will go in pairs, with a description of the role of the sending application, and a description of the role of the receiving application.

Message Types (MT)This defines the information content of the particular message.

Hierarchical Message DescriptionThis is a walk through of an R-MIM; when there is more than one path through a particular R-MIM, there will be a number of HMDs related to a particular R-MIM.

Refined Message Information Model - R-MIMThis is a cut down version of the D-MIM. There are more constraints and cloned classes than in the D-MIM. It has a single entry point, which is where to start to make a message. One R-MIM may be used for a number of similar pattern messages. There has to at least one RMIM for each HMD; but more than one HMD can relate to a single RMIM.

Domain Message Information Model - D-MIMEach domain has its own D-MIM. The D-MIM contains a representation of everything to be used in the messages used within the domain. It contains cloned classes (classes with additional constraints) from the main RIM.

V3 Ballot EvaluationTo evaluate whether the V3 Ballot addresses the messaging needs of the practice of healthcare (business processes) within a particular domain, the process should be to evaluate:The use cases and storyboards – are all the scenarios covered?What trigger events exist in the domain, and how do these relate to the state transitions?What interactions exist, and are these appropriate for the business processes?What message types exist, and do these contain the correct information?

The R-MIM and D-MIM are part of the structural/development process, providing the foundation for the message artefacts and their relationships together. They do not have to be completely analysed in order to evaluate whether the ballot package contains the necessary messages to support the business processes of the domain.

Infrastructure Controlled Event Wrapper HMD and Lab D-MIM (MW)Issue: There is a risk of overlap/confusion between these two.Discussion: (GS) Aim is to try to disambiguate the participants in the Controlled Event Wrapper. For example: In a “Cancel Order” transaction there is a need to distinguish all the different participants – the person who made the order, the person who cancelled it etc. Resolution: Need to add documentation to explain the difference between the participations in Act Relationships on the focal class (the order/intent/event – where to start the walk of the HMD) versus those of the control event.

Sensitivity Panel Results Communication (VL)The need to update the storyboards for Microbiology is accepted.

“Grouping” of Observations into Profiles eg “Full Blood Count”(DH)The structure can do this, as discussed in recent MnM meetings.The next ballot must show examples and normative text to explain this. (Vote: 13 in Favor, 0 Against,and 1 Abstain)There is a recursive relationship managed by Act Relationship_Component:

It is now clear (from the MnM discussions) that there is the ability to apply restrictions at different points within the Act Relationship_Component recursion using profiles.There was discussion of the various identifiers for the individual events and their relationships to each other at each level. The “cd* 1:1” means that an identifier is required to be sent if it exists, but it is not mandatory.

Representation of “headings” and Contextual Inferences that can safely be derived from them? (DH)Deferred, but discussion of comments followed.

Are headings “Comments”?Have established how to do ‘batteries’; how can one put a ‘heading’ on that battery?Can put text (txt attribute) from the responsible person into the observation event.Is it possible to have a comment without identifying the commenter? If so, does it go in the “txt attribute” - yes.What determines the reasons to use one particular structure over another? (For example Responsible Party txt versus txt attribute in observation event)

Need to add “Comments” to the O&O issues list and have some storyboards/use cases to support these. Patrick Mitchell-Jones will provide storyboard for this.

Structures are needed to unambiguously describe microbiology information, particularly the unwrapping of recursion.

Appropriateness of A_Observation_event name-value pair construct eg the Microbiology and General Medical domains (DH)Hepatitis B - is this a test or a medical condition?Vocabularies usually have some context information – diagnosis codes are different from test codes.It is an appropriate construct, so will resolve this by giving examples of name-value pair constructs to show how the vocabulary codes should be used in the message (Karen will do this).(vote: 14 in Favor, 0 Against, and 1 Abstain)

Specific State-Transition Diagrams for Each Business Object (DH) Business object (focal class) of O&O is an order, intent or supply; these do have their own specific state transition diagram based on the Act State Transition Diagram.It would be very helpful to describe more clearly the states in relation to orders, intents and supply. This could be done in the Introductory Section, with storyboards.

Description of Acknowledgement Modes (DH)O&O V3 work for Receiver Responsibilities only describes the ORR type of acknowledgement. The Message Wrapper from Infrastructure Management dictates the simple ACK type.

Receiver Responsibility Review:O&O need to review whether any specific Receiver Responsibilities have been missed (Sara). Also need to make sure that all appropriate Receiver Responsibilities are documented. Need to investigate how to indicate that no receiver responsibilities are required in a particular scenario. (Austin)

“Nullify” Trigger Event (DH)This is essentially the same as the issue with state transitions – making the definitions clear and having examples. Should never ‘lose’ the record of a nullified event, and cannot dictate what an application does with a nullify message.

Scenario for Laboratory comments provide by Patrick Mitchell-Jones:Dr Door collects two specimens of blood from Mr Smith who has just been admitted to the observation ward complaining of abdominal pains. For one specimen he places an order with the laboratory for a Urea & Electrolytes, Amylase and Liver Function tests and asks to be telephoned with the results. For the second specimen places an order for protein electrophoresis. He labels the samples with the sample labels generated by the system. The order is transmitted to the laboratory and Dr Door leaves the samples on the ward to be collected by the porter and transferred to the laboratory. Unfortunately, he places them in the incorrect place.

Harry, the porter arrives on the ward on his scheduled round and picks up samples from the collection point, failing to pick up Mr Smith’s sample. He continues on his round and picks up samples from other wards and returns to the laboratory.

The laboratory accept the samples into the laboratory system using the ordering system sample number to retrieve the order details and applies a laboratory number to each (filler number).

Dr Door has had a number of emergency cases since he collected the sample and has not been telephoned with the results on Mr Smith by the time that he gets to the end of his shift. He checks on the patient, who is comfortable and not complaining of pain any more. Dr Door rings the lab to see why he hasn’t been telephoned with the results. They tell him the sample was not received. He checks the hospital system and sees that the order is still on the system but not acknowledged by the lab. He looks for the sample and finds it where he left it. He rings the porter and arranges for pick-up.

The porter picks up the sample and transports it to the laboratory.

On receipt of the sample by the laboratory, the technician notes that the samples were collected 6 hours ago and makes a comment against them ‘Sample received 6 hours after collection’.

The U&E, AMY and LFT sample is analysed, the results validated (for technical correctness) and subjected to the LIS authorisation (clinical approval) rules. These rules check for specific conditions such as reference range or delta check failure, and will hold up observations or observation batteries that meet defined criteria for manual approval. The Protein Electrophoresis is stored for the next run of electrophoresis testing. The laboratory has recently changed the analyser that carries out the LFT tests and has added a comment to the battery definition to be included on reports that advises the recipient of this. Because the Potassium is raised and the Amylase outside the normal range, all the results are held up for approval by a clinically qualified person. Only when this approval is complete can the results be made available to Dr Door. The Clinical Chemist, Sylvia Moore, checks the list of results waiting for clinical approval and reviews the results for Mr Smith. She adds a comment to the Potassium result to indicate that the potassium is raised but this may be due to the age of the sample.

On looking at the overall U&E results, she notes that the combination of the results suggests that the patient may be dehydrated and puts a comment against the battery.

The overall results of the analyses suggest pancreatitis and she adds a clinical comment that applies to all the results being released to Dr Door at that time, i.e. the U&E and LFT batteries and AMY result.

The protein results will be released later with any appropriate clinical comments that may be added.

The relationships of the comments made are:

1. Sample has a comment regarding the lateness of delivery which should be reported with all observations carried out on that sample.

2. The observation battery (LFT) has a note identifying a change of method3. The observation battery U&E has a clinical comment indicating dehydration4. The observation potassium (part of the U&E battery) has an observation-specific comment5. The U&E and LFT batteries and AMY result have a clinical comment (diagnosis?) which applies

to all the observations being approved at that time.

1 is satisfied by the O_SpecimenCharacteristics (Obs)

2 is satisfied by the A_Observation_event (Txt)3 is satisfied by the A_Observation_event (Txt)4 is satisfied by the A_Observation_event (Txt)5 I haven’t a clue how this is handled.

Ballot Review

We were only able to address those ballot items with notes in the Disposition Comment column.

Name General CommentDN - Dale NelsonGD - Gary DickinsonJM - Joan MillerHF - Heath FrankelMW - Mead WalkerBD - Bob DolinSB - Sandy BoyerSR - Scott RobertsonVL - Virginia LorenziBK - Bert KabbesNA - Nick ApperleyDH - Dick Harding

ID # Artifact Section Dmn Vte Tpe Existing Wording Proposed Wording Comments DispVL 16 ST 2.1.1 All N Mj This storyboard does not adequately show

the sensitivity panel results communication.

Each sensitivity result should be listed and arrows for each interaction drawn. The method or methods used should be specified.

Microbiology results are common and core to most lab interfaces. They are one of the hardest to implement in V2 partially to the flexibility in the specification and in the lack of adequate documentation in earlier releases. If microbiology is to be addressed in this release of V3, care should be taken to well document how the sequence of messages are communicated.

Accept

BD Applicable sections of ballot and related CMETs

All N Mj Substance_administration.cd vocabulary domain; Substance_administration.route_cd vocabulary domain.

I don’t agree with the current approach to pharmacy messaging, that would put drug codes into Substance_administration.cd, and would mix both routes and actions in Substance_administration.route_cd. This approach allows a concept to serve as both an entity or an act depending on the context. It also seems to diverge from the USAM model by putting codes into the Act.cd field that aren’t acts. A substance isn’t an act, and therefore shouldn’t be

Defer

included in the vocabulary domain of Substance_administration.cd. The approach in this ballot is no different than would be the case if we were to create an Act class code of “implant”, where the values for Implant.cd are device concepts. Substance_administration.cd – This attribute should not be populated by drug entity codes. It should not be allowed that a concept can be the value of an Entity.cd and an Act.cd. The Substance_administration.cd should convey the kind of administration –including values such as “injection”, “infusion”, “irrigation”, “instillation”, etc. Substance_administration.route_cd – This attribute defines the route of administration. It should not be an act code (i.e. should not include “injection”, “infusion”, etc). Just because people like to say [administer this drug by "intravenous injection" or by "transdermal application"] doesn’t mean that the stuff in quotes represent administration routes. Also, route codes are not the same as body site codes. For instance, “transdermal” and “intravenous” are routes, and are not body sites. SNOMED differentiates Route and Procedure Approach codes from body site codes. Substance_administration.route_cd values should include things like “intravenous”, intrarterial”, “transdermal”.


All N Mj Procedure.approach_site_cd vocabulary domain

disagree that these are body site concepts. When we’ve discussed this with a group of surgeons in the past, the feeling was that a surgical approach is not a body site but more of a technique. SNOMED has distinct codes for procedure approach and for body site.

Defer


All N Mj Participation.type_cd vocabulary domain Because the Participation.context_control_cd uses the hierarchical structure of the vocabulary domains when determining inheritance (“Additive inheritance adds new objects into the inherited context while overriding inheritance replaces inherited objects of the same or more specific type/class with this inherited object”), we need to be sure that the vocabulary hierarchies represent strict subtype/supertype hierarchies. When Concept A is stated to be a child of Concept B, it must ALWAYS be the case that Concept A is a kind of Concept B, irrespective of the context in which the concept is sent. Some of the parent-child relationships that may not represent strict subtype/supertype relationships include: -- ServiceActorInformationGenerator – if this is meant to represent authors and originators of information, I’m not sure why CBC (call-back contact) or ENT (data entry person) are included. Also, INF (informant) is really a source of information rather than an author, so this one may not belong either. -- ServiceTargetTypeSubject – should include PATSBJ (patient subject). (PATSBJ should be a child of PAT and of SBJ).· TargetTypeLocation – Not sure why RCV (receiver) is included here. --

Defer

ServiceTargetTypePatient – the definition says that this “indicates whose patient medical record this service item is part of”. So I’m not sure BBY (baby) and MTH (mother) belong here – because I think these values will be used within a single report (e.g. an obstetrical ultrasound) to differentiate the subject of the various observations. Perhaps these values need to be moved under SBJ (ServiceTargetTypeSubject)?

GD 13 General Comment - Application Profile - Sender or sender/receiver adapters to the RIM?

All n mj Initial assumption: the HL7 v3 "application role profile" specifies the common denomination (CD) of classes, attributes, relationships and events in common between the unity RIM and the heterogeneous application instance, presumably in 1-n specializations of sender and receiver? (Unless each application truly instantiates all RIM classes, attributes, relations and events, its application role profile is but a proper subset "view" of the unity RIM.) OK, so now I understand, an application role profile is unique to an application instance and specifies its common denominator with the unity RIM. But wait a minute - application roles were supposed to ensure v3 interoperability between paired and complementary sender and receiver roles. Does this make the "application role profile" really a common demoninator (of classes, attributes, relationships and events) between, and thus unique to, the unity RIM, the sender app instance and the receiver app instance? So what have we: 1) an application role profile unique to an application instance, as sender or receiver (i.e., CD of a single application instance and the RIM); or 2) an application role profile unique to the paired

Defer

sender and receiver applications and intermediate RIM (i.e., CD of paired sender, receiver applications and the RIM)? Describe.

GD 16 General Comment - Application Role Profile Registry - True Interoperability or a Slippery Slope to Chaos?

All n mj If not by ballot, describe how HL7 intends to induce the industry to agree on a smallish subset of all possible application roles, such that interoperability can be truly touted as a v3 achievement. The existing application role registry amply illustrates a slippery slope to chaos, not interoperability.

Defer

DH All · How to “group” observations into profiles eg “Full Blood Count”

Accept

DH All · How to represent “headings” and what contextual inferences can safely be derived from them

Defer

DH All · Choice of terminology (codesets) to be used in specialist domains eg Microbiology

Defer

DH All · Whether the name-value pair construct provided in A_Observation_event is appropriate for eg the Microbiology and General Medical domains.

DH All · each business object (person, order) must have its own specific state-transition diagram which specifies the entire lifecycle of the business object. I have voted on this during the first ballot.

Defer

DH All Acknowledgement modes need to be described with each Interaction particularly for those interactions where a number of acknowledgement modes is possible (eg the acknowledgement of an order message is sometimes a modified order message eg an ORR in V2 terms and othertimes a simple ACK. Otherwise conformance is unable to be tightly specified.

Accept

DH All Need more discussion re the “nullify . . .” trigger event. The trivial case where the error is realised as soon as it is made is OK. But need to discuss the case where the error is detected only after services have been provided.

Defer

MW CL005

DM 5 POLB

N Mj Looking at the Lab DMIM, and the Infrastructure Controlled Event Wrapper HMD, there appears to be a severe potential for overlap and confusion between the two. Since a message instance will include both this overlap needs to be addressed. For example, the Controlled Event Wrapper contains the following participations: P_callback, P_data_entry, P_device, P_entry_location, P_initiator, P_responsible_parties, and the following act relationships, AR_reason, and AR_encounter. At the same time, the Lab DMIM has the following that appear to overlap:P_Responsible_party, P_Data_entry, P_Callback_contact,

Accept

AR_Encounter. There needs to be an explanation that tells people when to use controlled event participations, and when to use order intent participations.

MW CL006

DM 5 POLB

A S In AR_Observation_event_component, two type codes are allowed, COMP and OCCUR. The document should to explain when to use one and when to use the other. (Is this overkill? On the other hand, simply allowing the option creates the potential for confusion.)

Accept

HF ST 2.1 POLB

N Q Request Response - Accept Lab Order Activate, Reject?? Lab Order Complete??

What is this message? I assume it is not the message control level acknowledgment. I assume it is not a 'Lab Intent, notification' as this is explicitly shown next. There only seems to be a 'Lab order Activate, Reject' interaction, no Accept. Can it be a 'Lab order, complete' interaction?

Defer

HF ST 2.2 POLB

N Q e.g. Notification, Lab Event Final 3.1 e.g. Lab Event Complete, Notification 3.1 Is there a difference between Lab Event Final and Lab Event Complete

Defer

HF ST 2.2 POLB

N Q e.g. Notification, Lab Event Preliminary 2.1 and Notification, Lab Event Final 2.1

e.g. Lab Event Complete, Notification 2.1 and Lab Event Revise, Notification 2.1

What is this message? Is it another Lab Event Complete which gets revised later? Why not show this?

Defer

HF AR 3.1 POLB

N S At present, Practice and Observations deals with the following state transitions: Activate, Suspend, Resume, Abort, Replace (a ombination of 'Obsolete' and 'Activate'), Complete and Re-activate.

At present, Practice and Observations deals with the following state transitions: Activate, Suspend, Resume, Abort, Complete and Re-activate. A combination of making 'Obsolete' an existing act and 'Activate' or 'Complete' a new act is defines a special state transition 'Replace' which is not provided in the Act state machine.

It is not immediately obvious that replace is not a standard state transition on the Act state machine and that it actually generates a new act after making the old one obsolete. However the definition of Replacement down further does help.

reject

VL 42 AR 3.1 POLB

N Mi Reactivation: This application role is capable of re-activating an Act that was completed in error (re-activate state transition). An application supporting this role must also support the Basic and Lifetime application roles.

Separate this from Nullify since in some cases, both are not applicable.

Accept

VL 43 AR 3.1 POLB

N Mi Comprehensive: This application role is a superset of all the above roles. It includes all the supported act transitions (Activate, Abort, Complete, Suspend, Resume, Replace, Revise, Reactivate, and Nullify). If an application plays this role, it should NOT play any of the subset roles (Basic, Lifetime, Nullification, Suspension, Revision, Replacement, or Reactivation).

Defer

VL 44 AR 3.1 POLB

N Mi Replacement:…Revision:… Add the following line to each of these: " Applications supporting this role must also support the Basic application role."

Accept

VL 51 AR 3.1 POLB

A S Placer/Fulfiller and Confirmer/Confirmation Receiver narrative

The narrative which explains the break-up between Placer/Fulfiller and Confirmer/Confirmation Receiver is very confusing and would no longer be correct if above suggests are accepted. I think the narrative should be removed.

DN 52 DM 5.1 POLB

N Mi Participations on A_Observation_intent are duplicated from Control Event Wrapper: P_Responsible_party, P_Data_entry, P_Actual_performers etc. Where do you use which?

VL 94 HD 7 POLB

A S When you click on the definition of the field and then on the vocab behind it, the vocab for ACT elements often references the old service object.

Accept

DN 95 HD 7.1 POLB

N Mi no vocab links for CNE domains ParticipationMode

Defer

HF ST 2.1/2.2 POLB

N Mj Request Response - Accept In the story board diagram in section 2.1 the Request response is returned to the 'Lab Tracker' but in other diagrams including the one in section 2.2 this Request response is returned to the 'Lab Order Requestor'. Which is the correct target for the response? Does it depend on the actual message sent (as described above)? These should be consistant onless there is a reason for them to be different in which case a more descriptive interaction description might help explain the difference. Currently thios inconsistancy just makes it very confusing

Accept

VL 23 ST 2.2.1 POLB

A S "in filler initiated reflex order" "a reflex order" Aren't reflex orders by definition, from the filler? This wording implies that there is more than one type of reflex order.

reject

VL 25 ST 2.2.2 POLB

A T Should there be a lab intent? Remove this question - it must have been left in by accident

JM 2-hk AR 3 Applicati

POLB

N MI N/A N/A Why are act state transitions defined for the Introductory Application Role explanation

Accept

on Roles + 4 Trigger Events

of the application role hierarchy rather than by a state transition diagram related to the trigger events section which contains state transition based and interaction based trigger events? Explanations for state transitions are contained within the RMIM and Interaction section. So the information is scattered what makes it difficult to grasp the "big picture".

VL 58 AR 3.124-3.125, 3.148, others

POLB

N Mi Order Confirmer Roles All Lab roles with "Order Confirmer" in them should be removed. No need for ordering system to confirm orders in lab since proposals are not used. Intent is the proper confirmation of an order.

Defer

VL 53 AR 3.14-3.17

POLB

N Mi Laboratory Observation Event Lifetime Laboratory Observation Event Comprehensive. Also, narrative is incorrect, should talk about all 9 possible state transitions that are supported.

The confirmer and confirmation receiver roles contain all state transitions and should therefore not be classified as Lifetime. Note that Tracker and Notifier for these only contain Abort and Activate. I believe this is by design.

Defer

VL 54 AR 3.18-3.21

POLB

N Mi Narrative is incorrect since it includes completion state transition. The completion state transition is not part of any of the lifetime roles in P&O except for those that are "Comprehensive" as described above.

Accept

VL 55 AR 3.22-3.25

POLB

N Mi Laboratory Observation Nullification Narrative is incorrect - should only talk about nullifying and reactivating.

Also: Link to interaction lists don't work. I do not believe these roles are in the 9.1 interaction index. Should these roles support reactivate? Nullification shouild have a single meaning across all P&O - either just the nullify event (another role added to support reactivate if necessary) or always nullfy AND reactivate.

reject

VL 56 AR 3.26-3.27

POLB

A S Nullification Narrative is incorrect - should only talk about nullifying and reactivating.

Also:These support reactivate - should they?

Defer

VL 52 AR 3.6 - 3.13

POLB

N Mi Laboratory Observation Complete Laboratory Observation Basic The term complete is incorrect. Basic should be used. In addition, the link to the interaction list does not work and the interaction indexes do not contain these application roles.

Defer

VL 59 TE 4.x POLB

N Mi Order Confirmation events These should be removed - for lab, confirmation triggers apply to events and intents only.

Defer

VL 77 TE 4.x POLB

A Q Complete Order Why isn't there a complete order event? Defer

VL 60 TE 4.x, 8.x POLB

N Mi Ambiguity between occurrences and complex orders

Lab does not have an unambiguous was to send an event for a specific occurrence of a scheduled lab observation as pharmacy does (Scheduled Administration messages). These additional trigger events should be added to ensure a more plug and play nature to V3. I would suggest names like "Scheduled Lab Observation Occurrence"

Defer

DM 4 DM 5 (also all RMs in 6)

POLB

N Mj Representation of containment within the messages seems insufficiently expressive. The A_Observation_event as understood from the ballot pack represents at least three different concepts.1) An investigation “result item” for which there is a result represented as a value (e.g. a quantity)2) A group of investigation result items such as a “battery”.3) A “report” of a set of results of various investigations or batteries for a particular patient.See details in attached document V3Ballot_ContextComment.doc

Defer

VL 85 DM 5, 6.x POLB

N Mi AR_Observation_step I object to this being used both to support components of a complex order/battery and occurrences of an order (perform today, perform tomorrow). It should only refer to components of a complex order. These could have a timing relationship (today do the widget, tomorrow do the wudget). A separate RMIM and separate events should be provided to support the transmission of individually timed occurrences. In addition, a separate application role would need to be specified to support sending and receiving at the occurrence level.

DN 86 DM 5.1, observation event

POLB

A T See the discussion under Order/Intent above.

See the discussion under Order/Intent above. In this case, the value of the attribute must be “EVN”-event.

reject

VL 86 RM 6.x, 7.x POLB

N Mi Status_cd, id, cd For each HMD, if the status changes, the constraints should specify the resulting status_cd (for example, on an abort event, status_cd = ABORTED). The HMDs should also explicitly state whether the id or cd can be changed as a result of the event or not. Abort and Revise do not change id, but Replace can change both id and cd. Replace also has the concept of old act/new act similar to a merge in V2. The other events do not. Based on the variety of constraints based on trigger event, there may evenm be a need to have RMIMs specific to event to make these constaints obvious to the reader. I do not find the HMDs nearly as readable as the RMIMs.

Reduce optionality and ambiguity. This applies to pharmacy as well.

Accept

VL 88 RM 6.x, 7.x POLB

N Mi AR_Intent_Replacement, AR_Event_Replacement

These should only be available on the replace event. I think an RMIM per event would be more concise - at least the replace event should have its own RMIM.

Reduce optionality reject

VL 82 HD 7.x POLB

N Mj R_Patient, etc. Message types for a specified HMD appear to be exactly the same at least in the table view. It appears that the tightly versus loosely coupled differentiation was not followed through. This applies also to shared and to pharmacy.

Accept

VL 63 IN 8.71, 8.72, 8.77, 8.78

POLB

N Mi For the receiving roles for order fulfillment requests, there are actually three possible receiving roles: Rejector, Fulfiller by Event, Fulfiller by Intent. This needs to be expressed more clearly. In addition, for each of these, there is a simple role and in some cases a "Comprehensive" role that could apply. This should be explained clearly. The concept that orders can be rejected at the order level and fulfilled by an intent or an event is very hard to find in the standard and should be clearly explained in introductory narrative.

Defer

VL 62 IN 8.9, 8.10, 8.13, 8.14

POLB

N Mi Lifetime application role Basic application role Lifetime does not contain complete. Also, simplest possible role should be specified.

Defer

DN 63 ?? All POLB

N Mi Duplication of participations b etween Control Event Wrapper and Lab messages.

Accept

DN 1 MT PO - Laboratory Section 5.1 and elsewhere

POLB

N Mi Should the AR_Encounter.type_cd on A_Observation_event (POLB_RM004000) be PERT, rather than COMP? COMP implies that an encounter is composedof (among other items) this lab observation. PERT seems more likely.

reject

DN ### ?? RIM/USAM clarifications needed from MNM:

POLB

A Q observation - We aren't clear what HL7 meant by suspend in the event mood.Context for this issue: We understand suspending an intent and suspending an order but not suspending an event in observation specialization.

DN ### ?? RIM/USAM clarifications needed from MNM:

POLB

A Q observation in event mood.In terms of observations, the revise vs. replace paradigm is not clear. Is it, as it seems a matter of business rules at an implementation? I.e. For some applications, the state transition of revise active might be valid, for others the transition of revise completed might be valid, and for others, only a two-act event payload is possible, with the target act replacing the source act, and the target act ending up in active or completed mood, while the source act should probably go to nullified. a correction.

DM 11 DM POLB

N Mj A "certainty_cd" attribute should be added to the RIM class Observation. The current

embedding of this in value or other data types is unsatisfactory, over complex and not applicable to all situations in which certainty is a relevant attribute of an observation.The absence of a "certainty_cd" attribute in the RIM class Observation causes a problem for representation of a coded "possible diagnosis" in the clinical information associated with a request. This is a more significant problem for clinical data in a electronic record.

DM 12 DM POLB

N Q It is not clear how a distinction is made between the status of a reported event (i.e. an interim result) and the effective status of the communicated information. For example, it is possible to communicate a lab result item for the first time and it is possible to update that result item. However, in either of these cases the status indicating it is "complete" or "active" (indicating that it is an interim result). It seems that only one of these can be readily communicated in status_cd.

Defer

DM 13 DM POLB

N Q How are factors such as "fasting" applied to an "A_Laboratory_Observation_order" or "A_Laboratory_Observation_order"? It is clear that substance administration can be used for many such factors but "fasting" is a lack of administration and some other factors are unrelated to adminstration (e.g. post-excercise). Further more even where a substance is administered the relevant time

Accept

is often relative to the investigation time rather than an absolute time (e.g. 30 minute post glucose load). How is this represented in the current model.

MW CL008

RM 6 PORX

N Mj As with the LAB models, in the pharmacy RMIMs, there appear to be overlaps between the Substance Order Intent participations and act relations and the Controlled Event Wrapper. The proper course for message implementers needs to be explained.

DN ### HD 7.1 PORX

N Mi no vocab links for CNE domains ParticipationSignature and RelationshipConjunction

VL 75 AR 3.x PORX

N Mi All "Complete" application roles Should be changed to "Basic" application roles. In all these cases, the link to the interaction index does not bring up a list of associated interactions. Links to interaction index should be fixed.

Defer

VL 76 TE 4.x, 8.x,5, 6

PORX

A S Complete Events It seems that more trigger events and interactions are needed to support important state transitions on pharmacy events (mood = EVN). In specific, at least Nullify and Revise and Replace should be supported. This change would also impact the DMIM and RMIMs which now show events with status_cd = COMPLETED.

Defer

DM 5 DM 5 (also all RMs in 6)

PORX

N Mj There does not appear to be an appropriate grouping container to allow representation of a prescription. In the UK sense this is a set of orders applicable to one patient that are logically and/or physically ordered in a single composite act. This is essential for support UK electronic prescribing. It impacts the entire model and associated

Defer

validation of the message since the composite is associated with a patient and the prescriber, dispenser etc. Thus there is no requirement for these associations at the individual item order level. See also the more detailed discussion of context attached.

VL 80 RM 5, 6 PORX

A S P_Subject P_Patient Clearer and more consistent with lab. Defer

VL 81 RM 5, 6 PORX

A T Supply_event id is missing - why? In at least some cases, should it be required?

Defer

AK AJK043

DM 5.1 Pharmacy D-MIM (PORX_DM000000)

PORX

A Q The following was a question from the first ballot: "Why is the cardinality to P_subject 1 to many rather than just 1 to 1? Wouldn’t you need to specify a distinct order for each subject?" The question remains unanswered.

AK AJK045


PORX

N Mi In the D-MIM diagram, it is unclear what Acts the "AR_Dispense_instructions" is creating a relationship between. It's just hanging out there in the middle, unattached to any specific acts.

Accept

VL 79 RM 5.1, 6.x PORX

A S R_Assigned_Practitioner_or_Device Create a CMET with choices to support the various options

Defer

VL 87 RM 6.x, 7.x PORX

A S id This is not required - why? Reduce optionality Defer

VL 89 RM 6.x, 7.x PORX

N Mi AR_Instantiation, AR_Encounter Whether or not applications share master files is a common negotiation issue. Should there be a concept of loosely and tightly coupled applied here. That is, a way to determine up front whether DEFs will need to be passed with the order, intent, event? IOn a similar note, all the RMIMs show the encounter as identified - is there ever a case where two applications want to share information and the encounter is not identified and more info about the encounter is required? It would seem that in the loosely coupled case, this may be true.

Reduce optionality - this applies to lab and shared as well.

Reject

VL 83 HD 7.x PORX

N Mi Message types for community versus institution appear to be the same - if there's no difference in the data, why have different message types?

DM 9 ?? General PORX

N Mj As discussed on list, the terminology is not helping us in sorting through the valid from the redundant. For example: Combined Pharmacy Intent Complete Active Informer Community Tightly-coupled (PORX_AR003813)Structured Name: Combined Pharmacy Intent Complete Active Informer Community Tightly-coupled An application that is capable of notifying another system about the completion of a commitment for a administration and dispensing of a drug or similar therapy. The application is designed to work in an environment that is community-based (rather than institutional) and does NOT assume a common or shared repository of

Defer

patient, provider and similar information. What on earth is the "completion of a commitment"? Surely this is notification of a supply event?The level of uncertainty about these issues that still exists (witness the current threads in O&O and Pharmacy) merits a negative ballot in its own right

DM 10 DM General PORX

N Mj Assumptions about vocabularies made in many of the coded elements in pharmacy assume particular vocabulary structues some of which do not exists and some of which from a UK perspective would be liable to conflict with NHS terminology and drug dictionary developments. It seems likely that this will cause significant difficulties in localisation.

Defer

DN 11 ?? Practice PORX

N Mi 3.1. Act.effective_time is GTS in RIM but e.g. TS in PORX_MT004403, line 5, and IVL<TS> in PORX_MT004403, line 147, and in many other places. 3.2. Act.activity_time is GTS in RIM but sometimes IVL<TS> in HMDs. 3.3. Participation.time is IVL<TS> in RIM but sometimes GTS in HMDs.

Defer

SB HD PORX

N Mj I disagree with treating a drug in two different ways – as both an Act and an Entity. In addition, it is not clear when a drug is to be treated as an Act vs. when it is to be treated as an Entity. I believe that a drug is an entity and is separate from the act of administration of the drug.

Defer

SB HD PORX

N Mj A number of attributes, most importantly the ‘form’ attribute (OrderableDrugForm vocabulary table), are not included when the drug is treated as an Act (PORX_DM000000) but are included when it is treated as an Entity

Defer

(COCT_DM2300000). It seems odd that this information would not always be needed.

SB HD PORX

S ClinicalDrug vocabulary table is not populated. It would be helpful if this could be provided (I am aware that the committee has been working diligently on this issue).

Defer

SB HD PORX

N Mj I struggle with the idea of Route of adminstration being treated as an Act, which does not seem correct. I would like to understand this modeling. I would also like to reiterate previously expressed reservations about the modeling of Route of adminstration - issues include apparently incorrect groupings (e.g., intraocular is not a form of topical application), mixing of methods and routes (e.g., 'instillation, rectal tube' or even 'intravenous infusion'), and ambiguous distinctions ('swish and swallow, oromucosal' vs 'swallow, oral').

Defer

SB HD PORX

Q There is a D-MIM called A_Observation (COCT_DM1200000) that has a definition of “Completely specifies an observation, clinical procedure or clinical medication.” I am unclear how ‘clinical medication’ is involved. In addition, there is no D-MIM diagram – instead there is a Note that says “Refer to the Observation D-MIM for the derivation of this C-MIM)”, but there is no indication as to where to find the Observation D-MIM.

Accept

SB HD PORX

In the Combined Pharmacy Proposal R-MIM, it appears that observations such as body weight, surface area, allergies, and medical conditions are related to the

Accept

substance administration act, but they are separate from (and not linked to?) the patient (P_Subject) to whom they apply.

VL 92 RM 5, 6 POXX

A S id, cd State that these cannot be changed on the message

Accept

VL 90 RM 5, 6, 7 POXX

N Mi Class_cd = OBS Class_cd should = Act or OBS+SBA_DM Accept

VL 91 RM 5, 6, 7 POXX

A S Status_cd Status_cd = Suspend+Resume+Nullify+Abort

AK AJK046

DM 5.1 Shared Interactions D-MIM (POXX_DM000000)

POXX

N Mi The D-MIMN shows A_Act with a class_cd of OBS. Shouldn't this be ACT? These messages get used for more than just Observations. Ditto for A_Act_master and A_Act_intent.

AK AJK MT 7.1 POX N Mi The message types POXX_MT001101 and Accept

047 Generic Status (POXX_HD001100)

X POXX_MT001102 appear to be duplicates. There appears to be no distinction between tightly and loosely coupled messages.

DN ### ?? Practice POXX

N Mi The supply act specialization of DIET has a corresponding “food” entity.classCode. However there is no entity.cd domain for “food” at the entity.cd level.

Defer

BK 3 AR POLB

N Mj The proposed hierarchy of application roles (basic, lifetime, etc.) causes the number of roles to increase way above any desirable limit. Most roles are only related to a single interaction, making a mockery of the concept of application roles. Given the 6 role prototypes, combined with loosely/tightly coupled variants, there shouldn't have been more than about 30 roles. A more balanced -business rule based- grouping of interactions seems to be required.

Defer

BK 4 IN POLB

N Mi Apart from references to roles. Defer

BK 5 AR PORX

N Mj The proposed hierarchy of application roles (basic, lifetime, etc.) causes the number of roles to increase way above any desirable limit. Most roles are only related to a single interaction, making a mockery of the concept of application roles. A more balanced -business rule based- grouping of interactions seems to be required.

Defer

BK 6 RM 6.1 POLB

N Mi mood-cd <= INT mood-cd <= ORD In POLB_RM004000 in A_observation_order_reference.

Accept

BK 7 RM 6.2 POL A S Mood code Intent is used for an order that

B was ´accepted´ by the filler. This seems to be inconsistent with the definition of this mood code as a general descriptor for intended Acts. Perhaps a separate mood code Accepted Order is needed, just as there is Appointment Request and Appointment.

BK 1 ST POLB

N Mi No interactions listed, identification of roles in storyboards erroneous or insufficently detailed.

Defer

NA 2 How is a comment about the specimen attributed against the specific specimen in order to preserve the context? The current structure only seems to allow this information to be conveyed as a text comment within an observation event which seems inappropriate if the context is to be preserved.

Defer

NA 1 N Mi For some messages, although they are transmitted from one computer system to another, the content is intended to be read by a specific recipient. The intended recipient may or may not be the same person as the requester. Is there an already existing container for identifying the recipient? Also, how are copy (of report) destinations to be identified in an order?

Defer

BK 8 ST 2.2 Diagram

POLB

A Q Why is the Request Response sent to the Lab Order Requester in this picture, while in other storyboards the message is sent to the Order Tracker?

Defer

BK 2 ST POLB

A Q Is it possible to add links from the storyboard to the triggers?

MW CL001

?? 1.1 H&CM

N Mi The Health and Clinical Management introduction should indicate the overall scope of expected domains. At least a little more is needed.

Accept

MW CL009

RM 5, 6 Phar A S I had thought there were to be descriptions of the RMIMs or of the DMIM. There are no descriptions included, but having them would be very useful.

MW CL004

DM 5 POLB

A S Regarding the DMIM, I had thought there was to be a DMIM description, but don’t see one. As the drafter of some material, I am also surprised not to see it. Some description of the model elements would be very valuable.

VL 1 IN 1 POLB

Workflow includes ability of service provider to accept, modify, or reject an order, with appropriate intent indication to the orderer. Modification may include breaking a parent order into child orders or work items Modification may include substituting a particular test Available/orderable Laboratory services may be described by an act in definition mood.

The order fulfiller (laboratory) can accept, modify, or reject an order, with appropriate intent indication to the orderer. The fulfiller can also break a parent order into child orders, substitute a particular test, or add tests (reflex orders).

Numerous typos. Unclear meaning of the paragraph - ambiguous. I tried to write what I think it meant. Also, reflex orders should be mentioned. As far as I can tell, this domain is not used to communicate acts in definition mood except in relation to the act in either order, intent, or event mood so that part is confusing - suggest leaving it out.

VL 6 ST 2 POLB

N Mj All domain Interaction diagrams Interactions should exactly match the interaction names defined in the domain's

This will allow the reader to tie real life scenarios to the interactions in V3.

Defer

interaction section.

VL 7 ST 2 POLB

S All domain Interaction diagrams The concept of interaction is somewhat detailed at this point when reading the domain. An alternative that should be considered is using the trigger event here. A trigger event might represent a more understandable level of abstraction.

Defer

VL 8 ST 2 POLB

N Mi All domain storyboard narratives At each point in a narrative where a message would be transmitted, the exact interaction name as well as its instance of use in the storyboard (v1.1, v1.2 when two results messages are sent) should be specified.

This will allow the reader to understand the relationship between the narrative and the interaction diagram.

Defer

VL 9 ST 2 POLB

N Mi All domain storyboard narratives When an application is referred to in the narrative, the same application should appear in the interaction diagram. All applications referred to in the interaction diagrams should also be referred to in the storyboards.

Defer

HF ST 2.1 POLB

N Mi e.g. Lab Order Requestor Loosely Coupled e.g. Lab Order Placer Loosely Coupled The names of the application systems should use the same terminology as the Application Roles in the documenetation to make it easier to follow and understand the storyboards

Defer

HF ST 2.1 POLB

N Mi e.g. Request for Action, Lab Order 1 e.g. Lab Order Activate, Fulfillment Request 1

The names of the interactions used on the diagram should be consistant with the interaction names in the documentation to make it esier to understand what messages are being sent

Defer

VL 10 ST 2.1 POLB

A T Several storyboard narratives refer to "closely coupled" applications

replace with "tightly coupled" Defer

VL 11 ST 2.1 POL A S Clinic Application Clinic Order Entry Application For consistency with the narrative Reject

B

VL 12 ST 2.1 POLB

A S Draw dotted lines around role for reference lab application and call it "Reference Lab Application." Draw dotted lines around role for public health application and call it "Public Health Application"

Reject

VL 29 ST 2.5 POLB

N Mi Tracker, closely coupled Laborarory Observation Event Tracker, Closely Coupled, Laboratory Observation Intent Tracker Closely Coupled

VL 33 ST 2.7 POLB

A T Interaction List Should not be there - leftover from ballot 1. Accept

HF AR 3 POLB

N Mi The application roles descriptions do not help much in understanding what this role is used for. Each role description is not much different to the others and shows that these have be developed mechanically rather than think about the end users usability. Half of the description explains the definition of loosely or closely coupled systems which is duplicated in every description. This should only need to be defined once.

Defer

HF AR 3.1 POLB

N S Suspension: This application role is capable of dealing with the temporary de-activation of an act. (For example, temporarily stopping a test, placing a prescription on hold). The application is also capable of dealing with the re-activation of the act.

Suspension: This application role is capable of dealing with the temporary de-activation of ('Suspend') an act. (For example, temporarily stopping a test, placing a prescription on hold). The application is also capable of dealing with the re-activation of ('Resume') the act.

It would be helpful to use the state transition names used in the Act state-machine diagram in the suspension definition as is done with most of the other definitions

Accept

VL 35 AR 3.1 POLB

A T Tightly-coupled and oosely-coupled applications.

Closely-coupled and Loosely-coupled applications

Accept

VL 36 AR 3.1 POLB

N Mi All Application Roles defined in Practice and Operations make use of 6 common stereotypes, and share a common hierarchical approach. They also make use of a distinction between Tightly-coupled and oosely-coupled applications.

All Application Roles defined in Practice and Operations make use of 6 common stereotypes, and share a common hierarchical approach based on state transitions supported. They also make use of a distinction between Tightly-coupled and Loosely-coupled applications. For pharmacy, an additional distinction is made based on whether the application is community based (local pharmacy) versus institutional based (hospital pharmacy).

Defer

VL 37 AR 3.1 POLB

N Mi The hierarchy of application roles is based on the Act state-transitions. At present, Practice and Observations deals with the following state transitions: Activate, Suspend, Resume, Abort, Replace (a ombination of 'Obsolete' and 'Activate'), Complete and Re-activate. These states have been placed into a hierarchy representing what an application is capable of. The hierarchy is as follows:

The hierarchy of application roles is based on the Act state-transitions. At present, Practice and Observations deals with the following state transitions: Activate, Suspend, Resume, Abort, Replace (a ombination of 'Obsolete' and 'Activate'), Complete and Re-activate. These states have been placed into a hierarchy representing what an application is capable of. The hierarchy is as follows:

Accept

VL 39 AR 3.1 POLB

N Mi Lifetime: This application builds on the Basic role, but adds the concept of an Act having a perod of existance, from the time it begins (or becomes effective) and the time it ends. Application supporting his role add the transitions of Activate (meaning the act has begun/become active), and Abort (meaning that the act has been prematurely terminated.) The following Application Roles all build upon the lifetime Role. They each require that the application have a concept of lifetime. A system may mix and match more than one of these roles, depending on its capabilities.

Lifetime: This application builds on the Basic role, but adds the concept of an Act having a perod of existance, from the time it begins (or becomes effective) and the time it ends. Application supporting this role add the transitions of Activate (meaning the act has begun/become active), and Abort (meaning that the act has been prematurely terminated.)

VL 40 AR 3.1 POLB

N Mi Suspension: This application role is capable of dealing with the temporary de-activation of an act. (For example, temporarily stopping a test, placing a prescription on hold). The application is also capable of dealing with the re-activation of the act. This level does not deal with any transitions involving the 'new' state (which represents an Act that is still being edited and is not yet 'active').

Suspension: This application role is capable of dealing with the temporary de-activation of an act (suspend state transition) . (For example, temporarily stopping a test, placing a prescription on hold). The application is also capable of dealing with the re-activation (resume state transition) of the act. Applications supporting this role must also support both the Basic and Lifetime roles.

VL 41 AR 3.1 POLB

N Mi Nullification: This application role is capable of dealing with the idea that a particular action may have happened in error and may need to be reversed. This is supported by two state transitions - ullification which causes the act to be treated as if it never really existed and Reactivation which allows an Act that had been marked as completed to be re-transitioned to the Active state.

Nullification: This application role is capable of dealing with the idea that a particular action may have happened in error "this never happened" (nullify state transition). It builds on the Basic role.

VL 45 AR 3.1 POLB

N Mi Informer: An application that is capable of notifying another application about a significant event (the status change of a focal class)

Informer: An application that is capable of sending messages to another application but does not require the receiver to perform any action.

VL 46 AR 3.1 POLB

N Mi Tracker: An application that is capable of receiving information about a significant event (the status change of a focal class), but is not expected by the receiver to perform any action.

Tracker: An application that is capable of receiving messages, but is not expected by the sender to perform any action.

VL 47 AR 3.1 POLB

N Mi Placer: An application that is capable of notifying another application about a significant event, and DOES expect the receiver to take action.

Placer: An application that sends requests to another application and expects the other application to fulfill the requests. An application that supports this role will most likely also support the role of Confirmation Receiver so that it can receive confirmations of the fulfillment requests from the fulfiller.

VL 48 AR 3.1 POLB

N Mi Fulfiller: An application that is capable of receiving a request from a Fulfiller application.

Rejector: An application that is capable of receiving a request from a Placer application and is capable of rejecting them. An application supporting this role will most likely support the Fulfiller role so that it can also accept requests for fulfillment.

VL 49 AR 3.1 POLB

N Mi Confirmer: An application that is capable of accepting a request from a Fulfiller application.

Fulfiller: An application that is capable of accepting and fulfilling a request from a Placer application Applications supporting this role will most likely also support the Rejector role so that it can also reject fulfillment requests if necessary.

VL 50 AR 3.1 POLB

N Mi Confirmation Receiver: A role implemented by a placer indicating what types of confirmations it accepts.

Confirmation Receiver: An application that is capable of receiving confirmations of fulfillment of requests. This si a role most likely implemented by an application that also supports the Placer role. It allows the Placer to receive confirmation of its fulfillment requests.

VL 84 RM 6.1 POLB

A T txt: describes intent .

VL 95 HD 7 POLB

N Mj Examples The examples provided for the HMDs do not have enough detail or context to be useful - having good working examples of the critical scenarios and complex scenarios is critical to readability, implementability, and success of V3. I recommend examples that tie in with the storyboards so the reader can follow through from high level concept through implementation.. Certainly complex orders (CBC), micro results, and reflex orders need to be shown.

This applies to pharmacy and even tp shared as well.

HF HD 7.2 POL N Mj <value xsi:type="CD|CE|ED|GTS|INT|MO| <value xsi:type="REAL">2.2<value/> example message provided

B PQ|REAL|RTO|ST|TS" nullFlavor="NI"/> (POLB_EX004401.htm) is fairly useless when it can not demonstrate the usage of the key attributes (Observation Value) properly. It had a null value which is very unlikely and is did not contrain the node type at the message level as it should.

HF ST 2.1.1 POLB

N Mi Scenerio hard to follow on the diagram and some interactions on the diagram are not discussed in the scenerio. The scenerio and diagram should be consistant to help understanding

VL 13 ST 2.1.1 POLB

N Mi "Lab Order Requestor, Loosely Coupled" under Clinic Application

"Laboratory Observation Order Lifetime Placer, Loosely Coupled"

This is one example of an application role matching a role from the application role section.

VL 21 ST 2.1.1 POLB

A S Sara Specialize Example name for a pediatrician (such as Peter Pediatrician)

To improve readability.

VL 24 ST 2.2.1 POLB

A S DIC Explain the acronym

VL 27 ST 2.4.1 POLB

A T receving receiving

VL 30 ST 2.6.1 POLB

A S Dr Sara Specialize Example name for Obstetrician

VL 31 ST 2.6.1 POLB

A S The combination of the vomiting, possible hypothyroidism, and anemia with her pregnancy and diabetes leads Dr. Specialize to immediately admit Eve to University Hospital, an 840 bed teaching hospital not far from her office, where she is on staff.

The combination of the vomiting, possible hypothyroidism, and anemia with her pregnancy and diabetes leads Dr. Specialize to immediately admit Eve to University Hospital.

Improve readability of the storyboard.

VL 32 ST 2.6.1 POLB

A S The phlebotomist returns to the lab and the processing team swings into action.

Boris Bleeder returns to the lab and the processing team swings into action.

Sounds more fun.

VL 34 ST 2.7.1 POLB

A S After entering the order a nurse will collect the urine and perform a phlebotomy.

After entering the order, Nurse Nightinggale collects the urine and blood specimens.

DN 35 AR 3.1, 2nd para

POLB

A T oosely loosely

VL 57 AR 3.x POLB

N Mj 1) Links for many of the confirmation/confirmation receiver roles don't work. 2) A majority of the narratives are exactly the same and say that the role supports all state transitions (ie: An application that is capable of accepting a confirmation from a system that has agreed to perform the actions necessary to deal with the issuing, discontinuing, completion, deletion (I.e. 'this never really existed') and restarting of a previously completed of a laboratory observation. ) - these need to be rewritten to apply to the specific role. 3) each Lifetime role should be checked to ensure that it only supports Abort and Activate. Otherwise the name should be changed to Comprehensive. 4) Each nullify role should be checked to see if it supports reactivate and separate roles then created for nullify versus reactivate. 5) All roles named "Complete" should be changed to "Basic" - there are many occurrences of this.

AK AJK042

TE 4 - Trigger Events for POLB abd PORX

POLB

N Mj This applies to POLB and PORX. None of the trigger events that are state transition based have documentation on the actual state transition. The publication database was enhanced to allow this documentation.

JM 3-hk RM 5 Domain Message Information Models

POLB

N MI N/A N/A Add explanation how to read the DMIMs?

JM 4-hk RM 6 Refined Message Information Models

POLB

N MJ N/A N/A Other than the entry point to RMIMs there is no description of how the RMIMs have to be navigated in order to derive the messages. That is what makes it difficult to understand the RMIMs because there is another level of indirection through the HMDs.

JM 6-hk IN 8 Interactions

POLB

N MI N/A N/A Graphical overview of interactions needed because of the sheer number of interactions.

VL 65 IN 8.71, 7.72, 8.77, 8.78

POLB

A S Indicates that the request has been accepted, and provides the resulting event

Indicates that the request has been accepted, and provides the resulting event (fulfillment by event)

VL 64 IN 8.71, 8.72, 8.77, 8.78

POLB

A S Indicates that the request has been accepted and provides details of the plan to fulfill it

Indicates that the request has been accepted and provides details of the plan to fulfill it (fulfillment by intent)

DM 6 ?? 1 PORX

N Mj The Introduction and Scope section needs to reference the real world process of 'prescribing' somehow, not just 'pharmacy orders'. The struggle between the terminology used to describe the linical process and the terminology used in the message development process need to mesh

somewhere, and if the introduction doesn't use some words we recognise, we're in real trouble.

VL 66a ST 2 PORX

A S Storyboards Storyboards should be reviewed to ensure that each of the major categories (Combined pharmacy, pharmacy admin, supply, scheduled admin, and scheduled supply as well as proposals) are demonstrated.

VL 68 ST 2 PORX

A S All domain Interaction diagrams Application roles should exactly match those defined in the domain's application role section.

This will allow the reader to tie real life scenarios to the application roles used in V3.

VL 69 ST 2 PORX

A S All domain Interaction diagrams Interactions should exactly match the interaction names defined in the domain's interaction section.

This will allow the reader to tie real life scenarios to the interactions in V3.

VL 70 ST 2 PORX

A S All domain Interaction diagrams The concept of interaction is somewhat detailed at this point when reading the domain. An alternative that should be considered is using the trigger event here. A trigger event might represent a more understandable level of abstraction.

VL 71 ST 2 PORX

A S All domain storyboard narratives At each point in a narrative where a message would be transmitted, the exact interaction name as well as its instance of use in the storyboard (v1.1, v1.2 when two results messages are sent) should be specified.

This will allow the reader to understand the relationship between the narrative and the interaction diagram.

VL 72 ST 2 PORX

A S All domain storyboard narratives When an application is referred to in the narrative, the same application should appear in the interaction diagram. All applications referred to in the interaction diagrams should also be referred to in the storyboards.

VL 78 DM 5.1 PORX

N Mj DMIM narrative There is no substantial narrative explaining the pharmacy DMIM. One should be provided with explanations of all the classes, attributes, act relationships, and participations. It should be analogous to the one provided for lab.

VL 93 DM 5, 6 PORX

A S P_Responsible_Participants = ASS+… I just can't seem to get comfortable with assistents being called "ASS", especially since one may be handy with computers and see their name associated with ASS in the XML.

AK AJK044


PORX

N Mj The description section of the Rx D-MIM is inadequate. It should have a description similar to the one for the Lab D-MIM.

AK DRY003

ST PORX PORX

N Mj Many storyboard ladder diagrams are still missing. Clumping the diagrams together rather than under their respective storyboard scenario is confusing.

AK DRY002

AR PROX PORX

N Mi The Application Role Names are not informative. Could there be a more normalized short name under which the long name and full description could be found? For Example Administration System Roles under which you find the longer names of Combined Pharmacy etc....

VL 97 HD 7 XXXX

N Mj Examples Real examples that implement read world events are needed and those that illustrate complex constructs within V3. At least some of the storyboards should be follow through with examples that implement the storyboard or parts of it.

This applies to all domains

VL 14 ST 2.1.1 A S Automated Microbiology Reflex Tests Microbiology Reflex Tests Since the storyboards are sorted in alphabetical, not logical order, this very complex one sorts to the top. If "automated" is removed, simpler storyboards will appear first, improving readability of the section.

VL 17 ST 2.1.1 A S technician laboratory technician Bill Beaker use the example names whenever possible - they really improve the readability of the storyboards.

VL 18 ST 2.1.1 A S microbiologist use an example name that implies microbiologist. I am not sure if there is one in the example name list. If not, I would recommend Oliver Organism, Carla Culture, or Ike Isolate.

Example names greatly improve the readability of the storyboards.

VL 20 ST 2.1.1 N Mi Dr. Patricia Primary alters her therapy. Dr. Sara Specialize alters her therapy. Karl Kidd was never seen by Patricia, only be Sara. Actually, this storyboard would be clearer with a pediatrician example name instead of Sara Specialize (for example Peter Pediatrician).

GD 8 General Comment - Gap Analysis

n mj Correlate responses for ISO 18307 with gaps identified in Chapter 1 of previous v2.x versions. See v2.4, Section 1.8 (was Section 1.7 in previous versions). Describe how HL7 v3 (and/or companion standards) will ultimately close identified gaps. Include gap analysis in v3 Introductory.

DM 2 MT Various tabular view

N Mj The addition of the tabular view is welcome. This is the form that vendors in the UK have indicated a preference for use at the detailed implementation level. However few of the rows have explanatory text. All rows should have text even where this is a common default applying to various occurences of the same attribute. Until all rows have text we consider it is difficult to be certain of the intent of the authors of a message type as to the precise usage of the attribute in given situation.

Thus a meaningful affirmative ballot will not be possible until this is achieved.

DM 3 MT Various tabular view

N Mj All rows in tabular representation have forms like: "[1..1] class_cd , Act , class_cd , D , ( CS ){ CNE: ActClass }"

All rows in tabular representation should have forms like: "[1..1] class_cd ( CS ){ CNE: ActClass }"

Th additional information relating to derivation from RIM etc is superfluous here and makes the tabular view much less readable.

VL 38 AR Basic:…. Basic: Supports transmission of completed Acts. This is the basic building block in the role Hierarchy. Applications supporting this role may also need to support the Lifetime, Suspension, Revision, Replacement, Nullification, and/or Reactivation Roles.

DM 14 DM N Q Where SET is specified as in SET<II> does a cardinality of "[1..1]" denote one instance of the SET or one member only in the SET? If the former then how is the number of members in a SET constrained? If the latter then if [1..1] SET<II> any different from [1..1] II ?A clear answer to this is important to determine whether these models meet our needs to have in some cases one or two (but no more) identifiers of a particular Observation.

DH The static model is inadequately explained and Interactions and Application Roles are numerous and difficult to understand within a domain (particularly for Pharmacy, but also for other domains)

DH Improve scope statement

DH The static model should be layered more to distinguish material intended for various usages eg message development usage, Business modelling usage etc. Some suggestions to improve the usability of the static model are provided.

DH Currently, the various functional domains, Pharmacy, patient Administration, etc each define a static model for a variety of subject classes. For example, patient Administration deals with Person management, Ambulatory encounters, Home health encounters, emergency encounters and inpatient encounters and participations. These subject classes must be dealt with separately, and this must be done in a hierarchy that describes the common features of the four encounter subject classes (common model) before dealing with their individual modelsSimilarly the Lab domain must be divided into orders management and results reporting which are dealt with separately.

MW CL003

AR 3 Lab A S In lab processing, there are too many application roles for this concept to have any value. This is an observation without a recommended solution, because the committee has faithfully followed the rules that were expressed, and because I don’t have a solution to recommend. However, it seems to me that this structure will not be maintainable. M&M needs to offer something more useful. Hopefully, lab developers can offer some potential solutions.

MW CL002

?? 1.1 P&O N Mi The Practice and Operations introduction should indicate the overall scope of expected domains. It would be nice if a little definition of the area could be

included. It would also be helpful if there could be some discussion of what is included in this ballot.

VL 4 ST 2 POLB

All interaction diagrams All Application Roles defined in Practice and Operations make use of 6 common stereotypes, and share a common hierarchical approach based on state transitions supported. They also make use of a distinction between Tightly-coupled and Loosely-coupled appl

VL 5 ST 2 POLB

N Mj All domain Interaction diagrams Application roles should exactly match those defined in the domain's application role section.

This will allow the reader to tie real life scenarios to the application roles used in V3.

VL 22 ST 2 POLB

A S Many of the storyboards claim to illustrate reflex orders.

To simplify the storyboards, the reflex order concept probably only needs to be represented once or maybe twice.

VL 28 ST 2.5 POLB

N Mi Draw dotted line boxes for Laboratory Application and Results Reporting Application

VL 26 ST 2.4.1 POLB

N Mi Variant 1 and Variant 2 are exactly the same

Make them different or remove one.

JM 1-hk AR 3 Application Roles

POLB

N MJ N/A N/A There is an extensive number of Laboratory Application roles. In my opinion this is a combinatorical explosion resulting from the combination of application roles in the proper sense with events, application role tasks associated with these events and IT infrastructure information (loosely vs. closely coupled repositories) -> I would recommend to reduce the number of application roles.

AK AJK041


POLB

N Mj This applies to POLB and PORX. The short and long names for trigger events are the same in this ballot. The short name was provided to give a common name for the artifact, making it easier for the reader to understand what the trigger event is used for.

VL 61 IN 8.x POLB

N Mi Ambiguity in Application Roles There is some ambiguity between application roles. All sending application roles should be set to the simplest role (one of Basic, Lifetime, Suspension, Nullification, Reactivation, Revision, or Replacement). However, for some interactions, Comprehensive is also a valid sending role. This should be expressed in some fashion, even if its in the introductory narrative.

Remove ambiguity. Note: This also applies to pharmacy.

VL 3 IN 1 PORX

N Mj In the introductory narrative as well as throughout the pharmacy section, the definition of community versus institutional should be clarified - in specific, what behavior on message information or constraints really make this communication different? Also, it was not clear in the pharmacy section that dispense == supply. This should be described up front and followed consistently throughout the section. In addition, it was also unclear the difference between combined pharmacy, pharmacy administration, and supply - this needs better up front definition. The introduction section should tie the purpose of the pharmacy section to the actual terms used to represent this messaging through out the section (also, it took a bit of reading to determine what scheduled administration was. The term scheduled through me off becuase I thought about scheduling things in advance). Diagrams showing the flow of orders, intents, dispenses, and administrations should be invaluable.

This applies to lab as well

VL 66 ST 2 PORX

N Mj Interaction Diagrams Most are missing - need to be added - all narratives should be changed to explicitely refer to the messages sent in the interaction diagram and the applications that are communicating as shown in the dotted lines of interaction diagrams.

VL 67 ST 2 PORX

A S All interaction diagrams Use of dotted lines around roles should be used consistently (no role should exist outside dotted lines). Names of applications represented in dotted lines should match storyboard narratives.

DM 7 ST 2 PORX

N Mj We have loads of storyboards in pharmacy now, but they don't actually tie up with our 829 Application Roles, 264 Trigger Events, 59 HMDs and 678 Interactions, so they're not really helping s very much. Until we can do this tie up, we cannot truly identify the redundancy that exists in stuff that has been generated (e.g. the ARs) by matrix process.

DM 8 AR 3 PORX

N Mj A total of 829 Application Roles are just too many to take in. Nobody's going to test conformance to this lot, or even a selection of this lot as it stands at the moment.I think the biggest general issue here is whether the distinction between loosely coupled and closely coupled systems is actually valid. If it is not, then we can automatically halve the number of things we need to worry about. I just don't know enough to comment properly, but I think that, when messaging between systems, one should assume nothing, thereby they are 'loosely coupled' by default. Then we go into the Placer/Confirmer, Fulfiller/Confirmation Receiver, Tracker and Informer type roles and there is yet more complexity that could be reduced.

VL 74 AR 3.x, 8.x PORX

N Mj Too many application roles and interactions for the implementor to pick from.

There are just too many application roles and interactions for the implementor to pick from. The chances that one would pick the wrong one are high, leading to a wide disparity of implementations. However, if a parametized approach is used or some easy formula is given up front and a person is navigated to the right role and set of interactions, the number of them would not matter so much. The number of roles and interactions appears to simply be a multiplication of some basic common criteria that should be made concise up front. The reader should only need the large list of roles and interactions as a reference list at the back.

This applies to lab as well

AK DRY001

AR PORX PORX

N Mi This has already been discussed but wanted to put it on the record that we need to review and probably limit the application roles to something more realistic to manage and understand.

VL 2 IN 1 Typical Interactions Remove this section or add more This list is very incomplete - there are more than one typical interaction. Better to just remove this part - storyboards will cover it.

VL 15 ST 2.1 N Mi This storyboard is trying to show too much The storyboard should be broken into two. The first storyboard should focus on microbiology cultures and sensitivities with no communicate with a reference lab or public health. A second storyboard could show communication to a reference lab and to public health (although their already is a storyboard that communicates a health outbreak).

This is the place one will read first to understand how to communicate microbiology orders and results - it should be kept as simple as possible considering the complexity.

VL 19 ST 2.1.1 N Mi LIS, hospital information system, clinic order entry system, satellite clinic information system, clinic system, laboratory information system, hospital clinic information system.

Pick one concise name for each of the applications and use it consistently through the storyboard and in the interaction diagram.

Improve readability of the storyboard.

HF AR 3.1 POLB

A This is an excellent overview of the application roles and the definitions used throughout the remainder of the document

DM 1 ?? ALL N Mj Given the size of the ballot pack and the limited possibility for informed review we suggest a change in the approach that limits the number of messages balloted at this stage to those for which there is a realistic expection of practical implementation either experimentally prior to ballot or within a specified period after a successful ballot. The rationale for this is as follows: Any interoperability standard requires implementation by at least two application providers. GIven that, why not introduce a rule that every balloted Interaction and Message Type needs at least two supporters who are going to implement it (and will feed back experience), plus a documented use case. A few dozen tested ones would be more useful than several hundred theoretical ones. A practical and pragmatic hurdle of this sort might provide a bottom up way of avoiding the combinatorial explosion problem. It would also ensure that we do not spend a lot of effort documenting artifacts that are neither based on practical experience nor likely to be used.

The smaller number of artifacts produced must all fit rigidly within the V3 architecture. The real benefit of using a comprehensive architecture like V3 is to allow consistent development over time, not "big bang". It will be a relatively simple task to add additional artifacts as needed based on the existing exemplars and architecture.Smaller discrete published standards would also allow a more effective ballot pool. We find ourselves casting negative ballots on general issues at this stage. In future the basis of a negative ballot could be a perception of a serious problem in one message while many messages in the same ballot might be of limited relevance to us.

MW CL007

DM 5 Phar N Mi When I try to bring up the Pharmacy DMIM, it doesn’t display.

JM 5-hk HD 7 Hierarchical Message Descriptions

POLB

N MI N/A N/A Grid views: definitions of column headings are missing. Table views: abbreviations (e.g. I, N) without explanation. Schemas: Multiple broken links present. Examples: Multiple broken links present. It is essential to have some typical examples and a walkthrough which shows how they are derived from the RMIM etc.

VL 98 XXXX

N Mj XML ITS I can't seem to find the part that explains how XML messages are derived from the HMDs as promised in the overview of the ballot. I need this information. I also need a high level overview to know that my encoding needs are addressed and that this is much better that V2 encoding. The V2.x XML document was easy to understand. In this one, I can't find what I need - perhaps its just missing completely. In the last version of the ballot, I had a really hard time understanding what it was saying. The XML ITSis a major selling point of V3 and it needs to be clearly documented.

VL 73 AR 3.1 PORX

N Mi Please see all my ballot items for lab on introductory application role - they all apply for pharmacy as well.

JM 7-hk ?? Pharmacy

PORX

N MI N/A N/A Same comments as for POLB

JM 1-cc ?? Ballot XXXX

N MJ N/A N/A While significant progress has been made, there is still too much ambiguity and uncertainty in the text and structure to consider this an implementable standard across all aspects. There needs to be at least one more round of creation and editing materials within the existing limited scope of Lab and Rx messages.

SR KP01

?? N Mi While there has been a vast improvement in the v3 content and presentation, there still appears to be a significant degree of disconnect between the v3 specification and how the specification will/can be

applied to real-life clinical situations. It is a formidable task to read and comprehend the v3 specification, but it is essentially self-consistent (albeit not always complete.) We believe that additional work is needed to assist the reader with the transition from specification to "reality." This may include:-further enhancing storyboards-in cases where roles, interactions, triggers, etc are derived from combination of orthogonal axes, include such in the narrative-in cases where roles, interactions, triggers, etc have hierarchical relationships, include such in the narrative-additional "real-world" scenarios (current scenarios are significantly better than the prior ballot, but additional scenarios will always benefit the reader.

We acknowledge that such changes are not possible without the participation of the HL7 membership, and we commit ourselves to that participation.

As we are not providing individual and specific examples, acknowledgment of our concerns and agreement to ongoing enhancements to the content will be sufficient for us to withdraw this negative ballot/convert our negative ballot to affirmative.

BK 1 ST POLB

N Mi No interactions listed, identification of roles in storyboards erroneous or insufficently detailed.

BK 2 ST POLB

A Q Is it possible to add links from the storyboard to the triggers?

AK AJK001

DM 5 Domain Message Information Models

COCT

A S This note is for publishing: Some of the diagrams in the CMET D-MIM section are illegible. In other sections, links are made to more legible diagrams, but not in this section.

AK AJK002

DM 5.13 A_Observation (COCT_DM120000)

COCT

N Mj The section references the LAB D-MIM, but I know the Lab D-MIM can't be used to derive things like intolerances at this time.

AK AJK003

DM 5.41 R_Specimen (COCT_DM080000)

COCT

N Mj In the previous ballot there were Major Negative votes on the Specimen CMET, indicating it was hard to understand certain parts of the CMET. Although the general text describing the CMET has been improved some from the last ballot, this CMET will benefit enormously from having a detailed textual description similar to what was done for the Lab D-MIM.

AK AJK004

RM 6.72 R_Reagent (COCT_RM250100)

COCT

A Q This question came from ballot 1 regarding the Reagent CMET: "How come there’s no little cd attribute in MM_Reagent? How do you know what the reagent is?" This question still appears to be unanswered.

AK AJK005

RM 6.17 A_Observation_dx_detailed (COCT_RM120100)

COCT

A Q The following was a question from the first ballot: "neither this CMET nor the Supporting Clinical Information CMET use the Act_relationship class. Does that mean that ALL complex diagnoses are supposed to use the Act.value? For example, we were recently asked guidance on how to represent things like “persistent neutropenic fever despite amphotericin”, “chronic, recurrent sinusitis with frontal sinus mucous retention cyst”." This question appears to remain unanswered.

AK AJK006

RM 6.70 R_Patient_identified (COCT_RM050200)

COCT

N Mj I believe we need to include the A_Observations_supporting CMET to this CMET. The reason being is that we will need to communicate information in this CMET for a patient whether or not we are tightly or loosely coupled. We need it in both cases.

AK AJK007

RM 6.20 A_Order_options_auto_repeat (COCT_RM210400) 6.21 A_Order_options_dilution_factor (COCT_RM210100) 6.22 A_Order_options_endo_conc (COCT_RM210200) 6.23 A_Order_options_reflex_perm (COCT_RM210300)

COCT

N Mi I don't understand why we ended up with 4 different order options cmet's. We now need to include 4 different CMET's in the Lab R-MIM's not one. The descriptions associated with each of these CMET's doesn't explain the purpose of the individual CMET.

AK AJK008

RM 6.19 A_Observation_supporting (COCT_RM120200)

COCT

N Mi This CMET should also include the following CMET's in the choice: 6.18 A_Observation_intolerance (COCT_RM120300), 6.17 A_Observation_dx_detailed (COCT_RM120100).

AK AJK009

RM 6.17 A_Observation_dx_detailed (COCT_RM120100)

COCT

N Mj The following was a Major Negative item from the first ballot: "The lower cardinality of P_responsible_parties should be 0 instead of 1. We don’t usually record this information when simply filling in the “indications” box when submitting an order". This still appears to be an issue with this CMET.

AK AJK010

RM 6.28 A_Transportation_clinical (COCT_RM060200)

COCT

N Mi I have several issues with the new transportation CMET's. The current CMET structure makes it difficult to determine exactly what's being transported, is it a person or a specimen? Because of the way the CMET is being used in orders, you can't tell from the context what's being transported either.

AK AJK011

?? POLB and PORX

POLB

N Mi Short names and long names appear to be the same through out the ballot. I believe this is really a publication issue, based upon feedback I've had from Helen Stevens, but I've added this as a negative ballot issue to make sure it gets resolved for the next ballot.

AK AJK012

?? POLB

N Mi ACT.priority_cd vocabulary is still missing. This was a negative ballot item on the previous ballot, and it’s still a negative ballot item.

AK AJK013

AR 3.1 Introductory Application Role (POLB_AR000000) 3.1 Introductory Application Role (PORX_AR000000)

POLB

A T Revision: This application is capable of dealing with changes to an act that do not require the assignment of a new identifier. (Different jurisdications may have different guidelines over what changes ay be made without requiring the creation of a 'new' act.).

Revision: This application is capable of dealing with changes to an act that do not require the assignment of a new identifier. (Different jurisdications may have different guidelines over what changes may be made without requiring the creation of a 'new' act.).

This applies to both POLB and PORX.

AK AJK014


POLB

A T Replacement: This applicatoin is capable of creating a new act that replaces an existing act. This is similar to a revision, except that a new identifier is assigned to the modified act.

Replacement: This application is capable of creating a new act that replaces an existing act. This is similar to a revision, except that a new identifier is assigned to the modified act.


AK AJK015


POLB

A T Nullification: This application role is capable of dealing with the idea that a particular action may have happened in error and may need to be reversed. This is supported by two state transitions - ullification which causes the act to be treated as if it never really existed and Reactivation which allows an Act that had been marked as completed to be re-transitioned to the Active state.

Nullification: This application role is capable of dealing with the idea that a particular action may have happened in error and may need to be reversed. This is supported by two state transitions - nullification which causes the act to be treated as if it never really existed and Reactivation which allows an Act that had been marked as completed to be re-transitioned to the Active state.


AK AJK016


POLB

A S This applies to both POLB and PORX. We have obviously identified a need to have some general introductory text for all Application Roles within a domain. We need to get with publishing to figure out how to get this documentation into the ballot without the subterfuge of using a "fake" application role.

AK AJK017

AR 3 - Application Roles for both POLB and PORX

POLB

A T Nullfication Nullification Nullification is misspelled throughout this section for both POLB and PORX.

AK AJK018


POLB

N Mi Fulfiller: An application that is capable of receiving a request from a Fulfiller application.

Fulfiller: An application that is capable of receiving a request from a Placer application.

This applies to both POLB and PORX. The definition of Fulfiller as given in the ballot is circular. I didn't know if this is just a typo, and it should reference a Placer instead of Fulfiller, or if this is what was actually meant, in which case it doesn't make sense to me.

AK AJK019


POLB

N Mi Confirmer: An application that is capable of accepting a request from a Fulfiller application

Confirmer: A role implemented by a fulfiller indicating what types of confirmations it can send.


AK AJK020


POLB

N Mi The roles of Placer/Confirmer and Fulfiller/Confirmation Receiver are very closely tied. All Placer applications must implement at least one Confirmation Receiver role for the same focal class. All Fulfiller applications must implement at least one Confirmer role for the same focal class. If this were not true, a Fulfiller would only ever be capable of rejecting a request. While this is easy to implement, the expected market for such an application is low.

The roles of Placer/Fulfiller and Confirmer/Confirmation Receiver are very closely tied. All Placer applications must implement at least one Confirmation Receiver role for the same focal class. All Fulfiller applications must implement at least one Confirmer role for the same focal class. If this were not true, a Fulfiller would only ever be capable of rejecting a request. While this is easy to implement, the expected market for such an application is low.

This applies to both POLB and PORX. Alternately use Placer/Confirmation Receiver and Fulfiller/Confirmer. The existing language just confuses things.

AK AJK021


POLB

N Mi The rational for the split of the Placer/Confirmer and Fulfiller/Confirmation Receiver roles is as follows. A request for action by a placer application might be accepted in multiple ways. The fulfilling application might respond with their intent to perform the action, or with a notification of the performed event. In areas such as pharmacy, a fulfilling application might respond to a request to fulfill a rescription with an intention to administer and dispense, to administer only, to dispense only, or with a schedule of intended actions. Naturally, not all applications will be capable of sending or receiving all possible responses. The choice is therefore to model the possible combinations through a separate set of interactions (Place combined order, receive combined confirmation intent; Place combined order, receive administration intent; etc.), or two separate the roles responsible for the requests from those responsible for the accept confirmations. In this ballot, we have chosen the latter.

The rational for the split of the Placer/Confirmation Receiver and Fulfiller/Confirmer roles is as follows. A request for action by a placer application might be accepted in multiple ways. The fulfilling application might respond with their intent to perform the action, or with a notification of the performed event. In areas such as pharmacy, a fulfilling application might respond to a request to fulfill a prescription with an intention to administer and dispense, to administer only, to dispense only, or with a schedule of intended actions. Naturally, not all applications will be capable of sending or receiving all possible responses. The choice is therefore to model the possible combinations through a separate set of interactions (Place combined order, receive combined confirmation intent; Place combined order, receive administration intent; etc.), or two separate the roles responsible for the requests from those responsible for the accept confirmations. In this ballot, we have chosen the latter.

This applies to both POLB and PORX. Alternately use Placer/Confirmation Receiver and Fulfiller/Confirmer. The existing language just confuses things. Also corrects typo, "rescription".

AK AJK022


POLB

N Mi Finally, applications are broken up into Tightly-coupled and Loosely-coupled versions. Tightly-coupled applications assume that there is a shared repository of information about patients, providers, facilities, etc. This allows for messages to be less detailed because it is sufficient to identify patients/providers/facilities using an id number and some basic coroborating information, rather than sending all of the detailed information. Loosely-coupled systems cannot rely on having a shared repository, and it is therefore necessary to send all information about patients/providers/facilities/etc. that the receiver would need to perform its function.

This applies to both POLB and PORX. Shouldn't the language in this section be brought in line with the definition of loosely/tightly coupled that appears in the glossary?

AK AJK023


POLB

N Mi This applies to both POLB and PORX. Throughout the section the description of loosely and tightly coupled seems to be out of synch with the definitions provided in the glossary.

AK AJK024


POLB

N Mj This applies to both POLB and PORX. We need to take a real hard look at the proliferation of application roles here. The number of application roles here has a major impact downstream on the number of interactions we will have. I can see that after the San Diego meeting quite a bit of work was done on elaborating application roles took place. I think we have a lot of weeding to do here to get his list down to a manageable size. We also need to take a look at how we are grouping the application roles. I'm not sure some of the groupings make sense.

AK AJK025

DM 5.1 - Lab D-MIM (POLB_DM000000)

POLB

A T b) laboratory intents (mood = intent, and b) laboratory intents (mood = intent, and order)

AK AJK026


POLB

N Mi I was under the impression that every structure in the R-MIM had to be present in the D-MIM. This means in essence an R-MIM can be derived from a D-MIM by subtracting elements from the D-MIM. Our R-MIM's can't be derived in this fashion. They contain items not contained in the D-MIM. For instance the Lab order R-MIM has A_Observation_Order, but the D-MIM does not contain this class. Thee are other examples as well.

AK AJK027


POLB

N Mi In the previous ballot we had identified that we failed to include financial transaction information into the order/intent/event for the first ballot. It looks like we didn't include it in this ballot either.

AK AJK028


POLB

N Mj In the previous ballot we had the ability to associate a diagnosis, allergy, other observation with an order. This capability has been removed from the current D-MIM, and hence all the R-MIMs as well. I know that the supporting clinical info CMET was added to the Patient CMEt, but the cloosely couple version of the CMET doesn't include supporting clinical CMET, so we have lost the means of adding this information. We can no longer reference a diagnosis, allergy, intolerance, etc. in an order. We can no longer transmit height, weight, etc. on an order

AK AJK029


POLB

N Mj The CMET section references our Lab D-MIM as the D-MIM for a number of clinical observation oriented CMET's, yet I know that the Lab D-MIM doesn't include things like intolerances at this point.

AK AJK030


POLB

N Mj There appear to be 4 separate order_option CMET's now, instead of just one. I'm actually a bit confused about how CMET's are supposed to be used now, and I'm not sure how these 4 CMET's fit into our D-MIM/R-MIM's

AK AJK031

DM 5.1 Lab D-MIM (POLB_DM000000)

POLB

N Mi The transportation CMET no longer has a way of distinguishing what's being transported, and the context it's used in the Lab D-MIM makes it ambiguous what's being transported.

AK AJK032

HD 7 Hierarchical Message Descriptions for POLB and PORX

POLB

N Mj This applies to POLB and PORX. It appears to me that many of the HMD's and Message types are duplicates of one another. We have more message types than the last ballot, and many of these are now duplicates. There doesn't seem to be any distinction between loosely coupled and tightly coupled anymore. I believe that Lloyd indicated that this is an issue with how his tools are creating HMD's and message types. Examples of duplicate HMD's include Laboratory Observation Intent Replace (POLB_HD003300) and Laboratory Observation Intent Revise (POLB_HD003200). Why do we have separate HMD's and Message Types if the information content is identical?

AK AJK033

HD 7 Hierarchical Message Descriptions for POLB and PORX

POLB

N Mj This applies to POLB and PORX. Descriptions of HMD's and Message Types are completely missing from the Lab and Rx ballot. This is a step back from the first ballot. One of the things that people didn't like about the first ballot was the lack of useful descriptions. In this ballot, we have made things even worse in a lot of cases.

AK AJK048

HD 7 Hierarchical Message Descriptions for POLB abd PORX

POLB

N Mj This applies to both POLB abd PORX. Although our D-MIM's and R-MIM's correctly show the ristrictions for vocabulary for attributes like class_cd and mood_cd (there are others), these restrictions haven't migrated into the HMD's and Message Types. I've inspected the Lab and Pharmacy model repositories that were posted on the HL7 website and they seem show the vocabulary restrictions properly via RoseTree, so I'm not sure where the issue arrose, but it's certainly an issue. Right now all out claas_cd's and mood_cd's use the full ActClass and ActMood domain's for vocabulary.

AK AJK049

HD All HMD's across the board.

POLB

N Mj The following issue was raised in the first ballot, and I'm adding it to this ballot because it echos a current concern of mine. This issue applies across the board to all attributes within HMD's. "The current documentary form contains insufficient usage notes about individual attributes in particular RMIM refined classes (or in the common HMD) to allow any certainty of interoperability. Numerous specific examples can be offered for each of the individual messages where the RIM description of the attribute is too general to be sure of the intended usage in a specific message.A revised documentary form is needed with usage notes available for each attribute of each class in the RMIM. This could most elegantly be provided in an extended version of the common HMD. Until this is available a really informed affirmative vote on this document is not possible. Even though it is possible that the

usage intended by the authors is entirely appropriate to the proposed interactions. This usage needs to be made explicit.An example of the problem …Substance_admin_order.max_dose_qty in HMPO_RX_RM01000. What does this maximum dose mean in the order? Is it an instruction that the recipient of the order limits the supply OR indicates on the supplied medication the maximum? The answer may seem self-evident to the authors of the RMIM but it needs to be stated explicitly in relation to these messages to ensure safety and interoperability. Note that this is only example, the primary problem is the restriction of the documentary form."

AK AJK034

IN 8 Interactions for POLB and PORX

POLB

N Mi This applies to POLB and PORX. Shouldn't the language in this section be brought in line with the definition of loosely/tightly coupled that appears in the glossary? All the interactions in this section use loosely couple/tightly coupled language that does not match the definition in the glossary.

AK AJK035


POLB

N Mj This applies to POLB and PORX. The short and long names for interactions are the same in this ballot. The short name was provided to give a common name for the artifact, making it easier for the reader to understand what the interaction is used for.

AK AJK036


POLB

N Mj This applies to POLB and PORX. Descriptions were one of the areas we need to beef up in the original ballot, but in the interaction area the descriptions are about the same as they were previously. The descriptions have changed, but I can't say that they are any better.

AK AJK037

RM 6 Refined Message Information Models

POLB

N Mj We appear to have lost the ability to handle parent/child orders. The D-MIM appears to support this concept with the AR-Fulfillment_by_intent recursion, but that's been removed from the Order and Intent R-MIM's. This needs to be restored.

AK AJK038

ST 2.3.1 Food Safety Outbreak Investigation (POLB_SN000501)

POLB

N T "Should there be a lab intent message here?"

? This appears to be an unanswered question about the construction of this storyboard.

AK AJK039

ST 2 - Storyboards for POLB abd PORX

POLB

N S This applies to POLB and PORX. In some ways the storyboards in the Lab and Rx section are an improvement over the first ballot (Rx now has them!). The stories themselves are clinically relevant. Unfortunately we have taken a step backward also, since components of storyboards such as ladder diagrams and interaction lists are partly or completely missing. In addition, those storyboards that do have diagrams, the diagrams themselves are inaccurate.

AK AJK040


POLB

N Mj This applies to POLB and PORX. Trigger Events is one area where we can tie back to version 2.x. The Publication database was enhanced to allow us to enter 2.x comments. We had these sort of comments in the previous ballot, but they were dropped in this ballot. This is a step back.

AK AJK041


POLB

N Mj This applies to POLB and PORX. The short and long names for trigger events are the same in this ballot. The short name was provided to give a common name for the artifact, making it easier for the reader to understand what the trigger event is used for.

AK AJK042


POLB

N Mj This applies to POLB and PORX. None of the trigger events that are state transition based have documentation on the actual state transition. The publication database was enhanced to allow this documentation.

AK DRY001

AR PORX PORX

N Mi This has already been discussed but wanted to put it on the record that we need to review and probably limit the application roles to something more realistic to manage and understand.

AK DRY002

AR PROX PORX

N Mi The Application Role Names are not informative. Could there be a more normalized short name under which the long name and full description could be found? For Example Administration System Roles under which you find the longer names of Combined Pharmacy etc....

AK DRY003

ST PORX PORX

N Mj Many storyboard ladder diagrams are still missing. Clumping the diagrams together rather than under their respective storyboard scenario is confusing.

AK AJK043


PORX

A Q The following was a question from the first ballot: "Why is the cardinality to P_subject 1 to many rather than just 1 to 1? Wouldn’t you need to specify a distinct order for each subject?" The question remains unanswered.

AK AJK044


PORX

N Mj The description section of the Rx D-MIM is inadequate. It should have a description similar to the one for the Lab D-MIM.

AK AJK045


PORX

N Mi In the D-MIM diagram, it is unclear what Acts the "AR_Dispense_instructions" is creating a relationship between. It's just hanging out there in the middle, unattached to any specific acts.

Action Items

ID# Action Item Responsible1 How to handle comments and annotations. Patrick Mitchell-Jones2 How to structure micro.3 Use case for different types of name value pairs for Observations Karen Sieber4 Need to add additional descriptions on how the state transitions apply specifically

to OO. Must be tied to general introduction to trigger events.Dick Harding, Austin, Gunther, Lloyd

5 Need to review Receiver responsibilites, to see if we missed any. Sara Korpak6 Need to review receiver responsibilites to make sure we included all appropriate

responsibilities.7 Need to investigate how to indicate no reciever responsibilities. Austin8 Convince Gunther of separating OCCUR vs. COMP Austin9 Create improved description of the Replace state transition scenario Austin

10 Incorporate the principle as appropriate into the application role/hierarchy discussion Lloyd

11 Move proposal to MnM Lloyd, Austin12 Review RIM for current terminology (replace outdated USAM terminology, e.g.,

service object) Gunther, Austin13 Re-synchronize ladder diagrams with interaction model. Lloyd, Austin14 Check with Dan Jernigan about the need for a lab intent. Hans15 Check on fix for nullification and reactivation as well as superfuously generated

wording Lloyd, Virginia16 Submit certainty_cd to Harmonization to be added to Act Gunther, David Markwell17 Address old approach for grouping container in Rx with new containment approach Lloyd, Julie18 Documentation of constraints on attributes based on status codes in the RIM Gunther, Harmonization19 Fix the machinery on how CMETs are incorporated into HMDs. Lloyd, Dale20 Check on COMP/PERT decision Lloyd, Gunther, Austin21 Create proposal and review with MnM/Conformance how it can be done legally Gunther22 Review additional trigger events/interactions needs for Rx Lloyd, Scott23 Resolve the discrepancy and come up with one construct except for cardinality Gunther, Lloyd, Austin24 Lloyd needs to determine if the supply event R-MIM needs an id attribute. Lloyd25 The Meds Management Sig needs to review these items Lloyd, Scott26 Tighten up the description of the A_Observation CMET (and derrived CMET's) and

change the names to Supporting_info, and create a D-MIM. Austin27 Synchronize the Rx/Lab approach on how to deal with A_Observation_supporting

Austin, Lloyd.

CMET, and b eef up the description of how it's used vs. the same CMET in R_Patient.

28 Update Act_Status_Control_Payload D-MIM to constrain id and cd such that they cannot be changed. Austin

29 Confirm no other status codes should be included. Determine the cardinality is correct (if so, clarify with use case the absence of a status code) Gunther, Austin

30 Forward to Publishing thoughts on improved readability and navigation. Hans31 Clarify whether Preliminary disappeared or needs to be better documented and

approach to supplementary. Gunther, Austin, Wayne, Bob Dolin