Lumify 1.8.x DICOM Conformance Statement

Transcription

1 Lumify 1.8. DICOM Conformance Statement Lumify Rev A Koninklijke Philips Electronics N.V All rights are reserved. Lumify 1.8. DICOM Conformance Statement 1

2 0.1 Revision History REVISION HISTORY Description Rev A (Initial Release) Lumify 1.8. DICOM Conformance Statement 2

3 1 CONFORMANCE STATEMENT OVERVIEW The Philips Lumify 1.8. Ultrasound systems implement the necessary DICOM services to download worklists from an information system, save acquired US Images to a network storage device and inform the information system about the work actually done. Table 1 provides an overview of the supported network services. TABLE 1 NETWORK SERVICES Networking SOP Classes User of Service (SCU) Provider of Service (SCP) Transfer Ultrasound Image Storage Yes No Ultrasound Multiframe Image Storage Yes No Secondary Capture Image Storage* Yes No Storage Commitment Push Model Yes No Workflow Management Modality Worklist Yes No Modality Performed Procedure Step Yes No *Secondary Capture is only used for images acquired of analysis and calcs results pages. It is not configurable. DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information. Lumify 1.8. DICOM Conformance Statement 3

4 2 TABLE OF CONTENTS 0.1 Revision History CONFORMANCE STATEMENT OVERVIEW TABLE OF CONTENTS INTRODUCTION AUDIENCE REMARKS Important Note to the Reader DEFINITIONS, TERMS AND ABBREVIATIONS REFERENCES NETWORKING IMPLEMENTATION MODEL Application Data Flow Functional Definition of AEs Functional Definition of Storage Application Entity Functional Definition of Workflow Application Entity Sequencing of Real-World Activities AE SPECIFICATIONS Storage Application Entity Specification SOP Classes Association Establishment Policy General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Activity Store Images and Loops Description and Sequencing of Activities Proposed Presentation Contets SOP Specific Conformance for Image SOP Classes Image Storage SOP Classes SOP Specific Conformance for Storage Commitment Push Modle SOP Class Association Acceptance Policy Activity Receive Storage Commitment Response Description and Sequencing of Activities Accepted Presentation Contets SOP Specific Conformance for Storage Commitment Push Model SOP Class Storage Commitment Notifications (N-EVENT-REPORT) Storage Commitment Attributes (N-EVENT-REPORT) Workflow Application Entity Specification SOP Classes Association Establishment Policy General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Activity Worklist Update Description and Sequencing of Activities Lumify 1.8. DICOM Conformance Statement 4

5 Proposed Presentation Contets SOP Specific Conformance for Modality Worklist Activity Acquire Images Description and Sequencing of Activities Proposed Presentation Contets SOP Specific Conformance for MPPS Association Acceptance Policy Verification Application Entity specification SOP Class Association Establishment Policy General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policy Activity Verify as SCU Description and Sequencing of Activities Proposed Presentation Contets SOP Specific Conformance for Verification Association Acceptance Policy Activity Verification as SCP Description and Sequencing of Activities Accepted Presentation Contets SOP Specific Conformance for Verification PHYSICAL NETWORK INTERFACES Supported Communication Stacks TCP/IP Stack Physical Network Interface Additional Protocols IPv4 and IPv6 Support CONFIGURATION AE Title/Presentation Address Mapping Local AE Title Remote AE Title/Presentation Address Mapping Workflow MEDIA STORAGE SUPPORT OF CHARACTER SETS SECURITY ANNEXES CREATED IOD INSTANCES US or US Multiframe Image IOD Secondary Capture IOD Common Modules US or Multiframe Image Modules USED FIELDS IN RECEIVED IOD BY APPLICATION ATTRIBUTE MAPPING CONTROLLED TERMINOLOGY EXTENSIONS / SPECIALIZATIONS / PRIVATIZATIONS Lumify 1.8. DICOM Conformance Statement 5

6 3 INTRODUCTION 3.1 AUDIENCE This document is intended for hospital staff, health care system integrators, software designers or implementers. It is assumed that the reader has a working understanding of DICOM. 3.2 REMARKS DICOM, by itself, does not guarantee interoperability. However, the Conformance Statement facilitates a firstlevel validation for interoperability between different applications supporting the same DICOM functionality. This Conformance Statement is not intended to replace validation with other DICOM equipment to ensure proper echange of information intended. The scope of this Conformance Statement is to facilitate communication between the Philips Healthcare Lumify 1.8. ultrasound systems and other vendors Medical equipment. The Conformance Statement should be read and understood in conjunction with the DICOM Standard [DICOM]. However, by itself it is not guaranteed to ensure the desired interoperability and successful interconnectivity. The user should be aware of the following important issues: The comparison of different conformance statements is the first step towards assessing interconnectivity between Philips Healthcare and non - Philips Healthcare equipment. Test procedures should be defined to validate the desired level of connectivity. The DICOM standard will evolve to meet the users future requirements. Philips Healthcare is actively involved in developing the standard further and therefore reserves the right to make changes to its products or to discontinue its delivery. 3.3 Important Note to the Reader Interoperability Interoperability refers to the ability of application functions, distributed over two or more systems, to work successfully together. The integration of medical devices into an IT environment may require application functions that are not specified within the scope of DICOM. Consequently, using only the information provided by this Conformance Statement does not guarantee interoperability of Philips equipment with non-philips equipment. It is the user s responsibility to analyze thoroughly the application requirements and to specify a solution that integrates Philips equipment with non-philips equipment. Validation Philips equipment has been carefully tested to assure that the actual implementation of the DICOM interface corresponds with this Conformance Statement. Where Philips equipment is linked to non-philips equipment, the first step is to compare the relevant Conformance Statements. If the Conformance Statements indicate that successful information echange should be possible, additional validation tests will be necessary to ensure the functionality, performance, accuracy and stability of image and image related data. It is the responsibility of the user (or user s agent) to specify the appropriate test suite and to carry out the additional validation tests. New versions of the DICOM Standard The DICOM Standard will evolve in future to meet the user s growing requirements and to incorporate new features and technologies. Philips is actively involved in this evolution and plans to adapt its equipment to future versions of the DICOM Standard. In order to do so, Philips reserves the right to make changes to its products or to discontinue its delivery. The user should ensure that any non-philips provider linking to Philips equipment also adapts to future versions of the DICOM Standard. If not, the incorporation of DICOM Lumify 1.8. DICOM Conformance Statement 6

7 enhancements into Philips equipment may lead to loss of connectivity (in case of networking) and incompatibility. 3.4 DEFINITIONS, TERMS AND ABBREVIATIONS Definitions, terms and abbreviations used in this document are defined within the different parts of the DICOM standard. Abbreviations and terms are as follows: AE AET DICOM IOD ISO MWL R O PDU PDE SCP SCU SOP U US DICOM Application Entity Application Entity Title Digital Imaging and Communications in Medicine (DICOM) Information Object Definition International Standard Organization Modality Worklist Required Key Attribute for Modality Worklist Query Matching Optional Key Attribute for Modality Worklist Query Matching DICOM Protocol Data Unit Patient Data Entry DICOM Service Class Provider (DICOM server) DICOM Service Class User (DICOM client) DICOM Service-Object Pair Unique Key Attribute for Modality Worklist Query Matching, or Optional Attribute Ultrasound 3.5 REFERENCES DICOM] Digital Imaging and Communications in Medicine, Parts 1-20 (NEMA PS 3.1- PS 3.20), National Electrical Manufacturers Association (NEMA) Publication Sales 1300 N. 17th Street, Suite 1752 Rosslyn, Virginia , United States of America Internet: Note that at any point in time the official standard consists of the most recent yearly edition of the base standard plus all the supplements and correction items that have been approved as Final Tet. Lumify 1.8. DICOM Conformance Statement 7

8 4 NETWORKING 4.1 IMPLEMENTATION MODEL Application Data Flow Figure 1 APPLICATION DATA FLOW DIAGRAM The Storage Application Entity sends Images to a single remote AE. Acquisition of images is associated with the local real-world activity Save Image for single frame and Save Loop for loops or clips. Sending of images may occur automatically when configured to do so, either as images are acquired or upon eam completion. The system can also be configured to automatically end and send an eam after a specified eam duration. In addition, eam data may be sent manually upon request of the user. If configured to send as images are acquired, images are transferred immediately after acquisition and reports are transferred at the end of the eam. If configured for send upon eam completion, images report images are transferred when the eam is ended. The Workflow Application Entity receives Modality Worklist (MWL) information from and sends Modality Performed Procedure Step (MPPS) information to remote AEs. It is associated with the local real-world activities Query Worklist and Acquire Images. When the Update Worklist local real-world activity is performed, the Workflow Application Entity queries a remote AE for worklist items and provides the set of worklist items matching the query request. Update Worklist is performed as a result of an operator request. Patient Search is manually initiated Functional Definition of AEs Functional Definition of Storage Application Entity A Network Store queue with associated network destination will activate the Storage AE. An association request is sent to the destination AE and upon successful negotiation of a Presentation Contet the image transfer is started. If the association cannot be opened, the related queue s Status is set to Stopped as displayed in the Eport Queue. The user may select 8 Lumify 1.8. DICOM Conformance Statement

9 Retry Job to attempt re-send. After the automatic retries have failed, the job is set to Aborted. The user may Delete Job and re-send manually. Deleting a job does not remove the data, as it is still present on the system. Only the request to transfer the data is removed. Once any communication issues have been resolved, Retry Job may be selected or if the jobs were deleted, they may be queued again from the Review directory Functional Definition of Workflow Application Entity Query MWL attempts to download a Modality Worklist from a Modality Worklist server with studies matching the search criteria by sending a C-Find Request containing user-definable Query parameters. Query parameters are stored in the Setup MWL Server Dialog. Note: Either Broad Worklist Query or Patient Based Query can be configured at a time. Settings that may be customized are: o o o o Start Date (Today, within 1 day, within 7 days, within 30 days) AE Title (This system, Any or Another specific) Modality (Ultrasound or All Modalities) Perform Patient Based Queries (Allows user to enter Patient Name, Patient ID (MRN), Accession Number and/or Requested Procedure ID to be queried. When the Workflow AE establishes an association to a remote AE, a MWL C-Find-Rq message is sent to the MWL server. The server will transfer all matching worklist items via the open association. The results of a successful Worklist Update will overwrite the data in the Worklist display. There is no queue management for Modality Worklist; Modality Worklist queries only occur on demand. Modality Performed Procedure Steps are created and updated with the following real-world events: o MPPS N-Create, Status = IN PROGRESS: Acquisition of images will result in automated creation of an MPPS Instance managed by a remote AE. o MPPS N-Set, Status = COMPLETE Completion of the MPPS is performed as the result of an operator action of ending the eam. o MPPS N-Set, Status = DISCONTINUED Cancel Eam causes the Discontinued status to be sent Sequencing of Real-World Activities The following sequence diagrams illustrate the order of network operations during a number of imaging scenarios. If Modality Worklist is not being used, the user enters patient identification manually at the start of eam and the Query/Retrieve Worklist steps do not occur. Figures 2 and 3 illustrate eam acquisition with send as images are acquired or upon eam completion. Respectively. 9 Lumify 1.8. DICOM Conformance Statement

10 Figure 2 Sequencing Constraints Configured to Send as Images are Acquired 10 Lumify 1.8. DICOM Conformance Statement

11 Figure 3 Sequencing Constraints Configured to Send upon eam completion Note: Lumify does not eport images if Cancel Eam (resulting in step 6 Discontinued MPPS ) is selected and Store at End of Eam is configured. Images acquired during a cancelled eam are stored in the database and may be manually eported. 11 Lumify 1.8. DICOM Conformance Statement

12 4.2 AE SPECIFICATIONS Storage Application Entity Specification SOP Classes Table 1 SOP CLASSES FOR AE STORAGE SOP Class Name SOP Class UID SCU SCP US Image Storage Yes No US Multiframe Image Storage Yes No Secondary Capture Image Storage Yes No Association Establishment Policy General The DICOM standard application contet name for DICOM 3.0 is always proposed: Table 2 DICOM APPLICATION CONTEXT FOR AE STORAGE Application Contet Name Number of Associations Lumify 1.8. initiates one Association at a time for each destination to which a transfer request is being processed in the active job queue list. TABLE 3 Number of Associations Initiated for AE Storage Maimum number of simultaneous Associations Asynchronous Nature Lumify 1.8. does not support asynchronous communication (multiple outstanding transactions over a single Association). TABLE 4 Asynchronous Nature as a SCU for AE Storage Maimum number of outstanding asynchronous transactions Implementation Identifying Information The implementation information for this Application Entity is: TABLE 5 DICOM Implementation Class and Version for AE Storage Implementation Class UID Implementation Version Name LUMIFY_ Lumify 1.8. DICOM Conformance Statement

13 Association Initiation Policy Activity Store Images and Loops Description and Sequencing of Activities Images may be sent from the selected studies from the Review directory. Each image is sent in its own association that is opened and closed. Additional images acquired during the eam will be sent using subsequent associations. If the C-STORE response from the remote application contains a status other than Success or Warning, the association is retried until switched to a failed state. If a device is configured for Storage Commitment service, the Storage AE will transmit a single Storage Commitment N-ACTION request for images and, if present, the report images. The Storage AE can only receive an N- EVENT-REPORT request in a separate subsequent association initiated by the SCP. It cannot receive N-EVENT-REPORT request messages on the same association as the N-ACTION request. The sequence of interactions between the Storage AE and an Image Manager is illustrated in Figure 4 for the Store configuration option After Each Print/Acquire. If the At End Eam configuration option is selected, no C-STORE is sent at the Acquire Image event and instead all image C-STOREs are sent after end eam. 13 Lumify 1.8. DICOM Conformance Statement

14 Figure 4 SEQUENCING OF ACTIVITY SEND IMAGES AS THEY ARE ACQUIRED 14 Lumify 1.8. DICOM Conformance Statement

15 Proposed Presentation Contets Lumify 1.8. is capable of proposing the Presentation Contets shown in the following table: Table 6 PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY SEND IMAGES Abstract Synta Presentation Contet Table Transfer Synta Name UID Name List UID List US Image Storage US Multiframe Image Storage Secondary Capture Image Storage JPEG Lossy Baseline RLE Lossless JPEG Lossy Baseline RLE Lossless JPEG Lossy Baseline RLE Lossless Role SCU SCU SCU Et. Neg. None None None SOP Specific Conformance for Image SOP Classes Image Storage SOP Classes Storage (C-Store) All SOP Classes supported by the Storage AE ehibit the same behavior, ecept where stated, and are described together in this section. Table 7 describes C-Store response behavior. Establishing the Association with Default settings Service Status Table 7 STORAGE C-STORE RESPONSE STATUS HANDLING BEHAVIOR Further Meaning Error Code Behavior Success Success 0000 The SCP successfully stored the SOP Instance. If all SOP Instances scceed, the job is marked as complete. * * Any other status code The Association is aborted using A-ABORT and the transfer fails. The status is logged. During Image Transfer Timeout Eception Association aborted by the SCP or network layers Table 8 STORAGE C-STORE COMMUNICATION FAILURE BEHAVIOR Behavior The Association is aborted using A-ABORT and the transfer fails. The status is logged. The Association is aborted using A-ABORT and the transfer fails. The status is logged. 15 Lumify 1.8. DICOM Conformance Statement

16 The contents of US Image and US Multiframe Storage SOP Instances conform to the DICOM IOD definitions described in Section SOP Specific Conformance for Storage Commitment Push Modle SOP Class Storage Commitment Notifications (N-ACTION) The Storage AE will request storage commitment for the configured device. If Send images as they are acquired is selected, Storage Commitment is requested automatically by the system immediately after the instance is stored. Table 9 summarizes the behavior of the Storage AE when receiving response status codes Service Status Table 9 STORAGE COMMITMENT N-ACTION RESPONSE STATUS HANDLING BEHAVIOR Further Meaning Error Code Behavior Success Success 0000 The SCP successfully stored the SOP Instance. If all SOP Instances succeed, the job is marked as complete. * * Any other status code The Association is aborted using A-ABORT and the transfer fails. The status is logged. Table 10 summarizes the behavior of Storage AE during communication failure. Timeout Eception Table 10 STORAGE COMMITMENT N-ACTION COMMUNICATION FAILURE BEHAVIOR Behavior The Association is aborted using A-ABORT and the transfer fails. The status is logged. Association aborted by the SCP or network layers The Association is aborted using A-ABORT and the transfer fails. The status is logged. The Storage AE will request storage commitment using the attributes described in the following table. Table 11 STORAGE COMMITMENT N-ACTION REQUEST MESSAGE CONTENTS Action Type Name Request Storage Commitment Action Type ID Attribute 1 Transaction UID (0008,1195) 1 Tag Referenced SOP Sequence (0008,1199) 1 >Referenced SOP Class UID (0008,1150) 1 >Referenced SOP Instance UID (0008,1155) 1 Requirement Type SCU 16 Lumify 1.8. DICOM Conformance Statement

17 The N-ACTION request is retried if the N-ACTION has completed successfully but no N-EVENT-RESPONSE received within 96 hours. Further, the NACTION request is retried if N-EVENT-RESPONSE is received with one or more instances that fail commit; in that case, C-STORE requests are also resent for all instances that failed to commit Association Acceptance Policy Activity Receive Storage Commitment Response Description and Sequencing of Activities The Storage AE accepts associations for pending responses to a Storage Commitment Request only using SCP/SCU Role Negotiation of SCP eplicitly stating that the association is initiated by the SCP to the SCU Accepted Presentation Contets Table 12 summaraizes the Presentation Contets that the Storage AE accepts Table 12 ACCEPTABLE PRESENTATION CONTEXTS FOR ACTIVITY RECEIVE STORAGE COMMITENT RESPONSE Presentation Contet Table Abstract Synta Transfer Synta Name UID Name List UID List Storage Commitment Push Model Implicit VR Little Endian Eplicit VR Little Endian Role SCU Et. Neg. None SOP Specific Conformance for Storage Commitment Push Model SOP Class Storage Commitment Notifications (N-EVENT-REPORT) The Storage AE can receive an N-EVENT-REPORT notification received from the SCP via an association requested by the SCP with reverse-role negotiation. Table 13 summarizes the behavior of Storage AE when receiving Event Types within the N-EVENT-REPORT. Table 13 STORAGE COMMITMENT N-EVENT-REPORT BEHAVIOR Event Type Name Event Type ID Behavior Storage Commitment Request Successful Storage Commitment Request Complete Failures Eist 1 The commit status is set to complete for each object. 2 The commit status remains incomplete. The commit comment for each object is logged. The reasons for returning specific status codes in an N-EVENT-REPORT response are summarized in Table 14 Service Status Table 14 STORAGE COMMITMENT N-EVENT-REPORT RESPONSE STATUS REASONS Further Meaning Error Code Reasons Success Success 0000 The storage commitment result has been successfully received 17 Lumify 1.8. DICOM Conformance Statement

18 Storage Commitment Attributes (N-EVENT-REPORT) Table 15 Lists the attribtues that are supported within the N-EVENT-REPORT Event Type Name Storage Commitment Request Successful Event Type ID Table 15 STORAGE COMMITMENT N-EVENT-REPORT MESSAGE CONTENTS Attribute 1 Transaction UID (0008,1195) None Tag Referenced SOP Sequence (0008,1199) None >Referenced SOP Class UID (0008,1150) None Requirement Type SCU >Referenced SOP Instance UID (0008,1155) None Storage Commitment Request Successful 1 Transaction UID (0008,1195) None Referenced SOP Sequence (0008,1199) None >Referenced SOP Class UID (0008,1150) None >Referenced SOP Instance UID (0008,1155) None Failed SOP Sequence (0008,1198) None >Referenced SOP Class UID (0008,1150) None >Referenced SOP Instance UID (0008,1155) None Workflow Application Entity Specification SOP Classes Lumify 1.8. provides Standard Conformance to the following SOP Classes: Table 16 SOP CLASSES FOR AE WORKFLOW SOP Class Name SOP Class UID SCU SCP MWL Information Model FIND Yes No Modality Performed Procedure Step Yes No Association Establishment Policy General The DICOM standard application contet name for DICOM 3.0 is always proposed: Table 17 DICOM APPLICATION CONTEXT FOR AE WORKFLOW Application Contet Name Lumify 1.8. DICOM Conformance Statement

19 Number of Associations Lumify 1.8. initiates one Association at a time for a Worklist request. Table 18 NUMBER OF ASSOCIATIONS INITIATED FOR AE WORKFLOW Maimum number of simultaneous Associations Asynchronous Nature Lumify 1.8. does not support asynchronous communication. Table 19 ASYNCHRONOUS NATURE AS A SCU FOR AE WORKFLOW Maimum number of outstanding asynchronous transactions Implementation Identifying Information The implementation information for this Application Entity is: Table 20 DICOM IMPLEMENTATION CLASS AND VERSION FOR AE WORKFLOW Implementation Class UID Implementation Version Name LUMIFY_ Association Initiation Policy Activity Worklist Update Description and Sequencing of Activities Worklist queries for Modality (US) or All Modalities may be initiated by the user. 19 Lumify 1.8. DICOM Conformance Statement

20 Figure 5 SEQUENCING OF ACTIVITY WORKLIST UPDATE A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g. a device such as a RIS or HIS which supports the MWL SOP Class as an SCP) is illustrated in Figure 5: Proposed Presentation Contets Lumify 1.8. will propose Presentation Contets as shown in the following table: Table 21 PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY WORKLIST UPDATE Presentation Contet Table Abstract Synta Transfer Synta Name UID Name List UID List Modality Worklist Information Model FIND Eplicit VR Little Endian* Implicit VR Little Endian Eplicit VR Big Endian Role SCU Et. Neg. None 20 Lumify 1.8. DICOM Conformance Statement

21 *Note: If the worklist server accepts Eplicit VR Little Endian and Implicit VR Little Endian then Lumify 1.8. will use Eplicit VR Little Endian Transfer Synta SOP Specific Conformance for Modality Worklist Table 22 summarizes the behavior of Lumify 1.8. when encountering status codes in a MWL C-FIND response. A message query failed will appear on the user interface if Lumify 1.8. receives any other SCP response status than Success or Pending. Service Status Table 22 MODALITY WORKLIST C-FIND RESPONSE STATUS HANDLING BEHAVIOR Further Meaning Error Code Behavior Success Matching is complete 0000 The system replaced the worklist from the response. Refused Out of Resources A700 Failed Identifier does not match SOP Class A900 The Association is aborted using A-ABORT. The worklist is not replaced. Same as Refused above. Failed Unable to Process C000 CFFF Same as Refused above. Cancel Matching terminated due to Cancel request FE00 Pending Matches are continuing FF00 Continue. Pending * * Matches are continuing Warning that one or more Optional Keys were not supported FF01 Any other status code. The user is notified that a partial list was retrieved. The retrieved items can be displayed by user request. Continue. Same as Refused above. Table 23 summarizes the behavior of Lumify 1.8. during communication failure. Eception Table 23 MODALITY WORKLIST COMMUNICATION FAILURE BEHAVIOR Behavior Timeout Association aborted by the SCP or network layers Same as Service Status Refused in the table above. Same as Service Status Refused in the table above. Table 24 describes the Lumify 1.8. Worklist Matching Keys and requested attributes. Unepected attributes returned in a C-FIND response are ignored. Non-matching responses returned by the SCP due to unsupported optional matching keys are ignored. 21 Lumify 1.8. DICOM Conformance Statement

22 Module Name Attribute Name Scheduled Procedure Step Scheduled Procedure Step Sequence > Scheduled Station AE Title > Scheduled Procedure Step Start Date > Scheduled Procedure Step Start Time > Modality > Scheduled Performing Physician s Name 1 > Scheduled Procedure Step Description 2 > Scheduled Protocol Code Sequence 3 > Scheduled Procedure Step ID Requested Procedure Requested Procedure ID Reason for the Requested Procedure 4 Requested Procedure Description 5 Study Instance UID Referenced Study Sequence Requested Procedure Code Sequence Names of Intended Recipients of Results Imaging Service Request Accession Number Requesting Physician Referring Physician's Name 6 Reason for the Imaging Service Request 7 Patient Identification Patient s Name Patient ID Other Patient IDs Patient Demographic Patient s Birth Date Patient s Se Patient Size Ethnic Group Patient s Weight Patient Comments Table 24 WORKLIST MATCHING KEYS Tag VR M R D IOD (0040,0100) (0040,0001) (0040,0002) (0040,0003) (0008,0060) (0040,0006) (0040,0007) (0040,0008) (0040,0009) (0040,1001) (0040,1002) (0032,1060) (0020,000D) (0008,1110) (0032,1064) (0040,1010) (0008,0050) (0032,1032) (0008,0090) (0040,2001) (0010,0010) (0010,0020) (0010,1000) (0010,0030) (0010,0040) (0010,1020) (0010,2160) (0010,1030) (0010,4000) SQ AE DA TM CS PN LO SQ SH SH LO LO UI SQ SQ PN SH PN PN LO PN LO LO DA CS DS SH DS LT S S, R S S S S, * S, * Patient Medical Medical Alerts Additional Patient s History Pregnancy Status (0010,2000) (0010,21B0) (0010,21C0) LO LT US * = Wildcard matching The above table should be read as follows: Module Name: The name of the associated module for supported worklist attributes. Attribute Name: Attributes supported to build a Lumify 1.8. Worklist Request Identifier. Tag: DICOM tag for this attribute. VR: DICOM VR for this attribute. M: Matching keys for Worklist Update. An "S" indicates that Lumify 1.8. supplies an attribute value for Single Value Matching, R indicates a Range Value and * is for Wildcard matching. See section for setup location. 22 Lumify 1.8. DICOM Conformance Statement

23 R: Return keys. An "" indicates that Lumify 1.8. supplies this attribute as a Return Key with zero length for Universal Matching. D: Displayed keys. An indicates that this worklist attribute is displayed to the user in the Patient Data Entry screen or Worklist Directory. IOD: An "" indicates that this Worklist attribute s data is included into applicable Image Object Instances created during performance of the related Procedure Step. Notes: 1 Scheduled Performing Physician s Name sets the Performed by field in Patient Data Entry Screen. 2 Scheduled Procedure Step Description may be used to set Study Description field in the Patient Selection screen and is mapped to Study Description in images. It is the 2 nd option for Study Description in Patient Data Entry Screen and images. 3 Scheduled Protocol Code Sequence: Code Meaning may be used to set Study Description field in the Patient Selection screen and is mapped to Study Description in images. It is the 3 rd option for Study Description in Patient Data Entry Screen and images. 4 Reason for the Requested Procedure may be used to set Study Description field in the Patient Selection screen and is mapped to Study Description in images. It is the 4 th option for Study Description in Patient Data Entry Screen and images. It is also the 1 st option for Indication in the Patient Data Entry Screen. 5 Requested Procedure Description may be used to set Study Description field in the Patient Selection screen and is mapped to Study Description in images. It is the 1 st option for Study Description in Patient Data Entry Screen and images. 6 Sets the Referring Physician in Patient Data Entry screens. 7 Reason for the Imaging Service Request may be used to set Study Description field in the Patient Selection screen and is mapped to Study Description in images. It is the 5 th option for Study Description in Patient Data Entry Screen and images. It is also the 2 nd option for Indication in the Patient Data Entry Screen Activity Acquire Images Description and Sequencing of Activities An Association to the configured MPPS SCP system is established immediately after the first image is acquired to send the MPPS N-CREATE message with status of IN PROGRESS. The End Eam button causes a COMPLETED status in the N-SET message. An eam for which an MPPS Instance is sent with a status of COMPLETED can no longer be updated. The Cancel Eam button causes a DISCONTINUED message. An eam for which an MPPS Instance is sent with a state of DISCONTINUED can also no longer be updated. The system supports creation of unscheduled cases by allowing MPPS Instances to be communicated for locally registered Patients. The system performs a single Performed Procedure Step at a time per Scheduled Procedure Step. EPIQ/Affiniti will initiate an Association to issue: N-CREATE request according to the Create Modality Performed Procedure Step SOP Instance operation N-SET request to finalize the contents and state of the MPPS according to the Set Modality Performed Procedure Step Information operation. 23 Lumify 1.8. DICOM Conformance Statement

24 Figure 6 SEQUENCING OF ACTIVITY ACQUIRE IMAGES A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g. a device such as a RIS or HIS which supports the MPPS SOP Class as an SCP) is illustrated in Figure 6. Note: The Cancel and End Eam commands are mutually eclusive. They are both represented here for illustration purposes only. Actual workflow uses one or the other for a given eam Proposed Presentation Contets Lumify 1.8. will propose Presentaton Contets as shown in the following table: 24 Lumify 1.8. DICOM Conformance Statement

25 Table 25 PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY WORKLIST UPDATE Presentation Contet Table Abstract Synta Transfer Synta Name UID Name List UID List Role Et. Neg. Modality Performed Procedure Step Eplicit VR Little Endian* Implicit VR Little Endian *Note: If the worklist server accepts Eplicit VR Little Endian and Implicit VR Little Endian then Lumify 1.8. will use Eplicit VR Little Endian Transfer Synta. SCU None SOP Specific Conformance for MPPS The following table summarizes the behavior of Lumify 1.8. when encountering status codes in an MPPS N-CREATE or N- SET response. Table 26 MPPS N-CREATE / N-SET RESPONSE STATUS HANDLING BEHAVIOR Service Status Further Meaning Error Code Behavior Success Success 0000 The SCP has completed the operation successfully. Failure Processing Failure Performed Procedure Step Object may no longer be updated 0110 The Association is aborted. * * Any other status code. Same as Failure above. Table 26a MPPS COMUNICATION FAILURE BEHAVIOR Eception Behavior Timeout Association aborted by the SCP or network layers Same as Service Status Refused in the table above. Same as Service Status Refused in the table above. Table 27 provides a description of the MPPS N-CREATE and N-SET request identifiers. Empty cells in the N-CREATE and N-SET columns indicate that the attribute is not sent. 25 Lumify 1.8. DICOM Conformance Statement

26 Table 27 MPPS N-CREATE and N-SET REQUEST IDENTIFIERS Attribute Name Tag VR N-CREATE N-SET Specific Character Set (0008,0005) CS Modality (0008,0060) CS US Referenced Patient Sequence (0008,1120) SQ Zero Length Patient s Name Patient ID Patient s Birth Date Patient s Se Study ID (0010,0010) (0010,0020) (0010,0030) (0010,0040) (0020,0010) PN LO DA CS SH As received from MWL or entered in PDE As received from MWL or entered in PDE As received from MWL or entered in PDE As received from MWL or entered in PDE System Generated, starting at 1 for each patient and incrementing for each subsequent study Performed Station AE Title (0040,0241) AE AE Title from configuration Performed Station Name (0040,0242) SH AE Title from configuration Performed Location (0040,0243) SH AE Title from configuration Performed Procedure Step Start Date Performed Procedure Step Start Time Procedure Code Sequence (0040,0244) (0040,0245) (0008,1032) DA TM SQ Actual Start Date (on close of PDE Screen) Actual Start Time (on close of PDE Screen) Mapped from Requested Procedure Code Sequence (0032,1064) from MWL, Zero Length for unscheduled study Mapped from Requested Procedure Code Sequence (0032,1064) from MWL, Zero Length for unscheduled study Performed Procedure Step End Date (0040,0250) DA Zero Length Actual end date Performed Procedure Step End Time (0040,0251) TM Zero Length Actual end time Performed Procedure Step Status Performed Procedure Step ID Performed Procedure Step Description (0040,0252) (0040,0253) (0040,0254) CS IN PROGRESS Performed Procedure Type Description (0040,0255) LO Zero Length Performed Protocol Code Sequence (0040,0260) SH LO SQ Scheduled Step Attributes Sequence (0040,0270) SQ Auto generated in the format, <YYYYMMDDHHMMSS> Set from Study Description field in PDE, else mapped from Requested Procedure Description in MWL. Zero length, or mapped from MWL Scheduled Protocol Code Sequence (0040,0008) COMPLETED or DISCONTINUED Set from Study Description field in PDE, else mapped from Requested Procedure Description in MWL. Same 26 Lumify 1.8. DICOM Conformance Statement

27 >Accession Number Attribute Name Tag VR N-CREATE N-SET >Referenced Study Sequence >>Referenced SOP Class UID >>Referenced SOP Instance UID >Study Instance UID >Requested Procedure Description >Scheduled Procedure Step Description >Scheduled Protocol Code Sequence >Scheduled Procedure Step ID >Requested Procedure ID (0008,0050) (0008,1110) (0008,1150) (0008,1155) (0020,000D) (0032,1060) (0040,0007) (0040,0008) (0040,0009) (0040,1001) SH SQ UI UI UI LO LO SQ SH SH Performed Series Sequence (0040,0340) SQ From MWL or user PDE input. MWL value may be edited. One item per item in the MWL Reference Study Sequence. Absent if unscheduled. Same value as in of the Reference Study Sequence in the MWL Same value as in of the Reference Study Sequence in the MWL Same value as in MWL attribute or auto generated Same value as in MWL attribute if present or Zero Length Same value as in MWL attribute if present or Zero Length Same value as in MWL attribute if present or Zero Length Same value as in MWL attribute if present or Zero Length Same value as in MWL attribute if present or Zero Length >Retrieve AE Title (0008,0054) AE Zero Length Same >Series Description (0008,103E) LO Zero Length Same >Performing Physician s Name >Operator s Name >Referenced Image Sequence >>Referenced SOP Class UID >>Referenced SOP Instance UID (0008,1050) (0008,1070) (0008,1140) (0008,1150) (0008,1155) PN PN From the Performed by field in PDE From the Performed by field in PDE SQ Zero Length Same Same >Protocol Name (0008,1030) LO Free Form Same >Series Instance UID (0020,000E) UI Auto Generated Same >Referenced Non-Image Composite SOP Instance Sequence (0040,0220) UI UI SQ Zero Length One item per referenced image instance SOP Class UID of acquired instance SOP Class UID of acquired instance One item per referenced non-image instance 27 Lumify 1.8. DICOM Conformance Statement

28 Attribute Name Tag VR N-CREATE N-SET >>Referenced SOP Class UID (0008,1150) UI SOP Class UID of acquired instance >>Referenced SOP Instance UID (0008,1155) UI SOP Class UID of acquired instance Association Acceptance Policy The Workflow Application Entity does not accept Associations Verification Application Entity specification SOP Class Lumify 1.8. provides Standard Conformance to the following SOP Class: Table 27 SOP CLASSES FOR AE VERIFICATION SOP Class Name SOP Class UID SCU SCP Verification Yes Yes Association Establishment Policy General The DICOM standard application contet name for DICOM 3.0 is always proposed: Table 28 DICOM APPLICATION CONTEXT FOR AE VERIFICATION Application Contet Name Number of Associations Lumify 1.8. initiates one Association at a time for a Verification request. Table 29 NUMBER OF ASSOCIATIONS INITIATED FOR AE VERIFICATION Maimum number of simultaneous Associations 1 Table 30 NUMBER OF ASSOCIATIONS ACCEPTED FOR AE VERIFICATION Maimum number of simultaneous Associations 1 Note: There is no enforced limit on the number of incoming associations. However, only associations from the configured Storage Commitment AE will be accepted, effectively reducing the maimum number of incoming associations to one Asynchronous Nature Lumify 1.8. does not support asynchronous communication (multiple outstanding transactions over a single Association). 28 Lumify 1.8. DICOM Conformance Statement

29 Table 31 ASYNCHRONOUS NATURE AS A SCU FOR AE VERIFICATION Maimum number of outstanding asynchronous transactions Implementation Identifying Information The implementation information for this Application Entity is: Table 32 DICOM IMPLEMENTATION CLASS AND VERSION FOR AE VERIFICATION Implementation Class UID Implementation Version Name LUMIFY_ Association Initiation Policy Activity Verify as SCU Description and Sequencing of Activities SCU: The user can verify the eistence of a DICOM server on the hospitals network, through a Test button on the DICOM Node s Setup Dialog. When the user presses this button, Lumify 1.8. will initiate the association. Only one association is established for each verification attempt. Verification SCU Verification SCP 1. Open Association 2. C-ECHO Request 3. C-ECHO Response 4. Close Association Figure 7 SEQUENCING OF ACTIVITY ISSUE VERIFY Proposed Presentation Contets 29 Lumify 1.8. DICOM Conformance Statement

30 Table 33 PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY VERIFY AS SCU Presentation Contet Table Abstract Synta Transfer Synta Name UID Name List UID List Verification Implicit VR Little Endian Eplicit VR Little Endian Eplicit VR Big Endian Role SCU Et. Neg. None SOP Specific Conformance for Verification The following table summarizes the behavior of Lumify 1.8. when receiving status codes in a C-ECHO response. A message will appear on the user interface if Lumify 1.8. receives any other SCP response status than Success. Service Status Table 34 VERIFICATION C-ECHO RESPONSE STATUS HANDLING BEHAVIOR Further Meaning Error Code Behavior Success 0000 Device Status is set to: Verified Refused Out of Resources A700 Device Status is set to: Not Verified Failed Unable to Process C000 CFFF Same as Refused above. * * Any other status code. Same as Refused above Association Acceptance Policy Activity Verification as SCP Description and Sequencing of Activities SCP: The system listens on the port configured in the Connectivity Profile for Verification requests initiated by other remote devices. The calling device AE must already be configured as the remote Storage Commitment device in the Connectivity Profile or the association is rejected Accepted Presentation Contets Table 35 PROPOSED PRESENTATION CONTEXTS FOR ACTIVITY VERIFY AS SCP Presentation Contet Table Abstract Synta Transfer Synta Name UID Name List UID List Role Et. Neg. Verification Implicit VR Little Endian Eplicit VR Little Endian SCP None SOP Specific Conformance for Verification The association request will be rejected if the remote AE is not configured on Lumify Lumify 1.8. DICOM Conformance Statement

31 4.3 PHYSICAL NETWORK INTERFACES Supported Communication Stacks TCP/IP Stack The System provides only DICOM V3.0 TCP/IP Network Communication Support as defined in PS 3.8 of the standard. The TCP/IP Stack, as supported by the underlying Operating System, is the only protocol stack supported. The system supports Wireless network interface that is available by the device. The system does not control or configure the network interfaces Physical Network Interface The Lumify 1.8. system supports one network interface at a time. The available network interfaces are determined by the Android device in use Additional Protocols Not Applicable IPv4 and IPv6 Support IPv4 and IPv6 addresses are supported. 4.4 CONFIGURATION Any implementation's DICOM conformance may be dependent upon configuration, which takes place at the time of installation. Issues concerning configuration are addressed in this section. Lumify uses a concept of Configuration Profiles that may be used to group sets of configured devices together. Each profile may contain at least one of a Primary Storage Server, a Storage Commitment Server, a Modality Worklist Server and a Modality Performed Procedure Step server. Other settings are configurable as well, including strategies for automatic eport of eam images, and automatic deletion of eams AE Title/Presentation Address Mapping An important installation issue is the translation from AE title to presentation address. How this is to be performed is described here Local AE Title Table 36 DEVICE AE TITLE CONFIGURATION Application Entity AE Title Storage Storage Commitment* Worklist Performed Procedure Step <User Specified> <User Specified> <User Specified> <User Specified> Note: For Storage Commitment N-Event-Report messages to return to the system, the Android operating system limits the range of available listening ports for Lumify to be above cannot be assigned to the Lumify Remote AE Title/Presentation Address Mapping 31 Lumify 1.8. DICOM Conformance Statement

32 Table 37 REMOTE AE TITLE CONFIGURATION Application Entity AE Title Storage Storage Commitment Worklist Performed Procedure Step <User Specified> <User Specified> <User Specified> <User Specified> Workflow Setup is used to set the AE Title, Port number and IP Address the remote MWL SCP. Multiple MWL SCPs may be defined, but only a single remote MWL SCP can be used at a time. AE Title may be selected as the system s. The Start Date defaults to Today but may be modified to be All Dates, or a Date Range that may be 1, 7, or 30 days. 32 Lumify 1.8. DICOM Conformance Statement

33 5 MEDIA STORAGE Lumify 1.8. does not support Media Storage. Lumify 1.8. does support saving of images to DICOM file formats, but does not necessarily comply with the DICOM Media Storage model in PS Lumify 1.8. DICOM Conformance Statement

34 6 SUPPORT OF CHARACTER SETS Lumify 1.8. supports the following value of Specific Character Set (0008,0005): ISO_IR 100 (ISO :1987 Latin Alphabet No. 1 supplementary set) 34 Lumify 1.8. DICOM Conformance Statement

35 7 SECURITY DICOM security is not implemented on Lumify 1.8. at this time. 35 Lumify 1.8. DICOM Conformance Statement

36 8 ANNEXES 8.1 CREATED IOD INSTANCES TABLE 39 specifies the attributes of an Ultrasound Image transmitted by the Lumify 1.8. storage application. The following tables use a number of abbreviations. The abbreviations used in the Presence of column are: VNAP ANAP EMPTY Value Not Always Present (attribute sent zero length if no value is present) Attribute Not Always Present Always Present Attribute is sent without a value The abbreviations used in the Source column: MWL USER CONFIG the attribute value source Modality Worklist Unless otherwise noted, values returned from worklist may be overridden by User input. the attribute value source is from User input the attribute value is generated automatically the attribute value source is a configurable parameter US or US Multiframe Image IOD Table 38 IOD OF CREATED US OR US MULTIFRAME SOP INSTANCES IE Module Reference Presence of Module Patient Patient TABLE 41 Study General Study TABLE 42 Patient Study TABLE 43 Series General Series TABLE 45 Equipment General Equipment TABLE 46 General Image TABLE 47 Image Piel TABLE 48 Cine TABLE 49 Only if Multi-frame Image Multi-frame TABLE 50 Only if Multi-frame US Region Calibration TABLE 51 ANAP* US Image TABLE 52 SOP Common TABLE 53 * the US Region Calibration module is not present in US Multiframe images where a calibration change occurs, i.e. the loop contained a depth or zoom change. 36 Lumify 1.8. DICOM Conformance Statement

37 8.1.2 Secondary Capture IOD Table 39 IOD OF CREATED SECONDARY CAPTURE SOP INSTANCES IE Module Reference Presence of Module Patient Patient TABLE 41 Study General Study TABLE 42 Patient Study TABLE 43 Series General Series TABLE 45 Equipment SC Equipment Table 56 General Image Table 54 Image Piel Table 55 Image SC Image N.A. All attributes are optional and are not present SOP Common Table Common Modules Table 40 PATIENT MODULE OF CREATED SOP INSTANCES Attribute Name Tag VR Value Presence of Value Patient s Name (0010,0010) PN Same attribute of MWL or PDE input Patient ID (0010,0020) LO From MWL, user input or system generated. Patient s Birth Date (0010,0030) DA Same attribute of MWL or PDE input VNAP Patient s Se (0010,0040) CS Same attribute of MWL ANAP Other Patient IDs (0010,1000) LO Same attribute of MWL ANAP MWL Source MWL/ USER/ MWL/ USER/ MWL/ USER MWL/ USER Table 41 GENERAL STUDY MODULE OF CREATED SOP INSTANCES Attribute Name Tag VR Value Presence of Value Study Instance UID (0020,000D) UI Same value as in MWL or auto generated Source MWL/ Study Date (0008,0020) DA Study s Start Date (0040,0244). 37 Lumify 1.8. DICOM Conformance Statement