DICOM Requirements for Modality Bid Specs When you order new modalities for imaging that you want to connect to PACS, the following items should be specified in the bid. Please see the explanations at the bottom of the document so that you understand why these need to be in the bid. If this is not specified, the vendor will charge you to add these capabilities after the fact. Updated: 06/18/07 Bill Gregg ------------------ Copy appropriate text below this line into your bid spec --------------- DICOM/HL7/IHE Requirements In order to facilitate the bid process, the DICOM Conformance Statement, applicable IHE Integration Profiles, and the Manufacturers Discloser Statement for Medical Device Security (MDS2) should be forwarded to the PACS Administrator at LSUHSC-S early in your process. Bid’s that do not provide this information will not be accepted. Each modality will have a different set of requirements encompassed within the points below. Each request from LSUHSC-S should have attached to this document a copy of these requirements in a spreadsheet format. If these spreadsheets are included they will define the specific functionality required, otherwise this document will define the requirements. These requirements will be matched up with the vendors statements provided above to determine if the modality bid meets the LSUHSC-S requirements. 1. The modality must be DICOM (Digital Imaging in Communications and Medicine) compliant, provide at a minimum Level 2 conformance, and be able to function with other DICOM compliant modalities and systems within LSUHSC- S. The intent is to provide maximum automation for the institution utilizing DICOM standards. This includes specifically the institutions GE PACS (Picture Archiving and Communications System), and any other DICOM equipment specified in the bid. Functionality at a minimum includes DICOM Storage Service Class User (SCU) and DICOM Verification Service Class User and Provider (SCU and SCP) capability. These classes should be current and appropriate for the modality, and if requirements specify connection to an older system, should include any potential ‘retired’ SOP (Service Object Pairs) the older modality may require. If the modality does not yet have the capabilities below, they must be installed at no additional charge within one year from purchase. These items must be clearly stated in the bid specifications, along with projected time frames for implementation. 2. The modality must be able to perform DICOM Modality Work List Information Model Find functions so that patient orders can be selected from a worklist provided by PACS/RIS (Radiology Information System), rather than requiring manual entry by the technologist. The worklists will be provided via the Mitra broker. For this bid there is a cost for a license pack to access the worklist from the modality for which the bid vendor is responsible. The vendor should negotiate with GE to purchase the applicable MWL license pack. 3. The modality must be able to perform DICOM Modality Performed Procedure Step functions, so that exam progress status can be automatically sent back to PACS/RIS, and DICOM Storage Commitment. 4. The modality must be able to perform DICOM Query/Retrieve functions as a Service Class User for all appropriate image sets to allow for retrieval of prior studies for comparison at the modality. 5. The modality must be able to perform DICOM Print as a Service Class User for all appropriate image sets, and must work with LSUHSC-S DICOM Print servers. 6. LSUHSC-S currently has GE’s PACS system (Centricity 2.0), and Siemens/SMS RIS system (v23). It is the vendor’s responsibility to ensure that images can be stored, retrieved and properly displayed from PACS, and that all requested DICOM/HL7/IHE functions work with the appropriate LSUHSC-S systems. This includes any additional licenses, fees and service required by these vendors to connect the modality and provide the functionality described. There will be a DICOM connection fee to connect the modality to the GE PACS for which the bid vendor will be responsible. The vendor should negotiate with GE to cover this connection fee. Payment will be made pending LSUHSC-S verification of these functions. LSUHSC-S’s unidirectional PACS broker currently prohibits DICOM MPPS from occurring, but once the ability to do bi-directional communication with the RIS is in place, this MPPS SOP class must be implemented by the vendor. If this connection does not work due to the vendor’s product not properly implementing the DICOM standard, it must be fixed. It is the intention of this bid to ensure a complete installation, and that there will not be any ‘gaps’ left to LSUHSC-S to pay for outside of the bid to make the systems work as intended. 7. Once the modality is installed, the vendor will work with LSUHSC-S to provide validation testing before production use to ensure proper exchange of intended information. 8. The vendor must be a participant in the IHE (Integrating the Healthcare Enterprise) initiative. A current IHE Integration Statement must be provided prior to the bid. It is LSUHSC-S intent to utilize IHE principles to support the integration of systems in the healthcare enterprise. The vendor must be working in the same direction in order to be considered for this bid. There are currently a number of Integration Profile specifications, with varied degree of support from Vendors. Ultimately, all Integration Profiles should be a standard part of a Vendors offer. The specific profiles are listed below, and are required if applicable to the system being bid. If the Vendor does not currently support applicable profiles, they must be made available upon Vendor implementation (within one year from purchase) at no extra charge to LSUHSC-S. The vendor must provide User Authentication/Access Control at the device, as well as node authentication and exportable audit logs in the IHE Audit Trail and Node Authentication (ATNA) format. There must be an ability to synchronize the clock on the device with a central clock specified by LSUHSC-S. a. Patient Information Reconciliation (PIR) b. Scheduled Workflow (SWF) c. Presentation of Grouped Procedures (PGP) d. Post Processing Workflow (PWF) e. Reporting Workflow (RPW) f. Charge Posting (CP) g. Consistent Presentation of Images (CPI) h. Evidence Documents (ED) i. Key Image Notes (KIN) j. Simple Image and Numeric Reports (SINR) k. Access to Radiology Information (ARI) l. Portable Data for Imaging (PDI) m. Import Reconciliation Workflow (IRWF) n. Audit Trail and Node Authentication (ATNA) o. Nuclear Medicine Image (NMI) p. Mammography Image (MMI) q. Image Fusion (IF) r. Teaching File and Clinical Trial Export (TCT) s. Cross Enterprise Document Sharing for Imaging 9. If the modality provides storage to removable devices (DVD or MOD), this storage must comply with the DICOM Part 10 Media Interchange standards and the IHE Portable Data for Imaging (PDI) profile. To insure compliance with LSUHSC-S HIPAA policy, the storage mechanism must at least have the option to remove Identifiable Healthcare Information from the image sets that will be transferred via this mechanism, and all creation functions must be logged according to the IHE ATNA profile. Operating System and Software Patches The vendor must provide critical (security or operational) patches on a timely basis, including the process of FDA approval. If the system is affected by an attack on an unpatched (one that has a patch available for it but has not been installed pending approval by the vendor) security hole, it is the vendors responsibility to bring the system back to a functional state within the emergency response time specified under service. Network requirements Network connections should be located within 15 feet of the console. The bid system should support 100mbps (100BaseT) network speeds. 1000mbps network speed is preferred, particularly for modalities that create large data sets, such as multi-slice CT. The LSUHSC-S PACS network shall be segmented from the rest of the hospital network, and utilize category 5e cables for all installations. Network jacks must be 8 pin modular (RJ45). The bid system should be connected to the network via patch cord connection to the facility infrastructure. LSUHSC-S will provide AE Titles, IP address, default router IP address, and subnet mask for each system installed. Hardware requirements All computer hardware and operating systems must be current versions. For Windows at this time that would be Windows XP Professional, NOT Vista. If a vendor is currently utilizing an older operating system, the system must be upgraded within a year to the current version of the operating system. ----------------------- Copy text above this line into your bid spec --------------------- ----------------------- Omit the descriptive text below from bid ------------------------- Some description is necessary to understand these items. The items in the introductory paragraph are of utmost importance, and must be required for every bid. If we do not do this we are making a blind purchase. The DICOM standard is not a simple issue, and it is necessary to include the PACS Administrator early in the process for creating the bid. It takes time and understanding to properly create the desired specifications. The IHE Profiles ensure that the modality properly uses these standards to accomplish desired goals. It is extremely important that the customer help the vendor to comply with standards and frameworks. If we do not ensure the proper functionality in the bid, it could either cost us significant money or lack of capability in the future. If we can not get this information from the vendor, we must ensure that their product can not be purchased. This can be done by utilizing the requirements spreadsheet prepared by the PACS Administrator. If there is nothing from the vendor to compare it to, it does not qualify. Consequently, every modality bid should have this, which requires involvement well before the bid is let. The Manufacturers Disclosure Statement for Medical Device Security is fairly new, but is necessary to enable us to understand what the vendor provides, and also to push them to fully provide mechanisms necessary for proper HIPAA security implementation. Item 1 is pretty standard DICOM compliance stuff, and should be in every bid. Item 2 ensures that we can use worklists on the modality, and not have to enter patient information manually. This is a must. Item 3 is not something we can make use of at this time, but should be able to use somewhere down the line. This, like item 2, is a workflow enhancing function, as it allows the device to automatically send start procedure and end procedure steps to the RIS. This frees the technologist from having to manually track these steps. We need a bi- directional, or brokerless (the PACS Broker is what transmits HL7 ADT and report information from the RIS to the PACS) environment to be able to do this. Currently we can only receive information from RIS, so the PPS function has no way to report back to the RIS. In the future this should evolve. The bottom line here is that some vendors may not have implemented this yet (all should as time goes on), and to reduce costs you may need to leave this out. I strongly recommend all modalities we purchase have this function, even though the vendor may not be able to implement it at this time. DICOM Storage Commitment enables the PACS server to tell the modality that it has taken charge of storing the exam, and has it committed. The modality can then delete the study from its drive to make way for more exams. What we would ultimately like to see is the ‘archiving’ function moved from the modality to the servers archive. This will save the technologist’s time in not having to manually store exams to tape, CD, or whatever media is used. As of 06/18/07, however, we do not have a full disaster recovery mechanism for our archived exams, so continuing to do modality based archiving of exams is necessary. Item 4 allows the modality to query the PACS server for prior studies to use as comparisons at the modality (to mimic prior studies as closely as is desired). Item 5 allows the modality to print to our DICOM print servers. Item 6 specifically states that it is the vendor’s responsibility to make their equipment work with our information systems (PACS/RIS). This is to prevent us from being caught in the middle of a finger pointing session. If they can’t get it to work, we will not accept it. It also requires the vendor to include any licensing that is required by the system the modality needs to connect to. There is a DICOM license fee of $1500 ($4500 if non-GE) to connect to PACS for any new modality, and a $1000 SQL license if a worklist is required (these are only sold in a 5 pack by GE). If the modality needs to connect to other devices, there may be licensing fees for that as well. We should know these things, but we want it to be the vendor’s responsibility to make sure all is taken care of and included in the bid. Item 7 is extremely important. IHE is a concerted push to enable information systems integration that is being sponsored by RSNA, HIMSS and SIIM, as well as many international groups. This started in the Radiology realm, but the idea is to get other groups involved to Integrate the Healthcare Environment. It is very important that we, the customer, ensure that the vendors move down this path. If we don’t require it, they won’t do it. IHE has been evolving and growing over the last 4-7 years, and has been prevalent at RSNA and HIMSS for the last 3 years. Although there is much work to be done, there are a lot of ‘profiles’ that are currently embodied in the framework. Now that the HIPAA privacy and security rules are in effect, we must have the ability to audit for security events, and to provide access control at the device. Not having these capabilities is simply not an option anymore. Item 8 allows for the modality itself to store DICOM and jpg images that can be transferred to pc. Utilization of such will fall under HIPAA guidelines, so be aware that you will need a way to document the transfer of any Identifiable Healthcare Information. If all identifiers are stripped, there should be no problem, but auditing is still necessary.