HIMSS and RSNA. IHE Technical Framework Version 4.6. Errata

Transcription

1 HIMSS and RSNA Integrating the Healthcare Enterprise IHE Technical Framework Version 4.6 Errata - 1 -

2 Introduction The errata in this document are listed by section in the IHE Technical Framework. Each item begins with a comment number maintained by the IHE Technical Committee for cross reference to a tracking system. Following the tracking number is a description of the errata and/or new text which belongs in the IHE Technical Framework. Changes in This Revision The following new entries are included in this revision: Comment Section 17, Errata 1 (Review Committee) Group Case Requirement Change Rationale: The IHE Review Committee has decided to remove the requirement that modality actors support the group case in the Year 3 Schedule Workflow Integration Profile demonstration. The Review Committee has directed the Planning and Technical Committees to review the use cases for grouped procedures with clinical users and, if necessary, to revise the requirements in the Year 4 Technical Framework. Table 3.3-4: Table should be replaced by the following table and note: Actors Transactions Optionality Section Department System Scheduler/ Refer to Scheduled Workflow R Order Filler Acquisition Modality Image Manager/ Image Archive Refer to Scheduled Workflow R Modality Procedure Step In Progress R* 6.6 Refer to Consistent Pres. Of Images R Refer to Scheduled Workflow R Refer to Consistent Pres. Of Images R Performed Procedure Step Manager Refer to Scheduled Workflow R Refer to Consistent Pres. Of Images R

3 Note: The Presentation of Grouped Procedures Integration Profile makes support of Group Cases required for the Acquisition Modality Actor. Section : Remove the second sentence ("All of these... by all the actors involved.") Section : Add the following two new paragraphs at the end of the section: Support for the group case by the Acquisition Modality actor is required in the Presentation of Grouped Procedures Integration Profile, but is optional in the Scheduled Workflow Integration Profile. This is a relaxation for Year 3 of the Scheduled Workflow requirement. Broader use cases for grouping are being considered which may result in additional requirements in Year 4. The DSS/Order Filler, Image Manager and Performed Procedure Step Manager are always required to accept Performed Procedure Steps containing attributes from multiple Scheduled Procedure Steps and Requested Procedures in Integration Profiles where those actors accept Modality Performed Procedure Step Transactions. 2 (25) Section Change the tables of acknowledgement segments and profiles to include the optional ERR segment. Replace the current text, which reads as follows: ACK Acknowledgement Message MSH Message Header 2 MSA Message Acknowledgement 2 Chapter in HL Table IHE Profile - MSA segment SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME 1 2 ID R Acknowledgment Code 2 20 ST R Message Control ID 3 80 ST O Text Message 4 15 NM O Expected Sequence Number 5 1 ID O Delayed Acknowledgment Type CE O Error Condition Adapted from the HL7 standard, version

4 Field MSA-2 Message Control ID shall contain the Message ID from the MSH-10 Message Control ID of the incoming message for which this acknowledgement is sent. With: ACK Acknowledgement Message MSH Message Header 2 MSA Message Acknowledgement 2 [ERR] Error Comments 2 Chapter in HL Table IHE Profile - MSA segment SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME 1 2 ID R Acknowledgment Code 2 20 ST R Message Control ID 3 80 ST O Text Message 4 15 NM O Expected Sequence Number 5 1 ID O Delayed Acknowledgment Type CE O Error Condition Adapted from the HL7 standard, version Field MSA-2 Message Control ID shall contain the Message ID from the MSH-10 Message Control ID of the incoming message for which this acknowledgement is sent. Table IHE Profile - ERR segment SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME 1 80 ID R Error code and location Adapted from the HL7 standard, version (9) Section Add the following sentence after the second sentence of paragraph 1: In the event that a new patient will be seen as an outpatient at some future time, an ADT A04 message shall be used to convey patient information required by the Order Placer or Order Filler. Pre-admission of inpatients shall use the A05 message

5 4 (22) Section It is unclear whether or not Referring Doctor field may (or shall) be valued when ADT^A05 (pre-admit) is sent. It is common practice in the industry that this and other similar fields may be sent or note at the discretion of the registration clerk (i.e., whether information is known or not). Seems like some of the conditions for the fields in PV1 segment for the ADT messages are too restrictive. It is proposed to change the third paragraph below Table as follows: Field PV1-8 Referring Doctor shall be valued when registering an outpatient, i.e., when the MSH-9 Message Type is ADT^A04. May be present otherwise. 5 (35.2) Section The optionality of the Observation Identifer (Item #00571) in Table should be R and not R2. 6 (24) Section , Table Add Refering Physician to the PV1 segment as an R2 field, making sure it is passed if available for MWL mapping (Appendix D). Table now reads as follows: SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME 2 1 IS R Patient Class 8 60 XCN R Referring Doctor CX C Visit Number 51 1 IS C Visit Indicator 7 (35.4) Section The IHE Profile of the OBR Segment (Table 6.2-4) lists up to field 43 (Planned Patient Transport Comment). The HL specification for the OBR Segment includes fields 44 and 45. Note these fields are optional and have no defined usage in the IHE Technical Framework for Year 3. The two missing fields should be added as shown below CE O Planned Patient Transport Comment CE O Procedure Code CE O Procedure Code Modifier - 5 -

6 8 (33) Section 6.4 Add note to the third row of the Table as follows: Table 6.4-6: DSS mappings of the OBR Segment Element Name Seq Shall Contain: Notes Placer Field 2 OBR-19 Requested Procedure ID All OBR segments within a single ORM message shall have the same value in this field. Filler Field 1 OBR-20 Scheduled Procedure Step ID If a Scheduled Procedure Step has multiple Protocol Codes associated with it, several ORC segments within a single ORM message may have the same value in this field. Placer Field 1 OBR-18 Accession Number All OBR segments within a single ORM message shall have the same value in this field. Universal Service ID OBR-4 Both the Requested Procedure Description /Code and the Scheduled Procedure Step Description/Action Item Code. Specimen Source OBR-15 The fifth component, Site Modifier, shall be used for the L/R indicator. The L/R value shall be appended to the Requested Procedure Description (0032,1060). Diagnostic Service Section ID Components 1-3 of OBR-4 shall be copied by the Order Filler from the components 1-3 of OBR-4 it obtains from the ORM message (OBR segment) conveyed to it by the Order Placer. Components 4-6 shall be filled with the Scheduled Procedure Step Description/Protocol Code. Components 1-3 of OBR-4 field shall have the same value within one ORM message. This element shall only be used if the coding scheme that is employed does not contain laterality within the coding scheme itself. If laterality is inherent in the coding scheme, this element shall not be sent. OBR-24 DICOM Modality The Modality attribute of DICOM consists of Defined Terms that should be used in this element. 9 (27) Section Optionality of the field PID-7 Date and Time of Birth in the ORM message in Procedure Scheduled transaction cannot be R because there is a possibility of a procedure scheduled for the unidentified patient, i.e., when DOB is most possibly not known. Change optionality to R

7 10 (26) Section Conditions for the fields in PV1 segment of the ORM message in Procedure Scheduled transaction are incorrect, referring to the registration. Change second and third paragraphs below Table as follows: Fields PV1-3 Assigned Patient Location, PV1-7 Attending Doctor, PV1-10 Hospital Service, PV1-17 Admitting Doctor shall be valued only when a procedure is scheduled for the in-patient. Field PV1-8 Referring Doctor shall be valued when a procedure is scheduled for an outpatient. May be present otherwise. 11 (23) Section Change the paragraph discussing A03 to be a bulleted list which includes a discussion of how the discharge date/time is resolved. Replace the third paragraph under Table , which currently reads: For A03 message, the field PV1-3 Assigned Patient Location shall contain the patient s location prior to discharge and neither or neither PV1-6 Prior Patient Location nor PV1-43 Prior Temporary Location shall be valued. With: For Discharge Patient (A03) message: The field PV1-3 Assigned Patient Location shall contain the patient s location prior to discharge. PV1-6 Prior Patient Location or PV1-43 Prior Temporary Location shall be valued. Discharge Date/Time does not have to be present in A03, if A03 indicates the discharge happening at the time of the message the timestamp in the EVN segment signifies date and time of discharge. 12 (30) Section , , , , Change the second sentence of each section as follows: See section for the list of all fields of the PV1 segment. 13 (34) Section Add three sentences immediately after the Table as follows: - 7 -

8 Value of the field ORC-5 Order Status shall reflect status of the underlying order. If the order has been cancelled by either the Order Placer or the Order Filler, the value in the field ORC-5 shall be set to CA, otherwise it shall be set to SC. In particular, if the field ORC-1 is sent with the values of CA or DC, the field ORC-5 will be valued as CA, and with ORC-1 set to XO, the ORC-5 will be valued as SC 14 (15) Section : Table Delete the entire row with Attribute Name Referenced SOP Instance UID, because it is redundant. (The entry is right before Patient s Birth Date.) 15 (28) Section , Table Change note IHE-3 to explicitly state that the Placer Universal Service ID is to be used. Also, add a new note IHE-4 which states the Report Manager is assumed to be able to get the filler and order numbers if unavailable from the SR. The table is updated for the new note. The old table and notes are as follows: SEQ OPT TBL# ITEM # ELEMENT NAME DICOM DICOM Tag Notes Description / Module 1 R Set ID OBR See note IHE-2 2 R Placer Order Number SR Document General, Referenced Request Sequence (0040,2016) 3 R Filler Order Number SR Document General, Referenced Request Sequence (0040,2017) 4 R Universal Service ID See Note IHE-3 7 R Observation DateTime SR Content Observation DateTime if present, otherwise use the SR Document General, Content Date, Content (0040,A032) or (0008,0023) (0008,0033) Time 25 R Result Status = F IHE-2: If the SR has multiple items in the Referenced Request sequence, the Report Manager will generate separate ORU messages for each item. IHE-3: The Report Manager shall supply the Universal Service ID. It is assumed that the Report Manager is able to obtain the Universal Service ID value. The new table and notes will be as follows: - 8 -

9 SEQ OPT TBL# ITEM # ELEMENT NAME DICOM DICOM Tag Notes Description / Module 1 R Set ID OBR See note IHE-2 2 R Placer Order Number SR Document General, Referenced Request Sequence 3 R Filler Order Number SR Document General, Referenced Request Sequence (0040,2016) See Note IHE-4 (0040,2017) See Note IHE-4 4 R Universal Service ID See Note IHE-3 7 R Observation DateTime SR Content Observation DateTime if present, otherwise use the SR Document General, Content Date, Content (0040,A032) or (0008,0023) (0008,0033) Time 25 R Result Status = F IHE-2: If the SR has multiple items in the Referenced Request sequence, the Report Manager will generate separate ORU messages for each item. IHE-3: The Report Manager shall supply the Universal Service ID from the original order (Placer). It is assumed that the Report Manager is able to obtain the Universal Service ID value. IHE-4: If the Placer and/or Filler order number are not provided by the Referenced Request Sequence, it is assumed that the Report Manager is able to obtain values. 16 (17) (29) Section , Table To clarify the source of the Image references, clarify the references to Images and Sub-IDs in Table and to avoid confusion between Images and Key Image Notes, change the second section in the table. Replace: The next multiple of four OBX segments repeats for each IMAGE type Content Item present in the SR content. These are key images that are directly referenced in the content of the SR. Each set of four segments will have the same SubID, starting with one. The Set-ID increments starting with 2. 2 R Value Type = HD = Study Instance UID 5 R Observation Value SR Document General, Referenced Request Sequence 0020,000D - 9 -

10 2 R Value Type = HD = Series Instance UID 5 R Observation Value SR Document Series 0020,000E 2 R Value Type = SOP Instance UID 5 R Observation Value SR Document General, Referenced Study Sequence 2 R Value Type = HD = SOP Class ID 5 R Observation Value SR Document General, Referenced Study Sequence 0008, ,1150 With: The next set of four OBX segments repeats for each IMAGE type Content Item present in the SR content. Each OBX set provides the external report repository the ability to lookup the relevant image references. The Content Items only provide the Referenced SOP Class UID (0008,1150) and Referenced SOP Instance UID (0008,1155). The Study Instance UID (0020,000D) and Series Instance UID (0020,000E) are found in the corresponding item in the Current Requested Procedure Evidence Sequence (0040,A375) or the Pertinent Other Evidence Sequence (0040,A385). Use the SOP Instance UID to find the correct sequence item. For further details, see Table C.17-2 (SR Document General Module Attributes) and Table C.17-3 (SOP Instance Reference Macro Attributes) in Part 3 of the DICOM 2000 Standard. Each set of four OBX segments that make up an UID reference will have the same unique Observation Sub-ID (OBX 4). The Sub-ID for the first set shall have a value of 1. The Sub-ID shall increment for each subsequent OBX set in the message. 2 R Value Type = HD = Study Instance UID 5 R Observation Value Current/Pertinent Evidence Sequence, matching item s Study Instance UID 2 R Value Type = HD 0020,000D

11 = Series Instance UID 5 R Observation Value Current/Pertinent Evidence Sequence, matching item s Series Instance UID 2 R Value Type = SOP Instance UID 5 R Observation Value IMAGE Content Item, Referenced SOP Instance UID 2 R Value Type = HD = SOP Class ID 5 R Observation Value Image Content Item, Referenced SOP Class UID 0020,000E 0008, , (20) Appendix D Notes 5 and 6 are referring to irrelevant sections due to change in TF formatting and content. Review also showed that Note 3 is conflicting with the content of the table and Note 4 may be improved as well. Change the notes as follows: Note 3: Department System Scheduler/Order Filler shall determine the value of DICOM Modality (0008,0060) attribute based on the content of the order. The DICOM defined terms must be used for the MWL response as listed in DICOM PS 3.3. Note 4: Attributes (0040,2016) and (0040, 2017) are designed to incorporate the HL7 components of Placer Issuer and Number, and Filler Issuer and Number. In a healthcare enterprise with multiple issuers of patient identifiers, both the issuer name and number are required to guarantee uniqueness. Note 5: Refer to Appendix G for a more thorough discussion on the mapping of Patient ID and Issuer of Patient ID for different use cases. Note 6: As discussed in section , use of the field PID-18 Patient Account Number alone may not be sufficient to uniquely identify an encounter; field PV1-19 Visit Number is often used in addition to PID-18. However, because table D-1 represents a mapping of patient demographics and order characteristics to MWL, and because

12 Visit information is not migrated into the C-Store composite object, it is assumed that the value of PID-18 will be sufficient for purposes of MWL. 18 (35.3) Appendix D The observation value and unit fields for the Patient s Weight and Height OBX segments are specified incorrectly. The values are passed as strings, hence the value is the whole field. The units kg and m are HL7 unit identifiers and not text meanings. The following is the current HL7 Order Mapping to DICOM MWL entries: Patient's Weight (0010,1030) O 2 Observatio n Value Patient's Size (0010,1020) O 2 Observatio n Value when = "Body Weight" and = "kg" when = "Body Height" and = "m" The following is the corrected HL7 Order Mapping to DICOM MWL entries: ADT OBX:5 ADT OBX:5 See note 7 See note 7 Patient's Weight (0010,1030) O 2 Observatio n Value when = "Body Weight" and = "kg" ADT OBX:5 See note 7 Patient's Size (0010,1020) O 2 Observatio n Value when = "Body Height" and = "m" ADT OBX:5 See note 7 Note 7 example segments are incorrect:

13 OBX ST ^BODY WEIGHT ^62 ^kg OBX ST ^BODY HEIGHT ^1.90 ^m The corrected examples, include the missing required Observation Result Status, is as follows: OBX ST ^BODY WEIGHT 62 kg F OBX ST ^BODY HEIGHT 1.90 m F