Terms & Keywords
Healthcare professionals have a need to store and access relevant medical documents for any patient under care. Document creation and submission, query & retrieval functions, and secure access must span the healthcare enterprise to provide timely care in the most efficient manner.
Patient exams that include imaging of varying types of modalities and diagnostic reports ultimately belong to the patient, and only the patient has the right to share this information with other caregiving facilities. Strict HIPAA compliance requires that any PHR must always be treated with utmost security and never leave the designated secure areas.
In Radiology, the process begins when an order for an exam is placed by a physician. As part of this process, a local patient-identifier is generated for the order. However, for the lifetime of the patient, there is a global, unique patient identifier that spans the healthcare enterprise. Any Electronic Medical Record must then be tracked and accessible via this global patient ID.
An EMPI or Enterprise Master Patient Index system that is deployed across the healthcare organization helps maintain a consistent and accurate view of a patient’s identity. This database identifies the patient by use of a Global Unique Patient Identifier and accesses the patient record. The patient record contains patient demographics such as date-of-birth, place-of-birth, current address, and numerous other fields. Any variances or multiple records result in the merging or linking of extant records. Tolerance for error is close to zero and is a huge challenge in maintaining integrity across the healthcare enterprise.
IHE (Integrating Healthcare Enterprise) specifications pull together many industry standards such as DICOM, DICOMWeb, MTOM/XOM and more to provide a technical framework (TF) for integrating healthcare systems. This technical-framework specifies IHE-Actors and their Transactions which, when combined together, define a specific integration profile. IHE Profiles can cover various aspects of Healthcare Integration are specified in the following documents:
- IHE ITI TF-1
- IHE ITI TF-2a and IHE ITI TF-2b
- IHE ITI TF-2x
- IHE ITI TF-3
The Radiology specific profiles are provided in the specifications listed below. The radiology profiles are based on the general specifications but provide additional protocols and fields that apply to Radiology. These sets of specifications also detail the RSNA Image Sharing Network requirements.
- IHE RAD TF-1
- IHE RAD TF-2
- IHE RAD TF-3
- TF Supplement for Cross-enterprise Document Reliable Interchange of Images – XDR-I
- TF Supplement for Cross-enterprise Document Sharing for Imaging – XDS-I.b
There are numerous subfields of Radiology that are specified in IHE and IHE-RAD specifications, but the rest of this post mainly focuses on describing Integration Profiles required for the implementation of an Image Sharing Network.
The reference graph below shows a combination of actors and the SOAP transaction used to carry out the workflow.
There is a distinct Client / Server relationship where the ISN provides services that allow the clients to perform the following:
- Document submissions on behalf of a patient
- Query and Retrieve transactions for the retrieval of
- Patient information
- Image-manifests associated with an exam
- Diagnostic reports
- Images associated with the exams
Within the ISN, various actors implement integration profiles in order to
- Register a patient when a new order is generated
- Persist received images to a permanent store
- Register diagnostic reports and Image Manifest to support future query
- Retrieve documents from a permanent store and serve them out to the external clients
Fig.1 ISN Reference Model
Sponsored by a grant from NIBIB, RSNA, Mayo Clinic, and research facilities associated with universities were given a charter to build a patient-centric image sharing network (ISN). This network is designed to automate and improve Radiology workflows by facilitating storage of patient documents to the cloud.
Rather than provide a copy of the exam on a CD, the patient can now choose to receive the exam electronically. This has significant implications, such as
- Patient exams are centrally available
- Patient documents can easily be accessed by any clinician providing care to the patient.
- The study does not have to be repeated if the patient has traveled to another region and needs care
lifeIMAGE, a startup company based in Newton, MA, provided the ISN solution to RSNA based workflows. lifeIMAGE was part of the original research group that pioneered the end to end solution strictly based on IHE & IHE-RAD specifications.
The engineering team from BigR.io participated in the ISN Architecture evolution, its implementation, and subsequently validation and interoperability testing at Collectathons where vendors are required to perform live tests against other vendors in order to show full conformance. BigR.io, in collaboration with lifeIMAGE resources, demonstrated pure excellence in showing conformance and also assisted other teams to meet their objectives.
BigR.io’s knowledge in navigating a plethora of standards, such as DICOM and HL7, and its ability to innovate has proven to be a great asset towards providing a sound and robust solution.
The remainder of this post briefly provides the architecture and workflow details, specifically the RSNA Workflow.
ISN Reference Model and Workflow
The ISN Reference Model as shown in Fig.1 comprises three major functions:
- The Edge Server Function
- lifeIMAGE Registry as a Service
- Patient Health Record Account Access
The Edge Server Function
The edge server Function is an application that integrates with RIS and PACS and is deployed on-premise in a healthcare facility. Participating healthcare enterprises are designated an Affinity Domain. The ISN Service itself is multi-tenant and is capable of supporting multiple Affinity Domains.
The workflow begins when an order is entered in the RIS. At this time, a local patient identifier is generated and registered with the PIX-Manager. The PIX associates the patient identifier to a global patient-identifier, and a new global patient identifier is created if one is not found.
On completion of the exam, the edge server constructs an XDR-i-based Provide & Register SOAP Request and sends the submission request to the lifeIMAGE Registry. The request can include the following:
- Diagnostic Reports – HL7 Service is used to obtain diagnostic reports
- Images (different modalities) – DICOM Service is used to obtain all images and MTOM/XOP is used to attach images to the SOAP Request
- Metadata describing the request and patient information
- Both local and global patient identifiers are sent with the Request
Note that XDR-i does not require the Image Manifest (KOS) as this is built by the XDR-Imaging Recipient component in the Clearinghouse.
The lifeIMAGE Registry or Clearinghouse
The Clearinghouse is a hosted service. Any number of Healthcare Enterprises may subscribe to this service to conduct their desired workflows.
The service is made up of various IHE-specified Actors and these Actors implement the IHE/RAD specific Integration Profiles. Actors & their transactions are as follows:
1. XDR.Imaging Document Recipient (IDR)
- The recipient can receive incoming SOAP Requests over any affinity-domain.
- On receiving a valid request, the recipient retrieves all attachments and persists the data as necessary
2. XDS Imaging Document Source (IDS)
- IDR & IDS are grouped actors, and as such, they collaborate in processing of Provide and Register SOAP Requests
- The IDS digests the received request to produce Image Manifest. This is metadata that describes the Images and Diagnostic Reports
- The image-manifest and the diagnostic reports are then registered with the Repository Actor
- To this effect, IDS acts as a Client. It generates a Register Imaging Document Set SOAP Messages and sends it to the XDS Repository Actor
3. XDS Repository
- XDS Repository is the keeper of Image Manifests (KOS) and Diagnostic Reports. It provides an ITI-43 Retrieve Document Set service to external clients
- The Repository acts as a Client and sends an ITI-41 Register Document Set-b to the XDS Registry
4. XDS Registry
- XDS Registry maintains a database of all registered exams. The metadata received in the ITI-41 is persisted and is made available for future queries
- The Registry provides an ITI-18 Registry Stored Query Service to the external clients
5. PIX manager
- The PIX Manager mainly tracks all Patient Identifiers and its API is used by the Edge Server and the PHR Access Points
- The PIX maintains a single Global Unique Patient Identifier for a given patient. It associates all local patient-identifiers to a single global patient identifier as required by the ISN
The Patient Health Record (PHR) Account Access
PHR is an Edge Application that allows the end-users such as clinicians to access documents such as diagnostic reports and images submitted for a given patient.
In the RSNA Workflow, the patient is given an access key to access their exam electronically. To perform these actions the following Actors are implemented in the PHR:
1. Document Consumer function
- The document consumer first checks in with the PIX Manager to obtain a global patient-identifier associated with the patient
- This identifier is then used to perform a Registry Stored Query, anITI-18 SOAP Message to XDS Registry Service
- The Registry returns metadata in the Response. This metadata is then used by the Imaging Document Consumer for image and report retrieval
2. Imaging Document Consumer function
- The Imaging Document Consumer uses RAD-69 Retrieve Imaging Document Set – SOAP Message to retrieve desired set of images from the XDS Imaging Document Source Service.
Integrating Healthcare Enterprise is actively working to bring necessary modernization and efficiencies to the healthcare industry. The patient-centric workflow to share diagnostic exams is just one example of the integration profiles. There is a fair amount of innovation that lies ahead of us to modernize and make healthcare enterprises IT Infrastructure secure, robust, and efficient.
About the author
Sushil is a Principal Architect at BigR.io. He leads a team of engineers from lifeIMAGE and BigR.io to deliver a robust, conforming solution for ISN.