36H79719R0007-0006038.pdf

Joint VA / DoD DICOM Conformance Requirements for Digital Acquisition Modalities

Version 3.0

28 September 2005

Joint VA / DoD DICOM Conformance Requirements for Digital Acquisition Modalities

September 28, 2005 Version 3.0 Page i

SIGNATURE PAGE

James E. Demetriades Department of Veterans Affairs Date

5 Oct 2005

Veterans Health Affairs Chief Architect, Health Information Architecture Office

Ronald R. Pace Department of Defense Date

21 Oct 2005

Military Health Systems Chief Enterprise Architect

September 28, 2005 Version 3.0 Page ii

PREFACE

The purpose of this Requirements Document is to specify how modalities shall provide the Digital Imaging and Communications in Medicine (DICOM) functionality needed by the Department of Veterans Affairs (VA) and Department of Defense (DoD). This document and its associated annexes contain the minimal requirements for all VA and DoD purchases of radiology, dental, ophthalmology and optometry, cardiology, pathology, endoscopy, dermatology, and all other DICOM-compliant digital acquisition modalities and related equipment. Individual VA/DoD organizations may elect to mandate requirements which are listed as optional or are not present within this document and its associated annexes.

The Veterans Health Administration (VHA) Patient Care Services and the DoD Military Health System (MHS), representing all clinical care programs that use imaging equipment, consider these requirements essential for interoperability between imaging equipment and government hospital information systems (HIS). Other agencies are encouraged to adopt these requirements as the basis for DICOM conformance.

This document is available online at http://vaww.va.gov/imaging/.

Please refer to this website for directions regarding submission of comments, inquiries, and suggestions.

http://vaww.va.gov/imaging/�

September 28, 2005 Version 3.0 Page iii

REVISION HISTORY

Date Revision Description Author 11/25/1997 1.0 RFC Request for Comments Herman Oosterwijk 07/07/1998 1.0 RFP Request for Proposal Herman Oosterwijk 06/18/1999 1.0 Original Document Herman Oosterwijk 06/22/1999 1.1 Minor Revision Herman Oosterwijk 09/07/1999 1.2 Final Release Herman Oosterwijk 11/16/2001 2.0 Major Revision Herman Oosterwijk 02/15/2002 2.1 Made Storage Commitment and MPPS Optional Peter Kuzmak 03/27/2002 2.2 Added elements to MWL for clinical specialties Peter Kuzmak 01/03/2003 2.3 Updated references to external documents and web pages Dan Carozza

12/31/2003 2.4 Combined DoD and VA Requirements into one document

Donald Van Syckle Herman Oosterwijk

03/31/2004 2.4.8.3 Request for Comments Donald Van Syckle Herman Oosterwijk

05/11/2004 2.4.8.6 Request for Comments VA / DoD Imaging Subgroup

01/14/05 2.4.8.10 Require Modalities to support IHE Scheduled Workflow

Donald Van Syckle

1/28/05 2.4.8.11 Modifications due to comments from industry;

minor editing and corrections

Peter Kuzmak

8/1/05 2.5.5 Added Section 508 Requirements Peter Kuzmak 9/1/05 2.5.6 Updated IHE reference. VA / DoD Imaging

Subgroup 9/13/05 2.5.7 Added Signatures of Chief Architects VA / DoD Imaging

Subgroup

Principal Authors for Version 3.0 Mr. Don Van Syckle Mr. Herman Oosterwijk

Contributors for Version 3.0

Mr. Peter Kuzmak, DVA Dr. Ruth E. Dayhoff, DVA Dr. Daniel N. Carozza, DVA Mr. Dezso Csipo, DVA Dr. Glenn Haggan, DVA Dr. Gregory G. Zeller, DVA Mr. Paul Gihring, DVA Col Alan Smith, DoD Col James Cocklin, DoD Mr. Andrew Casertano, DoD

September 28, 2005 Version 3.0 Page iv

Major changes from Version 2.4 to 2.5.7 include:

1) Added Section 508 Requirements

2) Updated the Integrating Healthcare Enterprise Technical Framework (IHE) Scheduled

Workflow Requirements

3) Updated the document based on review and recommendations of the Department of

Defense, TRICARE Management Activity Technology Management, Integration and Standards and VHA/DoD Health IT Sharing Program Architecture and Standards groups.

Major changes from Version 2.3 to 2.4 include:

1) Combined VA and DoD requirements into one document

2) Update References to the Integrating the Healthcare Enterprise Technical Framework (IHE), Version

5.5 document

3) Updated Web-sites

4) Updated Acronyms

5) Restructured Figures and Table numbering

6) Updated Figure 1 - Hierarchical Integrated Data Model

7) Updated Table 1 - Scheduled Workflow Integration Profile - Actor and Transactions

8) Updated Table 2 - Consistent Presentation of Images Integration Profile - Actors and Transactions

9) Updated Table 6 - Modality Worklist (MWL) Keys for Broad Worklist Queries

10) Added two requirements in Section 4.4.3 - C-STORE Attribute Requirements

11) Updated Section 4.4.3 Minimum Attribute Length for Patient Name / Patient ID

12) Updated Table 11 - Image Storage Attributes

13) Updated Section 6.4 - Security of Connections

14) Added Signature Page

15) Add requirement for modalities supporting IHE Scheduled Workflow

Major changes from Version 2.0 to 2.3 included:

1) The requirements for the DICOM Verification, Modality Worklist and Storage services contained in this document are mandated for all new purchases of Radiology, Dental, and Ophthalmic digital acquisition modality equipment.

2) The requirements for the DICOM Storage Commitment and Modality Performed Procedure Step contained in this document are optional and are not mandated for purchases of new equipment.

3) This version of the requirements document introduces Print Management and Presentation Look Up Table (LUT) Service-Object Pair (SOP) classes, which are optional and are not mandated for purchase of new equipment.

September 28, 2005 Version 3.0 Page v

4) If the equipment does support these optional DICOM services, however, it should be done in a fashion satisfying the requirements in this document. VA will not be using or formally validating optional requirements at this time. This functionality will be phased in over time.

5) A checklist is provided at the end of this document to help vendors and acceptance personnel verify that the stated requirements are properly meet.

6) All new models of Radiology, Dental, and Ophthalmic digital acquisition modality equipment shall have their DICOM capabilities verified by Internet testing with the VA prior to being purchased.

This document also differs from Version 1.2 from a formatting perspective as well as a functional perspective. The format has been changed for vendors to more easily identify the specific individual requirements, which are now highlighted with bullets (“”) in the text. Furthermore, since there is a strong commitment from the VA and DoD to the IHE Technical Framework activity and corresponding technical documentation, this document has been made consistent with the transactions and profiles as described in the latest IHE Technical Framework. An effort has been made to reference the IHE documents wherever possible, instead of duplicating the text here. From a functional perspective, this document incorporates experience with integrating modalities with the VistA system since the initial version, and it accommodates non-radiology applications in clinical specialties.

Some of the requirements in this document are more detailed than what IHE specifies, for example, the IHE does not include any explicit statement for the presence of specific image attributes. On the other hand, some requirements are a subset of those of the IHE, because of the actual workflow environment;

for example, support is not required for unscheduled case, group cases, and so forth.

Major changes from Version 1.2 to 2.0 included:

1. Verification, MWL and Storage are mandated requirements. Storage Commitment, Modality

Performed Procedure Step, the Print Management and Presentation LUT SOP Classes are optional and are not mandated.

2. Each requirement is specifically mentioned in the form of a “bullet” and added as a checklist so that a vendor easily can determine and document its compliance (see Appendix C).

3. The requirements for the various SOP Classes were identical for each modality type. They are changed and now depend on the type of modality.

4. This specification is extended to include non-radiology modalities.

5. The document is made consistent with the profiles as specified in the IHE Technical Framework.

6. Print is added as a requirement for modalities, including support for the Presentation LUT, conformant with the IHE Print Composer profile.

7. MWL query support is extended and specified in more depth, consistent with the keys required by

IHE; version 1.2 only specified matching keys for Accession number and Requested Procedure Identifier (ID).

8. Shortcut Matching keys were required for the Accession number; this is extended to the Patient ID as well.

9. Support for some modalities as a Storage Service Class Provider (SCP) is added.

10. UID uniqueness (consistent with DICOM) is clarified.

September 28, 2005 Version 3.0 Page vi

11. Association errors are clarified (consistent with DICOM).

12. Gigabit/sec is added as a communication profile requirement.

13. Requirement for virus protection is added.

14. Testing of new modalities prior to the procurement with VistA is required.

15. Several new elements have been added to MWL in order to support the clinical specialties.

September 28, 2005 Version 3.0 Page vii

Table of Contents

SIGNATURE PAGE ..........................................................................................................................................I PREFACE ........................................................................................................................................................II

1. INTRODUCTION

1.1. Executive Summary

1.2. Audience

1.3. Reference Documents

1.4. Symbols and Abbreviations

1.5. HIMSS/RSNA IHE Initiative

1.6. Hierarchical Integrated Data Model

1.7. DICOM Digital Acquisition Modality Interface Architectures

2. REQUIRED AND OPTIONAL IHE PROFILES

2.1. Integration Profile

2.2. Print Profile (Optional)

3. GENERAL REQUIREMENTS

3.1. Service-Object Pair (SOP) Class Support to Implement IHE Profiles

3.2. Association Behavior

4. SPECIFICATION OF INDIVIDUAL TRANSACTIONS

4.1. Modality Worklist Provided (Mandatory)

4.1.1. Hierarchical Integrated Data Model

4.1.2. Query Support

4.2. Modality Procedure Step In Progress (Mandatory)

4.3. Modality Procedure Step Completed (Mandatory)

4.4. Modality Images Stored – Acquisition Actor (Mandatory)

4.4.1. Specific SOP Class requirements

4.4.2. Storage Service Association Policies for Low Disk Space

4.4.3. C-STORE Attribute Requirements

4.4.4. Pixel Representation Issues

4.5. Modality Images Stored – Archive Actor (Optional)

4.5.1. Specific SOP Class Requirements

4.6. Storage Commitment (Mandatory)

4.7. Verification (Mandatory)

4.8. Print Composer (Optional)

5. SERVICE AND SUPPORT REQUIREMENTS

6. COMMUNICATION PROFILES

6.1. Transmission Control Protocol / Internet Protocol (TCP/IP) Stack

6.2. Datalink and Physical Media

6.3. Configurable Parameters

6.4. Security of Remote Access for Vendor Service of Imaging Modalities

7. SECTION 508 REQUIREMENTS

8. SUPPORT FOR FUTURE ENHANCEMENTS

9. TESTING PRIOR TO PROCUREMENT

APPENDIX A: MAPPING BETWEEN DICOM MWL SCP ATTRIBUTES AND FIELD NAMES IN

VISTA AND CHCS II ......................................................................................................................... A-1 APPENDIX B: DIFFERENCE BETWEEN THE VA / DOD AND IHE REQUIREMENTS ............................. B-1 APPENDIX C: CONFORMANCE CHECKLIST ........................................................................................... C-1

September 28, 2005 Version 3.0 Page viii

List of Tables

Table 1 Scheduled Workflow Integration Profile - Actor and Transactions Table 2 Consistent Presentation of Images Integration Profile - Actors and Transactions Table 3 Required SOP Classes Table 4 Optional SOP Classes Table 5 MWL Keys for Query by Patient Table 6 MWL Keys for Broad Worklist Queries Table 7 Required Attributes to be Displayed for MWL Table 8 Additional MWL Attributes (Optional) Table 9 Proposed Presentation Context for all Storage SOP classes Table 10 Status Information Provided for Disk Full Table 11 Image Storage Attributes Table 12 Mapping Between DICOM MWL SCP Attributes and field names in VISTA and CHCS II ..... A - 1 Table 13 VA / DoD and IHE* Differences .............................................................................................. B - 1 Table 14 VA / DoD Requirements Compliance Checklist ..................................................................... C - 1 Table 15 VA / DoD Internet Test Checklist ............................................................................................ C - 4 Table 16 VA / DoD Acceptance Testing Checklist ............................................................................... C - 5

List of Figures

Figure 1 Hierarchical Integrated Data Model Figure 2 Architecture 1: Using a commercial PACS Figure 3 Architecture 2: Using the VistA Imaging System as the PACS

September 28, 2005 Version 3.0 Page 1

1. INTRODUCTION

1.1. Executive Summary

The purpose of this document is to define VA / DoD DICOM conformance requirements for digital acquisition modalities, which generate DICOM objects. Examples of these modalities include those used in radiology, dental, ophthalmology and optometry, cardiology, pathology, endoscopy, dermatology, etc.

By adhering to these requirements, modality compatibility and interoperability with VistA Imaging and CHCS II will be greatly enhanced. These requirements consist of a defined set of attributes for all objects that are exchanged. The requirements also include a set of DICOM services (DICOM Modality Worklist Management, Storage, Modality Performed Procedure Step, Storage Commitment and Verification).

DICOM standard issues that are commonly subject to misinterpretation are explicitly stated so vendors can check their implementations against the standard and verify their compliance. Note that these requirements should be redundant because they effectively repeat the DICOM standard.

In March 2003, the Federal Government announced the first eGov health information exchange standards. Benefits from using common health care standards include improved patient safety and a reduction in the cost of health care. As part of this federal partnership, the Veterans Health Administration (VHA) and the DoD Military Health System (MHS) have adopted the DICOM standard to enable images and associated diagnostic information to be retrieved and transferred between various manufacturers’ devices as well as provider workstations. This document is also designed to facilitate interoperability between the two organizations.

Department of Veterans Affairs (VA)

VA is one of the pioneers of implementing Picture Archiving and Communications Systems (PACS) in a clinical environment. VA was one of the first organizations to implement DICOM1 interfaces between commercial PACS, image generating modalities, and the hospital/radiology information system. Today, all VA hospitals are using this technology to increase efficiency, lower cost, and reduce turnaround time for diagnostic exams. This has a positive impact on improving patient care in the VA hospital environment.

Based on these early implementations, it became clear that there was a need to specify uniform and consistent requirements for modality vendors supporting the DICOM standard. The VA found many cases where information that was critical in uniquely identifying a patient or a study (for example the accession number in a radiology study) was often entirely missing from the image header, or was encoded in different fields (for example as Comments). The VA also noted that certain modalities do not accommodate a sufficient number of characters in the patient data entry, causing the Patient Name and/or Patient Identifier (ID) to be truncated. Furthermore, the VA encountered DICOM violations that might have resulted from misinterpretations of the standard, which caused interoperability issues. To resolve this situation, the VA initially developed this requirements document.

Department of Defense (DoD)

CHCS II will manage the medical and dental images of over 9.1 million Department of Defense Health Care Beneficiaries. Images from more than 100 hospitals and 600 clinics worldwide will be managed with the CHCS II Clinical Data Repository (CDR) military health record. To support a mobile force, CHCS II will enable worldwide access to images. Through the CDR, CHCS II will have an Enterprise Master Patient Index (EMPI) that will provide a unique identifier for patients.

1 National Electrical Manufacturers Association: Digital Imaging and Communications in Medicine standard PS 3.1 to 3.18 – 2004.

September 28, 2005 Version 3.0 Page 2

CHCS II will be implemented in blocks of increasing functionality, allowing the MHS to build a system that is easily adapted to meet new user requirements and to incorporate the latest technology available.

Block 1 provides a graphical user interface (GUI) for encounter documentation that enables immediate and concurrent retrieval of medical records. Block 2 integrates dental charting and documentation functionality as well as immediate global access to medical and dental records. Block 3 will integrate Commercial off the shelf (COTS) pharmacy, laboratory, and radiology functionality into the electronic patient record.

1.2. Audience

The intended audience of this document is:

• Government Contracting Specialists who need to include this document in every purchase order for imaging modalities to ensure that the equipment provides the necessary capabilities to interoperate properly with the Department of Veterans Affairs (VA) and the Department of Defense (DoD) systems.

• Vendor technical staff planning to interface with the Veterans Health Information System

Technology and Architecture (VistA) Imaging and the Composite Health Care System II (CHCS II). This document is intended to clarify the differences to implementers who are well versed in the Digital Imaging and Communications in Medicine (DICOM) standard and the Integrating the Healthcare Enterprise (IHE) Technical Framework.

• Vendor personnel who want to learn what specific requirements VA and DoD environments pose on modalities so they can plan their implementations accordingly.

• VA and DoD technical and functional personnel who want to familiarize themselves with the IHE concepts in context of the VistA Imaging and CHCS II environments.

1.3. Reference Documents

1. Federal Government Announces First Federal eGov Health Information Exchange Standards, March 2003. available at http://www.whitehouse.gov/omb/egov/gtob/health_informatics.htm,

2. Department of Defense/Department of Veterans Affairs Clinical Data Repository –Health Data Repository Working Integrated Product Team Imaging Subgroup Charter, dated April 23, 2003.

3. National Electrical Manufacturers Association (NEMA); Digital Imaging and Communications in Medicine (DICOM) standard, available at http://medical.nema.org/dicom/2004.html

4. HIMSS/RSNA Integrating the Healthcare Enterprise (IHE) Technical Framework, rev 6.0, 2005. Available at http://www.ihe.net/Technical_Framework/

5. Kuzmak PM and Dayhoff RE: Minimizing Digital Imaging and Communications in Medicine (DICOM) Modality Worklist Patient/Study Selection Errors, Journal of Digital Imaging, Vol 14, No 2 Suppl 1 (June), 2001: pp 153-157.

6. Gale ME, Gale DR: DICOM Modality Worklist: An Essential Component in a PACS Environment, Journal of Digital Imaging, Vol 13, No 3 (August) 2000: pp 101-108.

7. DoD Ports and Protocol Policy Available on the Defense Information System Agency (DISA) website. http://www.cert.mil/portsandprotocols/.

http://www.whitehouse.gov/omb/egov/gtob/health_informatics.htm�

September 28, 2005 Version 3.0 Page 3

1.4. Symbols and Abbreviations

AE Application Entity

CDR Clinical Data Repository CDT Current Dental Terminology CHCS II Composite Health Care System II COTS Commercial off the Shelf CPT Current Procedural Terminology CR Computed Radiography CT Computed Tomography

DEERS Defense Enrollment Eligibility Reporting System DICOM Digital Imaging and Communications in Medicine DISA Defense Information System Agency DoD Department Of Defense DX Digital Radiography

EMPI Enterprise Master Patient Index EWS Enterprise Wide Scheduling

FTP File Transfer Protocol (part of the TCP/IP protocol suite)

GUI Graphical User Interface

HIMSS Healthcare Information and Management Systems Society HIS Hospital Information System

ID Identifier IHE Integrating the Healthcare Enterprise IOD Information Object Definition ISO International Standards Organization

LUT Look Up Table

MHS Military Health System MPPS Modality Performed Procedure Step MR, MRI Magnetic Resonance Imaging MWL Modality Worklist

N/A Not Applicable NM Nuclear Medicine

PACS Picture Archiving and Communication System PDU Protocol Data Unit PT, PET Positron Emission Tomography Scan

September 28, 2005 Version 3.0 Page 4

RFC Request For Comments RIS Radiology Information System RSNA Radiological Society of North America

SCP Service Class Provider SCU Service Class User SOP Service-Object Pair

TCP/IP Transmission Control Protocol/Internet Protocol

UID Unique Identifier US Ultrasound

VA Department of Veterans Affairs VHA Veterans Health Administration VistA Veterans Health Information System Technology and Architecture VL Visible Light VOI Volume of Interest VPN Virtual Private Network VR Value Representation

XA X-Ray Angiography

1.5. HIMSS/RSNA IHE Initiative

The Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA) are sponsoring the IHE initiative to address similar interoperability issues. This effort has drawn participation from all leading commercial information and imaging systems vendors.

VA and DoD are in full support of the IHE effort and this document can be construed as essentially an interpretation of the IHE framework. The reader is directed to the IHE web site to obtain details on the scope of the project, its mission, and Technical Framework2

. The endorsement of the largest government-owned healthcare networks adds further momentum to the IHE project and signals the willingness of purchasers, vendors, and government software developers to work together toward interoperability.

This document references the Scheduled Workflow Integration Profile –Acquisition Modality and Archive Actor and Consistent Presentation of Images Integration Profile – Print Composer Actor as defined in the IHE Technical Framework document. This document is intended to augment the IHE document and provide implementation context. Procedural and definition details covered by IHE are not repeated by this document. This document also specifies several notable differences from the requirements set forth by the IHE Technical Framework; see Appendix B of this document. The reader is expected to be fully familiar with the concepts of the IHE Technical Framework. This document inherits the relationships, definitions and nomenclature established by the IHE Technical Framework.

2 For more information, please see the appropriate sections of the IHE Technical Framework rev 6.0, 2005. HIMSS/RSNA Integrating the Healthcare Enterprise Technical Framework, available at /www.ihe.net/Technical_Framework/ web site.

September 28, 2005 Version 3.0 Page 5

1.6. Hierarchical Integrated Data Model

The Data Consistency Model as defined by the IHE Technical Framework (see Figure 1) is generally followed, although there are a few specializations with regard to the multiplicity of the relationships between the various blocks in the diagram. These are described in detail under the corresponding transaction specifications.

The DoD Data Model will follow the IHE Technical Framework. CHCS II will associate the image order with a number of Requested Procedures that have to be performed to satisfy the order. Each Requested Procedure prescribes a number of actions that have to be performed by Digital Acquisition Modalities.

Imaging Service Request/

Filler Order

Patient 0-n

Requested Procedure Ref. St. Seq. [2]

{Req. Pr. ID}

{Study Instance UID}

1-n Conceptual Study Mgt.

{Study SOP Instance UID}

1-n

Scheduled Procedure Step

{Sch. Pr. ID}

Composite (e.g. Images, GSPS) SOP Instance

Performed Proc. Step

St. Inst. UID [1] Ref. St. Seq.

{Perf. Proc. Step SOP Instance UID}

Series Inst.

UID [1]

Image. Inst. UID [1]

0-n

0-m 1-n

I-Patient

1-n

I-Study

Ref. St. Seq. [3]

St. Inst. UID [1]

0-n

0-m

1 1

1-n

I-Series

Ref. St. Comp. Seq. [3] {Series Inst. UID [1]}

Req. Pr. ID (2/3) Sch. Pr. St. ID [2/3]

I-Composite

0-n

{SOP Instance UID [1]}

0-1 1-n

0-n

*** This relationship may not exist “0-1 to n” but “0-n to m” when multiple Scheduled Procedure Steps are satisfied by one Performed Procedure Step.

Legend:

{xxx} : An Attribute which is a unique identifier (DICOM UID) or an identifier (DICOM ID) or for the entity yyy : An Attribute which is used in the entity to reference another entity as show by the associated arrow.

[n] : The Attribute Type as defined by DICOM for this entity (IHE may strengthen this requirement) : A relationship between two entities using a unique identifier (DICOM UID) : A bidirectional relationship between two entities using a pair of unique identifiers (DICOM UID) : A relationship between two entities using a simple identifier (DICOM ID) n-m : Cardinality of the relationship between the entitties, not the identifiers. (Direction of the arrow is irrelevant to cardinality.)

Sch. Pr. ID 1 1

0-m 0-n

0-n

Figure 1 Data Consistency Model 3

3 REFERENCE: IHE TECHNICAL FRAMEWORK, VOL 2, VER 6.0, FIGURE A-1. Data Consistency Model: Modality Worklist Information Model, Composite IODs and Modality Performed Procedure Step IOD.

September 28, 2005 Version 3.0 Page 6

1.7. DICOM Digital Acquisition Modality Interface Architectures

VA currently supports two different architectures with regard to DICOM digital acquisition modality interfaces, depending on whether a commercial PACS system or the VA VistA PACS solution is used.

The modalities shall perform the same functions, whether they directly interface with VistA Imaging or interface through a commercial PACS. This document defines the domain of specification strictly as the point of interface between the modality and the PACS.

MHS supports only Architecture A. It is the intent of the MHS to utilize commercial PACS architectures at military medical and dental treatment facilities for image management and distribution. Through an interface with the CHCS II CDR and the Defense Enrollment Eligibility Reporting System (DEERS), CHCS II will provide patient demographic information. Through an interface with the Enterprise Wide Scheduling (EWS) System, CHCS II will provide scheduling information on imaging equipment, rooms, providers, and staff.

Architecture A has three high level components, the Modality itself, the VistA or CHCS II Information System, and a commercial PACS. In this architecture, the Modality will interface with VistA or CHCS II Information system to obtain patient demographic information and to a Commercial PACS to exchange images and image management information.

Figure 2 Architecture A: Using a commercial PACS

In Architecture B, the PACS is incorporated within the VistA Information system. From a modality functional perspective there is no real difference between Architecture A and Architecture B. The interface from the modality to a commercial PACS is now used between the modality and the VistA Information System.

The domain of this specification (that is, the DICOM interface of the modality) is identified in Figure 2 and Figure 3 by the shaded area.

Figure 3 Architecture B: Using the VistA Imaging System as the PACS

Commercial

PACS

Scheduling Info, Patient

Demographic Information

Images and Image Management

Information Domain of

Specification

VistA or CHCS II Modality

September 28, 2005 Version 3.0 Page 7

2. REQUIRED AND OPTIONAL IHE PROFILES

2.1. Integration Profile

A modality shall support all of the transactions as defined by the IHE as part of the Scheduled Workflow Integration Profile (see Table 1 below, which is a subset of Table 3.1-1 from the IHE Technical Framework, Vol 1, Ver 6.0). This section describes the minimal required IHE profiles. Individual VA/DoD organizations may elect to mandate requirements which are listed as optional or are not present within this document and its associated annexes.

Note that the Modality Images Stored transaction is supported as two actors, that is, the modality can either send or (optionally) receive the images. The latter might be needed for some modalities when comparing a study with a previous one.

Table 1 Scheduled Workflow Integration Profile - Actor and Transactions

Actors Transactions Requirement IHE Section Acquisition Modality Query Modality Worklist Mandatory * 4.5

Modality Procedure Step In Progress Mandatory * 4.6 Modality Procedure Step Completed Mandatory 4.7 Modality Images Stored Mandatory 4.8 Storage Commitment Mandatory 4.10 Verification Mandatory N.A. **

Image Archive Modality Images Stored Optional 4.8

* The optional features for this transaction are described in the referenced section of the IHE Technical Framework.

** The VA’s experience is that the Verification Transaction is critical in order to effectively troubleshoot and support these systems.

2.2. Print Profile (Optional)

A modality shall support the transactions as defined by the IHE as part of the Consistent Presentation of Images Integration Profile for the Print Composer Actor (see Table 2, which is a subset of Table 5.1-1 from the IHE Technical Framework, Vol 1, Ver 6.0).

Table 2 Consistent Presentation of Images Integration Profile - Actors and Transactions

Actors Transactions Requirement IHE Section Print Composer Print Request with Presentation LUT Optional 4.23

September 28, 2005 Version 3.0 Page 8

3. GENERAL REQUIREMENTS

3.1. Service-Object Pair (SOP) Class Support to Implement IHE Profiles

To comply with the mandatory profiles specified above, an acquisition modality is required to support the following SOP Classes, with their specified role (Service Class User (SCU)/Service Class Provider

(SCP)).

Table 3 Required SOP Classes

SOP CLASS NAME SOP CLASS UID USAGE

Modality Worklist Information Model Find 1.2.840.10008.5.1.4.31 SCU Modality Performed Procedure Step SOP class 1.2.840.10008.3.1.2.3.3 SCU Storage Commitment Push Model SOP Class 1.2.840.10008.1.20.1 SCU Modality Storage SOP Class (depends on modality Type, for example, CT, MR, and so forth)

1.2.840.10008.5.x.x.x.x SCU

Verification SOP Class 1.2.840.10008.1.1 SCU

To further comply with the optional profiles specified above, an acquisition modality may support the following SOP Classes, with their specified role (SCU/SCP).

Table 4 Optional SOP Classes

SOP CLASS NAME SOP CLASS UID USAGE

Modality Storage SOP Class (depends on modality Type, for example, CT, MR, and so forth)

1.2.840.10008.5.x.x.x.x SCP

Verification SOP Class 1.2.840.10008.1.1 SCP Basic Grayscale Print Management Meta SOP Class 1.2.840.10008.5.1.1.9 SCU Basic Color Print Management Meta SOP Class 1.2.840.10008.5.1.1.18 SCU Presentation LUT SOP Class 1.2.840.10008.5.1.1.23 SCU

If equipment does support these optional DICOM services, it should do so in a fashion that satisfies the requirements in this document.

3.2. Association Behavior

DICOM services may be implemented using multiple Application Entities (AEs). Each AE supports the Verification SOP class (as a SCU/SCP) and one or more additional SOP classes.

Separate AE support: The modality SCUs utilizing the services of the SCPs shall be prepared to support each service class residing on a separate AE in the VA environment, and be capable of configuring this accordingly.

The configuration of each modality SCU to use a different AE SCP with a different, unique, AE title for each of the SOP Classes (Storage, Modality Worklist, Modality Performed Procedure Step, and Storage Commitment) provides the greatest flexibility for the modality when interfacing to different system configurations. This is consistent with the implicit assumption of the IHE model depicted in the IHE Technical Framework document.

September 28, 2005 Version 3.0 Page 9

Port numbers: The modality shall be capable of utilizing the full 16-bit range (1-65535) of port numbers.

Restricted Numbers: The port numbers allocated by Request for Comments (RFCs) shall not be used for DICOM communications, with the exception of port 104.

4. SPECIFICATION OF INDIVIDUAL TRANSACTIONS

The following additions and/or specializations of the various transactions are described for the modalities.

4.1. Modality Worklist Provided (Mandatory)

The DICOM Modality Worklist service allows a modality to query for Patient and Study information (that is, issue a “C-FIND” request).

4.1.1. Hierarchical Integrated Data Model

The IHE Data Consistency Model (that is, the Modality Worklist Information Model, Image and Standalone Information Object Definitions (IODs) and Modality) Performed Procedure Step IOD is followed with the following specialization:

• The VA mapping from Imaging Service Request to Requested Procedure is 1:1, not 1:n. That is, a study has a single accession number that maps to a single procedure that maps to a single requested procedure step.

• The DoD mapping from Imaging Service Request to Requested Procedure is 1:n, which means that a single Accession number may contain one or more Requested Procedures.

Consistent with IHE, the Scheduled Procedure Step ID is meaningful for requested procedures resulting in multiple performed steps on the same or different modalities. An example would be a composite fluoroscopic study where the same device is used to take a set of supporting CR images.

4.1.2. Query Support

The modality shall initiate a query by supplying one or more matching keys. These can either be manually entered at a keyboard or come from an electronic scanning device (a barcode scanner, for example).

Modality Worklist (MWL) Query support: The modality shall support BOTH the Patient Based and the Broad Query4 with the keys that are specified for this transaction (see tables as specified in the IHE below for your reference).

The timing of the Modality Worklist query is important to obtain information on new procedures. In radiology, an “arrival event” is produced when the radiology staff takes responsibility for the study and registers the patient in the department. Because of the way radiology information systems (RISs) work, the “arrival event” is the first notification that a Modality Worklist provider receives about a study. The

4 IHE Technical Framework, Vol 2, Ver 6.0: Section 4.5.4.1.2, Examples for the Use of Matching Key Attributes.

September 28, 2005 Version 3.0 Page 10 most efficient use of Modality Worklist facility is to perform a single query shortly after the patient has been registered. A query prior to the arrival event produces negative results.

4.1.2.1. The Patient Based Query

This is the Query for a Worklist, specific for a particular patient.

Query by Patient matching key attributes: The SCU shall support all 15 combinations of the matching key attributes listed in the Table 5 by including one or more keys.

Table 5 MWL Keys for Query by Patient

Matching Key Attributes Tag Patient's Name (0010,0010) Patient ID (0010,0020) Accession Number (0008,0050) Requested Procedure ID (0040,1001)

Certain types of examinations can only be retrieved with explicit single value accession number queries.

An example of this type of query is selecting a previously performed radiology study for scanning on a film digitizer. Fewer selection errors are made when Patient Based Queries are used rather than Broad Queries.

Single Value matching: The Accession Number or Requested Procedure ID shall be retrieved with Single Value Matching (that is, wildcard matching shall not be allowed; an error shall be returned). Note that this is a DICOM specialization.

4.1.2.1.1. Shortcut Matching Keys in Modality Worklist Patient Based Queries

The VA hospital information system (HIS) and radiology information system (RIS) support “shortcut” representations of patient and study identifiers to minimize the amount of data entered, reducing keystrokes and errors. As an example, the VA uses a “quick-pid” patient identifier shortcut, which consists of the initial of the patient’s last name, followed by the last four digits of the social security number (R1234, for instance). This value is a convenient hash on the whole patient list, and usually matches only one or two patients at a time. It is much easier to remember and enter than the nine-digit social security number or the exact spelling of the patient’s name. For another example, the VA RIS uses two formats for the accession number, a shortcut called the “case number” which consists of a series of digits (something like 1025), and a “date case number” which consists of the date (in mmddyy format) followed by the case number (something like 102198-1025). The radiology staff only uses the case number when dealing with active studies, and always uses the date case number for referencing historical ones.

To make these shortcuts available at the modality, the VA has implemented them in its MWL SCP. The VA requires the DICOM Modality Worklist user to support this capability. The modality should be able to use a “shortcut” value in a field to do a query and accept results where the “shortcut” value is replaced by a “full” value (in the above examples, the full patient name, patient ID, or study accession number).

DoD is developing requirements for “shortcut” representations and supports the VA approach.

Ignore matching key checking: The modality shall accept the results of a query when the returned full key(s) are different than the matching short cut keys specified in the query. The modality shall not indicate an error condition and reject the results when they are different.

September 28, 2005 Version 3.0 Page 11

4.1.2.2. Broad Modality Worklist Query

This is a Query for a broad Worklist.

Broad Query matching key attributes: The SCU shall support all seven combinations of the matching key attributes listed in Table 6 by including one or more keys.

Table 6 MWL Keys for Broad Worklist Queries

Matching Key Attributes Tag Scheduled Station AE Title (0040,0001) Scheduled Procedure Step Start Date (0040,0002) Modality (0008,0060)

MWL polling: Issuing frequent periodic Broad Queries to the Modality Worklist provider (that is, “polling”) to retrieve patient data has proven to be inefficient. It is therefore not allowed as the primary method for obtaining such data. Broad Queries initiated by the user on demand are preferred to polling.

4.1.2.3. Selection and Display Requirements for All MWL Queries

A major issue surfaced early in implementations of Modality Worklist within the VA. In some modality implementations, the design of the user interface made it relatively easy to select the wrong patient information to associate with a particular image. The result was a mismatch of the patient demographic data and image(s), with serious effects on data integrity and potentially adverse effects on patient safety. 5

The selection of the appropriate patient and order information on most modalities is a two-step process.

After a MWL query, there is usually a "pick-list" displayed on the screen that clearly identifies the patients and orders so that an unambiguous selection can be made. Upon selecting an entry from this pick-list, more detailed information is displayed and the technologist verifies that the correct patient and order has been selected. The IHE Technical Framework specifies the list of MWL attributes6 that are required to be displayed, but does not indicate when and under what circumstances these attributes are to be displayed.

Sufficient data display: The following minimum list of patient/study data items need to be displayed (in a pick-list) at the modality in order to properly identify scheduled procedure steps to the user:7

Table 7 Required Attributes to be Displayed for MWL

Displayed attribute Tag Patient's Name (0010,0010) Patient ID (0010,0020) Accession Number (0008,0050) Scheduled Procedure Step Sequence* (0040,0100) > Scheduled Procedure Step Description (0040,0007) Scheduled Procedure Step Start Date (0040,0002)

5 Kuzmak PM and Dayhoff RE: Minimizing Digital Imaging and Communications in Medicine (DICOM) Modality Worklist Patient/Study Selection Errors, Journal of Digital Imaging, Vol 14, No 2 Suppl 1 (June), 2001: pp 153-157.

6 IHE Technical Framework, Vol 2, Rev 6.0: Section 4.5.4.1.2.2 Matching Keys and Return Keys for Display.

7 Gale ME, Gale DR: DICOM Modality Worklist: An Essential Component in a PACS Environment, Journal of Digital Imaging, Vol 13, No 3 (August) 2000: pp 101-108.

September 28, 2005 Version 3.0 Page 12

Displayed attribute Tag Requested Procedure ID (0040,1001)

*(0040,0100) is the “sequence container”, and is obviously not to be displayed.

MWL data verification: After the user query, it is mandatory that the user interface requires a second patient/study identification verification step to ensure that the images are matched to the correct patient.

Support for multiple Studies for a patient: The modality shall be able to handle multiple studies for the same patient, where each study may have a different Accession Number.

MWL Attribute support: The vendor shall support the keys as specified in IHE8

. This particular table summarizes the matching key requirements and lists the optional and required attributes that shall be requested and shall be returned in order to make these available to the user at the Acquisition Modality.

Display of Attributes: The modality shall conform to the display requirements for all attributes listed in IHE9

, which are an addition to the DICOM Standard requirements for the Modality Worklist SOP Class.

Requiring “Other Patient IDs”: The Other Patient IDs (0010,1000) may be used to store the VA Master Patient Index for the patient. In the near future, this element may be required to be obtained from the Modality Worklist Provider and stored in every image.

Additional Attributes: Table 8 lists additional attributes that are available as non-matching return keys. These attributes may be necessary for some digital acquisition modalities.

Table 8 Additional MWL Attributes (Optional)

Additional Attributes Tag Patient's Address (0010,1040) Scheduled Procedure Step Status – Defined Terms:

CREATED – order placed but not yet scheduled SCHEDULED – scheduled but not yet started ARRIVED – patient arrived but study not started STARTED – study started but not yet finished COMPLETED – completed VERIFIED – completed and image quality verified

(0040,0020)

Scheduled Procedure Step Sequence (0040,0100) > Scheduled Procedure Step Location (0040,0011) Requested Procedure Priority (0040,1003) Intended Recipients of Results (0040,1010)

The complete mapping of VistA and CHCS II database elements to the DICOM Modality Worklist is specified in Appendix A of this document.

7 IHE Technical Framework, Vol 2, Rev 6.0: Table 4.5-3 Return and Matching Keys For Modality Worklist.

9 IHE Technical Framework Vol 2, Rev 6.0: Section 4.5.4.1.2.2 Matching Keys and Return Keys for Display.

September 28, 2005 Version 3.0 Page 13

4.2. Modality Procedure Step In Progress (Mandatory)

The Modality Performed Procedure Step messages shall indicate the authoritative start of the procedure step (start of digital acquisition) and the completion or cancellation of the procedure step (end of digital acquisition), consistent with the IHE generic use case10

. The Modality Performed Procedure Step N―CREATE event can be used by the Modality Worklist SCP to prevent other modalities from starting the same procedure step.

4.3. Modality Procedure Step Completed (Mandatory)

The Modality Performed Procedure Step (MPPS) Complete N-SET message can be used to indicate that the Scheduled Procedure Step is eligible for removal from the Worklist.

4.4. Modality Images Stored – Acquisition Actor (Mandatory)

The primary function of a Modality is to acquire images. The DICOM Storage service is required in order to send image objects to specific destinations.

4.4.1. Specific SOP Class requirements

4.4.1.1. General Storage Requirements

The following general requirements apply for the Storage SOP Class support:

True SOP Class support: A modality may optionally support the Secondary Capture SOP class in addition to its “true” SOP class such as Digital Radiology (DX), X-Ray Angiography (XA), Visible Light (VL), CT, MR, and Positron Emission Tomography (PET) Scan. Support of Secondary Capture ONLY is not sufficient (except for Film Digitizer modalities).

Support of retired SOP Classes: Support of the retired NM and US Image Storage SOP classes is optional; support of the new NM and US SOP classes is required.

Support of Multiframe for Ultrasound: Ultrasound devices should also support the US

Multiframe Storage SOP Class in addition to the regular US SOP Classes.

DX support: Computed Radiography modalities are required to support the DX SOP Classes in addition to the CR SOP Class.

CR modalities can send the images either with a look up table (LUT) or apply the LUT to the image data and send an image that is presentable “as is”. For a CR viewing station, which is capable of generating different LUTs, and accommodating these accordingly, it makes sense to receive the images with the LUT. For general-purpose workstations, accommodating this LUT might be an unnecessary burden.

Applied LUT support for CR : If a CR/DX device is capable of sending images with one or more modality and/or Value of Interest (VOI) LUTs as part of the object, they shall be configurable to also send the images with the LUT already applied to the pixel data and omit the transmission of the LUT.

10 IHE Technical Framework, Vol 1, Rev 6.0: Figure 3.3-2. Procedure Performance Process Flow.

September 28, 2005 Version 3.0 Page 14

Processed data for CR objects: If a CR/DX device is capable of sending unprocessed (also known as “raw”) data in its CR object, it shall also be configurable to send processed data, that is, apply all pixel transformations so that the data is viewable without any addition processing at a workstation.

Note that the latter requirement only applies for CR objects, this is solved for modalities that support DX, because these are required to support the For Presentation SOP Class as a baseline anyway.

4.4.1.2. Modality Modes of Operation

When sending the images, the Modality shall support all of the following modes of operation:

Send images to multiple destinations: The modality shall be able to send images to different destinations, which shall be operator selectable.

Select image subset: The operator shall be able to select a study or a subset of clinically significant images to be sent to a specific destination. This is especially important for Angiography, Cardiology, and Ultrasound.

The modality shall support the following capabilities:

Auto-send: The modality shall send images automatically without any operator interaction to its destinations during the acquisition (send as you go).

Manual-send: The modality shall send images to its destination initiated by an operator at the modality (manual mode).

Time-out send: The modality shall be capable of sending images automatically after a pre-determined period of time if the images were not sent manually prior to the expiration of the interval timer. This capability shall be configurable so that it can be selectively enabled and overridden when the user does not want to send the images.

Retry send: The modality shall retry failed transmission either automatically or initiated by the operator. The modality shall log all transmission failures and notify the operator of the events.

4.4.1.3. Study Instance Unique Identifier (UID), Series Instance UID, and SOP Instance UID

The Modality Worklist provider shall use the Study Instance UID that is supplied by the HIS/RIS, and the Modality shall use the Study Instance UID that is supplied by the Modality Worklist provider. This Study Instance UID is assumed to be unique. These requirements allow the images to be properly related to the Study within the HIS/RIS and/or PACS.

Study Instance UID uniqueness: When the Modality Worklist provider is not available, the Study Instance UID shall be generated at the modality, and the modality shall guarantee that this value is unique for the particular object it generates.

Study Instance UID integrity: If a particular SOP Instance is sent again later from a particular modality, the same Study Instance UID shall be used to identify the Study.

The Series Instance UID and SOP Instance UID are assigned by the modality and permanently identify the Series and instance objects. By definition, they must be unique for each Series and instance object respectively. Because it cannot provide uniqueness, the modality shall not use a Study Instance UID obtained from Modality Worklist as the root UID for the generation of the Series Instance UID and SOP Instance UID. Rather, the modality shall use its own UID root to generate these values, so that uniqueness can be ensured.

September 28, 2005 Version 3.0 Page 15

Series Instance UID integrity: If a particular SOP Instance is sent again later from a particular modality, the same Series Instance UID shall be used to identify the Series.

SOP Instance UID integrity: The SOP Instance UID is not allowed to be subsequently changed, for example, when the same image is re-sent from the modality.

New SOP Instance UID generation: When the image object is modified and clinically significant changes are made, the modality shall create a new instantiation (that is, a new image object with a new SOP Instance UID). Additional instantiations received with the same UID will be ignored by the VistA system.

4.4.1.4. Presentation Context

Table 9 Proposed Presentation Context for all Storage SOP classes

Presentation Context Table Abstract Syntax Transfer Syntax Role Extended

Name UID Name List UID List Negotiation See Note 1 See Note 1 Implicit VR Little Endian 1.2.840.10008.1.2 SCU None See Note 1 See Note 1 Explicit VR Little Endian 1.2.840.10008.1.2.1 SCU None Note 1: Applicable for all Storage SOP classes

The preferred Transfer…