WG-33 was established by the DICOM Standards Committee at the end of last year to address the interoperability of systems that archive and manage DICOM data. The focus is on the management and interoperability of the archive data set as a whole, rather than interoperability of the data for individual studies or patients. The initial charge to WG-33 is to determine appropriate modifications to the DICOM Standard to better support PACS migrations, and to propose a corresponding Work Item to the DSC. The impetus for this was the Laitek proposal for a new PACS storage standard, as outlined in this blog over the past few months.

WG-33 held an organizational tcon in January, at which time Matt Bishop (UnityPoint Health) and Keith Eklund (Healthcare Tech Solutions) were elected co-chairs. We have since had two working tcons, and are now continuing with biweekly meetings. We have had about 30 people on each call, and good participation.

To kick off the discussion, I presented the main points of the Laitek proposal – basically a summarization of the blog posts. Based on the comments made during the discussion, there seems to be a consensus that the PACS migration problem is real. There were some other issues raised based on other current real-world issues around storage architectures, VNAs, cloud, and multi-institutional archives. I’ll try to summarize them, but as these were not my issues, I don’t guarantee that this summary accurately reflects the opinions of the people who raised them.

1. Separating the PACS from the storage layer at a standardized interface seemed to be a generally accepted principle. But there is an issue of what is most appropriate standard for that interface. While Laitek has proposed a file system type interface, other possibilities are a DICOM DIMSE (classic protocol) or DICOMweb interface, such as the interface between a PACS and a VNA, or even an object access interface, such as the S3 protocol used in Amazon Web Services.
2. Once PACS and storage are separate, there is a use case for storage migration separate from PACS replacement, including such uses as the storage moving from on-premises to the cloud. How this is addressed will depend on the nature of the interface between PACS and storage, as the storage migration must not affect that interface.
3. If the storage layer presents an alternative access method to the archive, other than through the PACS, it needs to support a broad range of access controls, including permissions down to at least the level of individual studies, dynamic role-based permissions, and access logging for audit. Note that DICOM does not specify any of this for the PACS (in the specs that were written 30 years ago!), but it should certainly be a consideration today. One possible solution that was mentioned is a token-based access control, where there is a access control manager function that issues tokens, and the storage layer provides access based on the token.
4. The proposal should address a storage layer that supports multiple institutions with differing views of patient metadata (e.g., patient ID). The metadata provided by the storage layer, e.g., in an Enhanced DICOMDIR, should support different metadata based on the identity of the accessing system or user. Note that this gets into the architectural decisions about health information exchange, and the role of master patient indexes in such an architecture (see for instance the IHE XDS family of profiles and their approach to differential metadata).
5. The proposal needs to account for vendor neutral archives, which are a significant feature of many enterprise architectures. To what extent should we consider VNAs as already providing the separation of PACS from storage? Should we consider the separation of the VNA application from its storage? If so, how should the proposal deal with the non-DICOM data storage features of VNAs?
6. A concern was raised that conformance to a PACS storage standard could raise the cost of a PACS by a non-trivial sum, and that may have consequences for the user organizations. But note that this is true of compliance to any standard, where the intent is to reduce the overall cost across the domain, in this case the long-term costs of system replacement and migration. And of course, this would be an optional conformance clause of DICOM, and the adoption of conformance to any DICOM feature is purely voluntary – vendors and users would have to make their own economic calculations as to whether it is a feature they would want to adopt.
7. This is not a short-term solution; I mentioned that historically capabilities such as this have a 5- to 7-year roll-out period. There is a concern that we should address the issues of transition during such a long period, including the inevitable evolution of technology during that time (especially cloud-based architectures).

These are going to be really interesting discussions, so stay tuned to this blog. Or you can participate yourself – sign up to be a member or observer of WG-33 at https://www.dicomstandard.org/participate/.

Author Harry Solomon is an interoperability consultant for Laitek, Inc., and past Co-Chair of the DICOM Standards Committee. He has been involved in the development of DICOM since 1993, and has taught graduate courses in healthcare interoperability and standards at Northwestern University and at Oregon Health & Science University. Contact him at hsolomon@laitek.com or harry.solomon@ieee.org.