Interregional Sharing of Medical Images and Reports in Denmark Through XDS Version 1.5

Transcription

1 Interregional Sharing of Medical Images and Reports in Denmark Through XDS Version 1.5

2 Source revision tag : 1.5 Source revision : 4c9f1ee39db1410e e67c80161f2f4369 Source revision date : Fri Mar 30 13:46:11 CEST 2012 Document ID: e29299a7-2cea-450c-a7fc-7980b83bc844

3 Summary of the document history Version Created Author Summary of the changes Kristian Skotte, et. al. Updated Appendix A with SDN addresses and included reference to document Messages and how they are related Kristian Skotte, et. al. Removed the last remainings of the external AD. Added SDN address information and network requirements Johan Hedin, et. al. Made the final packing. More focus on XDS-I. More focus on the importance of structured data. Removed the extranet AD. Removed the work in progress notice. Added a table of the included documents Johan Hedin, et. al. Many clearifications and improvements Johan Hedin, et. al. The first draft version iii

4 iv

5 Contents 1 About this document Intended Use Intended Audience Introduction Scope of the solution Overview of the Solution Design Choices Tiering of the Information Long Lived Data Vendor Independent High Availability Future-proof Control of Published Data Adaptations for the Nordic Region Scalable Security Model Structured Data Submitting to the Interregional XDS Repository Deviations from the IHE Profile Connecting a New Source Security Network requirements Querying the Interregional XDS Archive Deviations from the IHE Profile Connecting a New Consumer Security Using the Interregional Consumer Security A Addresses to the interregional XDS 19 v

6 Contents A.1 Production A.2 Test B List of included document 21 vi

7 C h a p t e r 1 About this document This document is a high level specification of the interregional sharing of medical images and reports in Denmark through the interregional xds provided by Region Zealand. For implementation details, other and more detailed documents are provided. These documents are listed in appendix B. 1.1 Intended Use The intended use of this document is for the planning of the connection with the interregional xds provided by Region Zealand. This document covers the technical connection strategies. The medical use cases are just briefly mentioned and the business case are not covered at all in this document. 1.2 Intended Audience The intended reader of this document is a Healthcare or it professional with basic knowledge about ris, pacs and xds, as well as basic knowledge about the imaging and report workflow in healthcare. The intended reader is assumed to read the document with the intention of getting oriented of the technical aspects of the connection, or in order to plan for work to be carried out based on the final version of this document and its included appendices. 1

8 1. About this document 2

9 C h a p t e r 2 Introduction By providing national access to radiology images and reports, the quality of the patient care can be improved, as earlier relevant medical findings are accessible to the involved physicians. In addition, not needed radiology examinations can be avoided. Hence, patients are spared extra radiation and healthcare resources can be utilized more efficiently. Region Zealand will provide the technical infrastructure and the governance of a national medical data storage that is searchable. In the first phase, this storage focuses on radiology images and reports. In the future, the solution can be expanded to other ologies with other medical content. 2.1 Scope of the solution The solution scope for the interregional solution is image and report sharing across the regional boundaries. For work flow, e.g. second opinion of radiology reports or load balancing of the bulk examinations across the regions, other solutions are required. However, by providing access to images and reports across the regions, several important goals are achieved as described in the section above. 2.2 Overview of the Solution In this section, the interregional solution will be described on a high level. In the subsequent chapters, more details about different aspects of the solution will be treated. The solution is based on a central xds.b registry and repository that is populated with a combination of regular xds.b and xds-i.b, c.f. section 3.1. An overview of the solution is shown in figure

10 2. Introduction The heart of the solution is an ihe xds registry and repository. These services are provided by Region Zealand for the rest of Denmark to use. The xds repository is the storage of the data. The documents can be fetched using their unique ids. The xds registry is the index service providing a standard query interface for finding the data stored in the repository. The result of the query in the registry gives enough information to build a patient overview, c.f. section 3.1. This is important, since it decreases the response time for the end users as well as reduces the hardware demands on the central solution. The open published and documented profile xds reduces the integration costs of connected systems. The deeper discussion of the design choices is given in chapter 3. In the interregional xds, copies of the relevant information from the regions are stored. The content of the interregional registry will vary by source, as discussed in section 3.1. For the xds-i submissions by the regional pacs archives, the document will contain pointers to wado access for the actual image, e.g. dicom kos objects. For the radiology reports, the interregional xds stores the full report in conformance with the hl7 cda-i implementation guide. In order to access and consume the interregionally stored material, the consuming systems should act as an ihe xds consumer. The material accessible by any ihe xds-i.b compliant consumer. The more detailed cda is provided for the consumers that wishes to build a uniform structured view of the radiology referral and report. In addition to the xds/xds-i access of the interregional data from the regional systems, an xds consumer is provided. The interregional consumer provides access to a patient by a cpr number given by the context by trusted servers in the consuming regions.! "#$%&! ' (( Figure 2.1. The interregional solution provided by Region Zealand in a high level view. 4

11 Overview of the Solution Attached to the consumer solution, there is a possibility to launch the streaming viewer, EasyViz, of Region Zealand to view the dicom object without the need to transfer the full dicom study through wado. A streaming remote viewing solution for the dicom images has three important advantages over wado access of the dicom objects. Firstly, the end user response time is much faster since only the portion of the images that are shown on the user screen needs to be transferred. This also reduces the load on the interregional networks. Secondly, a remote streaming viewer does not leave any footprint of the images on the viewing workstation. Thirdly, an accessible remote streaming viewer reduces requirements on the hardware and software for the viewing workstation. Other regions are encouraged to make similar technology available for the same reasons. It should however be noted that this is not a requirement, but rather a recommended extra option. The requirement is that the connecting regions makes the images available over wado as stated by xds-i. 5

12 2. Introduction 6

13 C h a p t e r 3 Design Choices The design is based on published and open documented standards. In the design process, the following items where found to be important: The data has a longer lifespan than the applications that produces the data, c.f. section 3.2. The solution must be vendor independent, c.f. section 3.3. The interregional index must have high availability, c.f. section 3.4. The individual regions must be able to choose what is being shared, c.f. section 3.6. The solution must be efficient for the Nordic region, c.f. section 3.7. The solution must be future-proof, c.f. section 3.5. The security model must be scalable, c.f. section 3.8. The stored data should be structured, c.f. section Tiering of the Information One important design choice is the tiering of the information. The design of the tiering is based on balancing speed, reliability and reusing existing infrastructure. The information content of the xds metadata is enough to populate a list of patient history. This is important since being able to query only the xds registry in order to present the first list is both faster as well as reduces the load on the central solution. 7

14 3. Design Choices The radiology reports are stored in a structured hl7 cda. The reason is that structured data enables both better presentation as well as future research. A non structured hl7 cda transformation, xds-sd, is also stored in order to conform to the xds-i.b profile. By storing an transformation in xds-sd, xds-i enabled systems are able to view the radiology reports. For the dicom images, the xds-i.b profile is chosen. The xds-i profile is based on sending pointers, dicom kos objects, to the xds archive. The actual dicom images are stored in dicom archives. Those images are retrieved through wado. The reason for this choice is that the dicom standard is mature. Several pacs vendors already support the xds-i profile both as sources and consumers. For non radiology multimedia, the full content is stored in the xds archive. This is motivated for three reasons. Firstly, the storage systems of the non radiology multimedia are in general not as reliable as a fully featured xds archive. Secondly, there is no corresponding standard way of querying the systems such as wado for dicom. Thirdly, most dicom archives operate on the assumption that a single dicom object can fit in the ram of the server. For xds, which is based on http streams, this limitation does not inherently apply. 3.2 Long Lived Data The lifespan of the medical data is much longer than that of the application that did produce the data. Therefore, it is of utmost importance that the data is independent of the source system that produced the data. In this context, hl7 cda-i and dicom are well suited formats for the radiology reports and images. For the non radiology medical multimedia, dicom have several limitations. Video is problematic to store in dicom as both the available video compression is lagging behind the technical standardization outside of dicom, as well as most dicom systems have problem with large files such as hd video. For the medical multimedia, a few well known and standardized formats are instead chosen such as jpeg, h264 and mp3. The same consideration must be done for the metadata as for the data. The metadata provides the way of finding and classifying the content. It needs to be stable over time, trends and vendors. It is important in this context to choose an xds vendor that stores the data and metadata in an open and documented way to enable migration to other vendors or new technologies. It is also important to choose a storage technology that guarantees the integrity of the data over a long time. The ability to read the data and metadata directly from the storage is important for the migration purposes mentioned above. 3.3 Vendor Independent A national solution must be independent of vendors. This includes both the vendor of the applications as well as the vendor of the databases and operating system of the servers and clients as well as the physical hardware. In order to lower the integration costs to such a framework, one based on published and open documented standards is 8

15 High Availability preferred. For the interregional solution, the ihe xds profile is chosen. The xds profile is rather flexible in the content and coding schemes of the metadata. Therefore it is well suited for the national solution. The xds as such is however not enough to define a solution. On top of the xds there are regulations about the content and coding, c.f. section 3.2. Another aspect of independence is that the interregional xds archive needs to be able to respond to queries from both new xds.b and legacy xds.a sql like query based consumers. 3.4 High Availability In order to achieve high availability of the solution, a design with as few components as possible has been chosen. In the center there is a national xds archive. This archive is deployed in two data centers in Ringsted and Slagelse. The data transactions in the servers are replicated across the data centers. In each data center, the individual servers are deployed in a ha cluster. The regions are required to publish the interregional data into this xds archive. Another solution with query spanning according to the ihe xca was considered. However, the xca was rejected early in the process. The reason is that the xca is too immature at the time of the implementation of the interregional solution. One example of this is that there are no time outs in the profile, i.e. in practice all networks and servers need to be operational for the solution to work. By minimizing the number of components with a single central archive, this dependency is reduced. It is however possible to convert the solution into an xca based solution in the future when the profile matures, c.f. section Future-proof It is very important that the solution is future-proof. It must be possible to upgrade the solution in components, as new technologies, standards, and vendors emerge. One important part in future-proofing the solution is published and open documented standards. Other important parts are vendor independence, c.f. section 3.3, and considering the long lifetime of the data, c.f. section 3.2. Since the solution is based on ihe xds, the querying and retrieving of the stored documents is open and documented, and hence most likely to be accessible in the future. The selection of the allowed content and content formatting is an important key in futureproofing the solution. By basing the storage on proven standards such as hl7v3 cda r2, dicom and h264, the data will be readable in the future. Also, the coding schemes and rules for the metadata must be very strict and well documented in order to be able to do queries on the data in the future. The xds archive chosen is able to store other types of medical content as the solution expands. Of course the same strict data formatting rules applies to all new content types that are added to the solution. Also the xca profile can be used in the future as the profile matures. The regional solution designed could be one of the xds registries in 9

16 3. Design Choices an xca context. If a region has connected as a pure xds source, the interregional xds archive can be used as the xca node for that region. Another important aspect is the research possibilities once the data is gathered. Open and accessible storage of the data and metadata is important here in order to be able to do advanced data mining and processing. 3.6 Control of Published Data Each region must be able to control what data gets published into the interregional solution. In the solution, no data is pulled from the regions. The attached regions are in complete control of what data is published in the interregional solutions, since the data is pushed by the region. However, once published to the interregional solution, the access control of the data is done by the consuming regions, c.f Adaptations for the Nordic Region The ihe frameworks are world wide valid. The Nordic region is somewhat unique in the aspect that national patient identifier both exists and are exclusively used. Therefore some adaptations of the xds profile are made to better suit the Nordic environment. In the Nordic regions the global identifiers are used in the local systems. The purpose of the pix is to translate the local patient identifiers into the global ones used in the xds. Hence, a pix does not provide any extra functionality and is therefore removed. In the Nordics, the patient data in the source systems is qualified by lookups in the national indexes. Hence, a patient identity feed is not required and is therefore removed from the solution. A pix manager may be installed at any time and start populating the xds with existing patient history. The interregional xds registry supports an implicit pix-like operation. If a query is made on an emergency cpr number, the documents for the merged cpr numbers are returned as well. In order for this to work, the regional sources are obliged to feed the interregional xds archive with patient merge in hl Scalable Security Model The security model must scale to a nation wide framework. This is done through federated security as intended by the xds profile. The connecting regions will connect through trusted gateways. These gateways will have full access to the interregional solution. The authentication, authorization, and logging of access to the patient data is the responsibility of the connecting region. In addition, a central consumer is provided. The access to this consumer is given by access through a trusted gateway in the connecting region that provides the patient and user context. The central consumer can in the future be 10

17 Structured Data adapted to a national security system for authentication and authorization. Before this is done, the scalable way of handling access is through the regional gateways. The regional gateways will be the only systems that are allowed to access the interregional xds archive. The access to the interregional solution is controlled by secured IP numbers over Sundhetsnetet. Once allowed access, the regional gateways will have full access to submit and query the interregional xds archive. It is the responsibility of the regional gateways to handle security, authorization, and auditing of the interregional requests for the users and systems in the region. For Region Zealand, the internal xds consumer and the internal xds archive will be the gateways. 3.9 Structured Data By storing the data in as structured as practically possible format, some distinct advantages are obtainded. Firstly, the view of the data can be unified regardless of the source system. Secondly, by storing a structured version of the data that is machine understandable, future data mining for research and e.g. algorithms that detect patterns and hence can be used as early indicators or diagnosis aid. The extra effort required to connect the sources to the solution as rich data sources is outveighted by the advantages in both near term, and most important, by the future possibilities with structured data. Thirdly, a structured represenation allows for Consumers to construct views that incorporate data from several documents, such as constructing a view with all examinations on one referral. The solution is based on both xds-i and cda-i. As described above, the benefits of using both the standards outweights the extra effort required to connect the source systems. As consumers, pure xds-i consumers can be used, althogh without the benefits of the strctured cda-i. 11

18 3. Design Choices 12

19 C h a p t e r 4 Submitting to the Interregional XDS Repository The connecting regions are obliged to submit the documents according to the ihe xds.b profile. The content must conform to the hl7 cda-i implementation guide and metadata specification. In the interregional xds archive, the dicom kos objects are stored according to xds-i profile and the interregional implementation guide supplied in addition to this document. The radiology reports should be supplied as hl7 cda-i document. The non radiology images are stored within the xds together with an hl7 cda document. In addition to submitting the documents to the interregional xds archive, the connecting regions also need to supply wado access to the images referenced by the dicom manifest object according to the xds-i profile. In Region Zealand, the submission to the interregional xds archive will be done through replication of the regional xds archive. The selection of the documents to be replicated is done through rules operating on the metadata. Other regions are recommended to take this approach, but there is nothing that prevents submitting directly to the interregional xds archive. Also Region Zealand will provide access to a streaming viewer for dicom images and access to an advanced viewing client for non radiology images. Other regions are recommended to do the same for efficient cross regional image access. However, the plain xds-i for dicom images as well as the xds retrieve for radiology reports and non radiology multimedia must always be supported. 4.1 Deviations from the IHE Profile A few deviations from the ihe xds profile are made in order to adapt the solution for the Nordic environment, c.f. section

20 4. Submitting to the Interregional XDS Repository The interregional xds is running without a patient identity feed. The reason is that all the source systems validate the patient data. The submitted patient data is therefore assumed to be clean. The regional gateways need to feed the interregional xds with patient merge in hl7 for emergency cpr numbers. 4.2 Connecting a New Source Region Zealand provides a complete test system for validating new connections. The correctness of the data and metadata is of utmost importance, since the data has long lifespan, c.f. section 3.2. A validation process of new sources will be carried out by the data governor of the solution. This process guarantees that the data stored in the interregional xds archive by the new source conforms to the data and metadata specifications and hence is understandable and usable for the other connected regions. 4.3 Security Only trusted gateways from the other regions will be allowed to submit documents. The authentication of the regional gateway is done through https access with a client certificate. The responsibility logging and handling security lies with the connecting region. The reason for this design is given in section 3.8. The connecting source system must also supply wado access to the dicom images for the submitted dicom kos objects for all the other connected regions. The access is handled through https with client certificates. Since wado does not supply any query capabilities, only the images published to the interregional xds archive will in practice be accessible interregionally. It is also recommended that the connecting region supplies a way of launching a streaming technology from the other regional gateways. It should be possible to launch the streaming solution with a single patient, with no possibility to change patients in the same session. The responsibility for the access and the regional auditing is in the regional gateways of the reading regions. 4.4 Network requirements The regional implementation needs to have access to the interregional solution with the addresses given in appendix A. This need to be opened on both the regional firewalls as well as the interegional firewalls. In addition, the connecting region must publish wado access to the dicom objects referenced in the interregionaly published kos objects. The wado access must be through the Sundhetsdatanetet and accessible from the trusted gateways in the other connected regions. 14

21 C h a p t e r 5 Querying the Interregional XDS Archive A query to the interregional xds registry provides enough information to populate a basic patient history list. Connected systems are encouraged to present only the metadata as a first entrance to the end user in order to lower the demands on hardware and networks. From that list, the client can choose to fetch the full document from the interregional xds repository, e.g. the full radiology report including the medical question and medical history. This report is fetched as a hl7 cda-i. The information tiering is described in section 3.1. The interregional xds archive supports both modern xds.b queries as well as legacy xds.a sql like queries. Furthermore the interregional xds repository supports streaming of large files directly from and to the storage through https. This is important for large media files such as hd video. 5.1 Deviations from the IHE Profile A few deviations from the ihe xds profile are made in order to adapt the solution for the Nordic region, c.f. section 3.7. The interregional xds is running without a ihe pix. The reason for this is that the only patient identifiers used are the unique national patient identifiers. Emergency numbers are merged. The absence of a pix manager moves the responsibility of acquiring a complete patient history, e.g. patient merge, to the consumer. Although wado access is required and provided, a more efficient streaming solution for interregional image viewing is recommended. 15

22 5. Querying the Interregional XDS Archive 5.2 Connecting a New Consumer Region Zealand provides a complete test system for validating new consumers. A validation process of a new consumer may be carried out by the data governor of the solution. This process guarantees that the new consumer queries according to the given specifications. The validation will also ensure that the security considerations at the consuming end are fulfilled. Whether a validation processes is needed is decided on a case-by-case basis. 5.3 Security Only trusted gateways from the other regions will be allowed. The authentication of the regional gateway is done through https access with client certification. The responsibility of logging and security handling lies with the connecting region. The regional gateway is granted full access, c.f. section 3.8. For accessing the streaming viewer of region Zealand, the regional gateway will be able to open the viewer on a given examination and patient. The user will not be able to change patients. The responsibility of the logging and authorization will be of the regional gateway, since the streaming viewer will be launched with a system account. For the wado access, only the regional gateways will be allowed to access the wado archives of the other regions. The access is controlled by https with client certificates. 16

23 C h a p t e r 6 Using the Interregional Consumer An interregional consumer is provided for access to the interregional xds archive. This consumer can show a patient history list for a cpr number given by the user. The interregional consumer has the ability to start an advanced viewer for the non medical multimedia. It can also launch a streaming viewer for efficient remote viewing of interregional dicom images. In the first phase, the viewers provided by region Zealand will be integrated. Once other regions connect, the interregional consumer can be integrated with remote viewers that will be made available by the connecting regions. 6.1 Security Trusted servers in the regions are given access to the interregional solution. It is the responsibility of that trusted server or the region that hosts it to handle security. The username of the user that accesses the XDS through a trusted server needs to be supplied as a parameter for logging purposes. All access to the consumer is performed via https. Communication with the image viewers is also encrypted. Once logged in, the user is able to search for any cpr number. The search and access to patients are logged. In future versions, the interregional consumer can be expanded with other authentication and context synchronization methods. Also, further integration with a national authentication and authorization system is possible. 17

24 6. Using the Interregional Consumer 18

25 A p p e n d i x A Addresses to the interregional XDS The interregional services are accesible through the Sundehetsdatanetet. All connections are made from the connecting regions towards the interregional service. Hence only outgoing traffic is needed to be opened in the regional firewalls. All traffic is tcp. A.1 Production The table A.1 describes the sdn addresses for the interregional production solution. The addresses are to be assigned later. Table A.1. The server on the SDN for the production environment SDN Service SDN Address SDN port Comment XDS Repository 80,443 XDS Consumer 80,443 XDS Registry 80,443 Medimaker 80,443 EasyViz Viewer 80, 10001, 10002, WADO 8080 A.2 Test The table A.2 describes the sdn addresses for the interregional test system. 19

26 A. Addresses to the interregional XDS Table A.2. The server on the SDN for the test environment SDN Service SDN Address SDN Comment port Interregionalt Billedindeks Test - XDS Repository ,443 Interregionalt Billedindeks Test - XDS Consumer ,443 Interregionalt Billedindeks Test - XDS Registry ,443 Interregionalt Billedindeks Test - Medimaker ,443 Interregionalt Billedindeks Test - Render Node/DB , EasyViz 10001, 10002, Interregionalt Billedindeks Test - Render Node/DB WADO 20

27 A p p e n d i x B List of included document 21

28 B. List of included document Table B.1. List of included documents in the interregional specification Document Version Description CDA for Imaging Implementation Guide 1.2 Describes constraints on the CDA Header and Body elements for Diagnostic Imaging Reports for the information sources in the Interregional Billedbroker. Interregional Integration Describes the different transactions that take place when documents are sent to and retrieved from the Interregional XDS Repository XDS Source Implementation Guide This specification defines the XDS metadata for extrinsicobjects (document entries) and registrypackages (submission sets) used in XDS-I Profile and provide examples MVC-Interregional This specification defines the codes and oids used in the solution. Messages and how they are related 1.0 This document gives an overview of the message types sent from the different components within the Region Zealand XDS solution and how they are related 22