The RSNA Image Sharing Network

Abstract

In the era of health information exchanges, there are trade-offs to consider when sharing a patient’s medical record among all providers that a patient might choose. Exchange among in-network partners on the same electronic medical records (EMR) and other integrated information systems is trivial. The patient identifier is common, as are the relevant departmental systems, to all providers. Difficulties arise when patient records including images (and reports) must be shared among different networks and even with the patients themselves. The National Institutes of Health (NIH) challenged Radiological Society of North America (RSNA) to develop a transport method that could supersede the need for physical media (for patients or other providers), replace point-to-point private networks among providers, and enable image exchange on an ad hoc basis between arbitrary health networks without long legal delays. In concert with the evolving US health care paradigm, patient engagement was to be fundamental. With Integrating Healthcare Enterprise’s (IHE’s) help, the challenge has been met with an operational system.

Introduction and Background

HIEs…the (next) final frontier. This is the voyage of the industry—health care. Its latest mission: to explore strange new business models, to seek out new patients and new accountable care organizations, to boldly perform ad-hoc image (and report) exchange with Enterprises that have never been exchanged with - before.

For those of us who do not live in the future, the reality of exchanging patient records is somewhat more prosaic and painful. In particular, imaging departments face a challenge that is perhaps a little bit beyond what sending other patient records entails. Fortunately, individuals at the IHE (Integrating the Healthcare Enterprise) have foreseen this need and created integration profiles to move the above scenario out of the realm of science fiction. Furthermore, the National Institutes of Health (NIH) has engaged forces to construct a reference implementation of those profiles. But we are getting ahead of our story.

Transmitting lab results, surgery notes, and other items deals mainly with text and perhaps tables of information in Health Level 7 (HL7) [1]. Radiology records transfer includes those items plus images, usually in Digital Imaging and Communications in Medicine (DICOM) format. In ascending difficulty, the following exchange scenarios are representative of what both the radiologist and clinician encounter:

1. A call from a primary care physician to a radiologist to consult on a patient exam that is on the clinical viewer in the same medical center of both the radiologist and clinician

2. A consultation request from a referring physician within the same health network (“Affinity Domain” in IHE parlance), but from another site on a different Picture Archiving and Communication System (PACS) (although using the same electronic medical records (EMR) and patient identifier grantor)

3. A consultation (or second opinion) from a colleague/patient that is from another network with different patient identifiers, exam identifiers, and maybe even in another state or country

The solutions for the above examples are understandably varied and get progressively more complex as the separation of the patient data increases from the local PACS, Radiology Information System (RIS), and EMR. In the solutions below, we assume that the radiologist at the interpreting site will want any imaging study on their native RIS, PACS, and speech recognition system (so the radiologist does not have to break out of their normal working environment). With these caveats in mind, we propose approaches for the three scenarios described above.

1. Request is triggered by a page, phone call, email, or instant message from the clinician to the radiologist that asks a question about an exam on a patient. Demographics may be shared and synchronized via name or patient ID.

2. Request is triggered as in (a), but since only the patient IDs are in common and the images live on different PACS, various intermediate steps will need to be employed. For example, if both PACS lie behind the same firewall, it may be simplest to send the exam using DICOM from the performing site’s PACS to the interpreting sites’ PACS. Usually, there is a gateway or buffer that holds these examinations until an order is received for this exam; then, the exam’s DICOM header can be coerced to that order and then sent into the interpreting sites’ PACS [2].

3. In this case, no identifiers in the exam are recognized by the interpreting site. The exam comes from a site outside the firewall with different patient and exam identifiers. The data has to transit the site firewall somehow, either by physical media (i.e., CD or DVD), through a virtual private network (VPN), or via IHE Integration Profiles using web services (cross-enterprise document sharing (XDS), etc. to be discussed in the next section).

At the institution of two authors, the third scenario is being addressed in several ways: physical media, VPN, a “cloud” vendor, and the Radiological Society of North America (RSNA) Image Sharing Network. That site handles about 120 inbound CD/DVD per day and supports about two-dozen VPN partners. The former solution had a financial effect analysis done in 2009–2010, and it is estimated that it costs about US$35–40 per study to staff CD/DVD import desks. Importation follows the IHE Portable Data for Imaging (PDI) profile for physical media [3]. Media are mounted at a desktop PC and the files read to a server where a staff person looks at the demographics and seeks if the patient has been seen at the site before. If so, the new exam is ordered and the exam images coerced to that patient identifier. If not seen before, the REG/ADT system is invoked to create a new patient ID; then, the new exam order is made (including an accession number for the exam), and finally, the exam images coerced before being sent into the PACS for the consult/second opinion.

Using VPN accounts from high volume referrers essentially works the same way except images are sent via DICOM to the IHE-PDI importer. This approach avoids handling physical CDs but presents its own challenges; creation of the VPN account to the other site is a time-consuming process, primarily for lawyers to contract a Business Associate Agreement (BAA). Once a BAA is signed, the networking engineers must set up the VPN and maintain it. Because VPNs are by definition point-to-point constructs, each site has to support N network links and BAAs with their exchange partners (see Fig. 1).

Fig. 1.

The web of connections that arise from using point-to-point virtual private networks (VPNs). It’s not just the expense and maintenance that is associated with VPNs that is painful. Each line is the result of a Business Associate Agreement drafted by the attorneys at each end point. These negotiations are not fast and inhibit the ability to perform an ad hoc transfer among sites that have not already inked a BAA

Needless to say, neither of these two methods effectively enables prompt care of trauma patients that are from an out-of-network site. And trauma surgeons at the tertiary center are ill-served when the first views they have of the primary hospital CT exam are when the air ambulance lands and the CD is on the patient’s gurney. For these and other reasons, the IHE consortium investigated new integration profiles to deliver on the promise “…to boldly perform ad hoc image (and report) exchange with Enterprises that have not been exchanged with - before”. In 2009, the RSNA partnered with the vendor community to construct a reference implementation solution based on the IHE profiles. The Image Sharing Network (ISN) is funded by the NIH Contract NHLBI-PB-EB-2009-134-R00 and Contract HHSN268201200078C. The solution was to establish a patient-controlled exchange mechanism built on existing IHE profiles by image-enabling PHRs (patient health care records). The architecture is novel in that it combines patient interaction within the IHE profiles (as will be seen in “The ISN Model: Variations on a Theme”). The IHE underpinnings of the solution are detailed in the next section.

IHE Profiles for Image Exchange

To remain vendor agnostic, the network utilizes the IHE XDS standard for data exchange. The XDS profile from IHE IT Infrastructure Committees comprises a set of specifications for enabling the sharing of medical documents between health care enterprises. In the IHE model, an enterprise can span the range from an individual physician’s office to an integrated delivery network consisting multiple hospitals and clinics. Furthermore, the contents of a document are not limited to plain text, but can include images (such as DICOM) as well as formatted content, like PDFs or HL7 Clinical Document Architecture (CDA) documents.

The XDS profile (Fig. 2) assumes that all participating entities are part of an affinity domain: a shared set of policies (usually through legal agreements) and infrastructure for exchanging documents [4]. Within the XDS profile are four key systems (“actors” in IHE nomenclature) for mediating the sharing of data:

1. Document repository: is responsible for storing the actual contents of a document in a secure and reliable manner. An affinity domain may contain one or more document repositories.

2. Document registry: contains pointers to and metadata about documents stored in one of more repositories within the affinity domain. There is usually just a single registry within an affinity domain.

3. Document source: system responsible for uploading documents to the registry/repositories. An affinity domain usually contains multiple sources.

4. Document consumer: a system that downloads documents from the registry/repositories. As with the document source actor, there are usually multiple consumers within an affinity domain.

Fig. 2.

The IHE XDS (Cross-Enterprise Document Sharing) Actor-Transaction diagram

The actual exchange of data takes place through transactions, which in the case of XDS are SOAP (Simple Object Access Protocol)-based web service calls with an ebXML (Electronic Business Using eXtensible Markup Language) v3.0 payload. The key XDS transactions utilized by the image sharing network are as follows:

1. ITI-41 [Provide & Register Document Set]: The transaction by which a document source uploads documents to a document repository. Upon receipt of the document set, the repository indexes the associated documents in the registry using the ITI-42 [Register Document Set] transaction.

2. ITI-18 [Registry Stored Query]: The transaction employed by the document consumer to locate documents using document metadata such as medical record number. The result of the query is a set of document pointers to documents located in one or more repositories.

3. ITI-43 [Retrieve Document Set]: Transaction used by the document consumer to actually retrieve the contents of a document from a repository. The consumer uses the pointers obtained via the query transaction to determine the location of the documents and the unique identifiers required to retrieve them.

The process of sharing data begins with a document source uploading documents to a repository via an ITI-41 transaction. The repository indexes the documents with the registry which makes them available to the consumers within the affinity domain. When a consumer wishes to retrieve a document, it first performs an ITI-18 query against the registry. Once it has a list of matching documents, it performs ITI-43 transactions against the repository, one transaction to retrieve each document.

In recognition of the reality that imaging data is significantly larger than the data types XDS was originally designed for, the IHE Radiology Technical Committee extended the XDS specification to support transactions that have been optimized for medical imaging. This new specification, XDS-I (Fig. 3), adds numerous DICOM-based transactions as well as extends the SOAP-based ones to support XML-binary Optimized Packaging/Message Transmission Optimization Mechanism (XOP/MTOM) for the efficient transfer of binary data [5].

Fig. 3.

The IHE XDS-i Actor-Transaction diagram. The –I (imaging) version of XDS adds new transactions to enable the efficient transfer of binary (image) data

The XDS-I profile extends XDS by adding two new imaging centric actors and numerous transactions, two of which are SOAP based and utilized by the image share network:

1. Imaging Document Source: a system, such as a PACS or standalone workstation, that can publish DICOM instances to an XDS affinity domain.

2. Image Document Consumer: a system that can retrieve DICOM instances from an XDS affinity domain.

3. Provide and Register Imaging Document Set [RAD-68]: A SOAP-based transaction for uploading a manifest containing references to the DICOM images to be published. This transaction extends the ITI-41 Provide and Register Document Set transaction by utilizing the MTOM/XOP standard to facilitate the transfer of binary data within a SOAP message. It should be noted that the RAD-68 does not include the DICOM images themselves. Instead, the images continue to reside on the imaging document source and can be accessed using the RAD-69 transaction described below.

4. Retrieve Imaging Document Set [RAD-69]: an MTOM/XOP-optimized SOAP-based transaction for retrieving the actual DICOM instances from the imaging document source.

As with XDS, the process of sharing images begins with a source actor, in this case the imaging document source, which performs a RAD-68 to upload a manifest to the repository. The manifest contains references to the DICOM instances to be shared. The repository indexes those references in the registry, so they become available to the rest of the affinity domain. When an imaging document consumer wishes to retrieve images, it first uses ITI-18 and ITI-43 queries to locate and retrieve the manifest(s) of interest. It then extracts the references and uses them to retrieve the actual instances from the imaging document source via the RAD-69 transaction.

The ISN Model: Variations on a Theme

The ISN implementation of XDS-I departs in some significant ways from the description in the prior section. Its first and primary use case was to provide a patient-controlled network through image-enabled PHRs. An early, overarching concern of the Steering Committee (SC) was to maintain patient confidentiality in an environment that went beyond an affinity domain—thus an open network, the full Internet. This was addressed by not having protected health information (PHI) in the patient identity cross reference manager (PIX Manager) in an “RSNA Clearing House (CH)”. Thus, there are no patient demographics in the CH. It also means that there is no means for the ISN Edge Servers (to be discussed below) to automatically coerce study demographics on importation from the sending site to a receiving site. Instead, the approach of the ISN design is that it is the delivery truck, delivering a package from one site to another. It is on the receiver’s side that patient demographics must be matched and coerced and new orders placed into that site’s EMR, RIS, and PACS for the images of the study to profile to. Rather than live PHI being used to index studies on the CH, a hash is created at the sending site that is a function of the patient’s date of birth, a password of their choosing, and their email address or a system-generated random token. To access the submission sets later from the CH, a request has to be able to reproduce these three factors. The upshot of all this effort is that the submission set (including images and reports) is encrypted as soon as it leaves the medical center with factors known only to the patient and only stored and transmitted in the encrypted form. As a final precaution, all connections to the CH are over secure Hypertext Transfer Protocol (HTTP) (Secure Socket Layer) links where authenticated certificates are exchanged by trusted representatives from lifeImage (the CH subcontracted vendor) and the other end point (the medical center or PHR vendor).

Another key point is that the members of the ISN do not share BAAs with each other, but rather between themselves and the CH vendor. This legal construct is the principle that allows one ISN member to exchange with another, even if they never have before. This works because the CH vendor then gives control to the patient, and the patient is not constrained by Health Insurance Portability and Accountability Act (HIPAA) to limit access and can provide access to any health care provider they wish, just as they can give a CD.

It is worth noting that the ISN is tasked with three distinct use cases:

• Patient centric use case

  The Image Share network was initially designed to supplement or replace existing processes for providing images to patients on removable media (CD, DVD). Patient enrollment involves some direct interaction with the patient and use of the browser-based Edge Server application. Dedicated staff, typically those currently responsible for burning CDs (such as “film or digital library” staff), and dedicated hardware, use a desktop PC with a Web browser to access the Edge Server over the network. The data flow consists of HL7 orders and reports flowing from the RIS to the ISN. If the patient desires, they contact file room staff and select which studies they want sent to the CH. They are also provided with information about the PHR options that have been vetted to work with the ISN. Thereupon they go home, create a PHR account on their preferred vendor, and access their studies from the CH by reproducing the above-defined hash.

• Site to site clinical transfer

  In this use case, two sites have decided in advance to share data for clinical reasons. A common situation would be a trauma case that requires remote consultation. For sites that have a number of partners and specialists distributed among dispersed sites, the ISN simplifies the configuration and transmission of images as follows:

  1. A patient is seen at clinical site A and has one or more imaging studies.
  2. Physicians at site A decide they need a radiologist at site B to interpret the images. A staff member at site A transmits the imaging study to the Image Clearinghouse without waiting for a report to be generated. The destination selection creates a hash which uses keys that are selected by site B.
  3. The ISN at site B queries the CH constantly (polls) for imaging studies that are encoded with site B’s hash. When a study is fetched, it is pulled from the CH and sent to site B’s importation tools where the radiologist views them on the local PACS, reads the images, and consults with the physicians at site A.
  4. Images remain fully identified to support clinical care. [Note: this does not contradict the earlier statement that the CH retains no PHI. The CH registry only knows the hash that an exam set was submitted with. It never knows a patient’s name, medical record number, or anything else of a personal nature. And the image set remains encrypted with the 30-day duration of its life on the CH. Only when the image set is pulled to the destination and the correct key applied is the image set unlocked and the PHI exposed.]

• Site to site research transfer

  In imaging-based clinical trials, imaging centers submit de-identified images to an imaging core where data analysis, image interpretation, and/or reader studies occur. Different imaging cores use different de-identification software and transmission mechanisms, requiring imaging centers to maintain multiple applications. The ISN provides a single solution for imaging sites and allows sites to share de-identified images with multiple imaging cores.

  1. A research participant is seen at an imaging center and has one or more imaging studies.
  2. A staff member at the imaging center initiates a data transfer to the Image Clearinghouse that de-identifies the image data and associates the data with the proper clinical trial.
  3. An automated process at the imaging core polls the CH and retrieves imaging data intended for that imaging core.

The following figures show the conceptual design of the ISN design as it’s currently built (Fig. 4). As intimated above, each site has an Edge Server; it performs several functions. Within the firewall of the medical center, the ISN receives unsolicited HL7 orders and reports from the Radiology Information System. This feed enables the ISN to construct a list of patients and their imaging studies. The Edge Server also links to the PACS in one of two ways; in clinical/patient mode, the ISN issues C-MOVES to itself to support clinical moves with PHI. In the research mode, unsolicited C-Stores are sent from PACS to the ISN for de-identification. In all cases, links within the medical center firewall are unencrypted; the links beyond the firewall are encrypted over HTTP using Secure Sockets Layer.

Fig. 4.

A simplified view of the components in the Image Sharing Network (ISN). Shown are an ISN Edge Server, the Clearing House, and the conceptual transactions that flow among them. Transactions within the firewall are unencrypted DICOM and HL7 messages. Outside the firewall, XDS messages to the CH are over secure HTTP (HTTPS) akin to internet shopping

The next figure explodes the details of the CH to reveal its XDS nature; the detailed XDS transactions are also shown (Fig. 5).

Fig. 5.

An exploded view of the Clearing House, detailing the XDS transactions alluded to in the previous figure. In place of real patient Identifiers that would typically be used in an XDS-b.i implementation, the ISN substitutes a three-factor hash consisting of data only the patient knows. All these transactions are over secure HTTP links, and the submitted document set is also encrypted via the aforementioned hash

The next figure lists what is presented to an operator via a web page when they wish to create a job to send patient studies to the CH (Fig. 6).

Fig. 6.

The web page an operator sees when they select a patient and studies to send to the Clearing House

Upon selecting a patient and their studies, the following steps occur. First, the Edge Server fetches the selected studies from the PACS using a DICOM C-MOVE request. After all studies have been acquired, they (along with the related reports) are rolled into an XDS-i submission set. A manifest file is created which lists all documents (and any subparts). The submission set is encrypted using the aforementioned hash. Finally, an HTTPS session is opened to the CH; the manifest and all documents are sent to the Repository in a single XDS submission set. The key required to index and fetch that submission set is the hash. Whether it is the patient using a patient health record (PHR) to see their own images or another medical center using an XDS compliant Edge Server (either RSNA’s or third party), they have to be able to reproduce the factors to generate the hash and fetch the submission set. Retrieved or not, 30 days after being sent to the CH, the submission set is deleted from the CH. This serves two purposes: it protects patient privacy by reducing excess copies of their PHI, and it controls storage costs for the CH vendor.

The ISN software is architected on an all open source stack. The operating system is Ubuntu Linux (Canonical Group Limited, London, UK). The database engine is PostgreSQL (PostgreSQL Association, Hood River OR). The Mirth HL7 engine is used to receive and map RIS orders and reports to the application database (MIRTH Corporation, Costa Mesa, CA). The DICOM toolkit used is dcm4che2 (http://www.dcm4che.org/). The Glassfish Java servlet engine is used to run the web-based application user interface (Oracle Corporation, Redwood Shores, CA). And the XDS Java library used is the Open Health Tools toolkit (Open Health Tools, Vienna, VA). All other software was written by the members of the consortium using Java-compatible languages. All of the aforementioned items have business compatible open source licenses. Because the software is freely redistributable, it is convenient to ship it as a “virtual appliance” [6]. The Edge Server is packaged as a virtual machine that can be run on VMWare (VMWare Corp, New York, NY), Hyper-V (Microsoft Corporation, Redmond, WA), Virtualbox (Oracle Corporation, Redwood Shores, CA), or KVM (Redhat Corporation, Raleigh, NC).

Results

Software

As of this writing, the ISN software is at version 3.1 and all primary use cases have been achieved. Recent improvements have been undertaken to ease system administration (alerting system administrators of failures via email) and sending emails to patients to alert them when they have new studies on the CH to view. As this project was funded by the NIH, all codes and documentation are open source and available at Github [7]. The adventurous can proceed there to download both source and an installer if they choose to build an Edge Server from scratch. For those who prefer a run-ready appliance, a virtual machine is available as well [8].

Documentation

Aside from the source code, a complete set of documentation is available at the same sites as the software mentioned above. It has been arranged for specific audiences. There is an executive overview of the ISN project (its components, architecture, and requirements) for medical center leadership (medical, administrative, information technology, and HIPAA officers). There is also a set of requirements, design, testing, and change log documents for regulatory audiences (i.e., the FDA). A quick start guide has been written for ISN file room users who will perform the actual study export tasks. For the team assigned to install and support the Edge Server, an installation and user manual has been written. And finally, for the patients, there is an overview of the ISN project and the process by which they may request and collect their imaging studies.

Participants

Aside from the patients themselves, the ISN effort consists of numerous participants. Medical Centers currently using it include the original participating sites (Mount Sinai, University of Maryland, University of Chicago, Mayo Clinic, and University of California San Francisco). In addition to the founders, the following sites have also joined: Saint Barnabas Health, Advanced Radiology Consultants, and Gillette Children’s Hospital. The CH itself is being hosted by lifeImage (lifeImage, Newton, MA). Currently approved PHR vendors are lifeImage LINCS, DICOM Grid (DICOM Grid Corporation, Phoenix, AZ), Dell Passport (Dell Corp, Round Rock, TX) and itMD.

Volumes

Since Jan 2012, the CH has received over 40,000 studies representing over 9,000 separate patients. Of the uploaded studies, a little over 12,000 have been pulled by study consumers (PHRs, other medical centers, or core research labs). It thought that some of this asymmetry is due to patients forgetting to “pick up” their studies, and this may be mitigated by the new email feature which alerts patients when they have new studies to be fetched. Finally, about 30,000 studies have been purged from the CH after the 30-day expiration has passed.

Performance

To characterize performance, one must specify of what component. The HL7 Mirth channel is taking over 50,000 messages a day at some sites. The speed of the DICOM transfer from PACS to the ISN at one author’s site averages about 6–8 CT images/s. Both these metrics (and others) are highly dependent upon several factors: the native capacity of the site’s PACS and RIS, the bandwidth of the network links to the Edge Server, and most important of all the CPU power and RAM assigned to the ISN virtual machine (or physical machine if one is used). In the example cited above, ample performance is seen if the VM is granted four 2-GHz cores and 8 GB of RAM [9]. Another metric is the transfer rate of the XDS submission sets to the CH. Again, using the site referred to above, rates of 4–5 MB/s, is typical. In addition to the prior dependencies, this metric is dependent on the latency of the network connection between the medical center and the CH [10].

Future Work

The first priority in continuing work on the Image Share network is to expand the network to new sites and increase the number of patients participating. Image sharing is, like other patient-controlled health records, in its early phases of adoption. An expanded presence at a greater number of sites is needed to establish the expectation of Web-based, patient-controlled access to personal health records. Patient demand will ultimately bring image-enabled personal health records to the tipping point that makes them a sustainable business reality and an expected part of clinical care. RSNA and the project team of researchers and developers from six leading care sites are working with their vendor partners to link additional sites to the Image Share network. They are also expanding education and promotional materials available to participating radiology sites to increase recruitment of patient participants.

Convenience and ease of use will also expand patient use of the system. The project team plans refinements to the usability of the system for patients and site personnel alike. The authentication and security model will be brought into closer alignment with the ones used by widely adopted Web applications. Communication of access information and instructions via email will be enhanced, as will communication to site personnel of notifications regarding site-to-site transfer of information.

The participants recognize that a single translational research effort will likely not be sufficient to establish widespread use of image-enabled personal health records in the US health system. They are encouraging vendors to expand the network further by incorporating the capabilities of the Edge Server into systems for image management and distribution (for example, import and export of images on removable media such as CDs) they provide to radiology sites. Effectively linking in their existing customer sites would greatly multiply the number of sites participating in the ISN. The standards-based approach used in defining the specifications for the Edge Server, Clearinghouse, and PHR participants facilitates addition of new participants.

The project team is also working to connect the ISN to other operating health information exchange networks. The development team recognizes that different mechanisms may support image exchange, e.g., HIEs, PHRs, and provider to provider exchange. The goal is to employ IHE XDS-based profiles whenever possible so that these solutions may live on a common infrastructure and interact in a cohesive transparent fashion. The IHE Cross-Community Access (XCA) profile complements the XDS.b profile by defining transactions between document registry/repositories (like the CH) to enable information access between networks. Agreements are in place to connect an XDS-based image sharing network with the ISN using this approach. To enable XDS networks based on the affinity domain model to use the patient-controlled security model adopted by the ISN, lifeIMAGE is developing a Web service that will generate the ISN token at the point of patient enrollment in the network. Site staff will be able to provide that token to use in retrieving their studies, the same model in use at other ISN sites. The project team has submitted a profile proposal to the IHE Information Technology Infrastructure (ITI) committee to define a standards-based method for incorporating support of patient-controlled secure access into an XDS-based health information exchange (HIE) environment and has committed to drafting a white paper on the subject. The project team is also exploring direct site-to-site and site-to-patient transfer of information using the IHE Cross-Enterprise Document Reliable Interchange (XDR) and Cross-Enterprise Document Media Interchange (XDM) profiles adopted by the Office of the National Coordinator for Health Information Technology (ONC) direct project and referenced in meaningful use certification requirements.

Finally, work is planned to enable participating sites to make use of the data they accumulate in their local Edge Servers for Quality Assurance (QA) Programs and Comparative Effectiveness Research (CER). The project team will conduct a series of pilot projects to expand the data capture and management capabilities of the Edge Server to include gathering and analyzing quality measures and outcome information, including measures supporting goals for the ONC’s meaningful use program. Planned enhancements include enabling the Edge Server to

1. Aggregate procedure information with standard procedure names from the RadLex Playbook and aggregate reports in structured document formats using RSNA’s RadLex uniform terminology. This information will be used in targeted data mining projects to support CER.

2. Gather patient radiation dose information associated with exams from CT and other radiation-emitting modalities for use in dose monitoring programs and inclusion in patient medical histories.

3. Capture image annotations, calculations, and other image metadata generated by radiologists and image post-processing applications using the Annotation and Image Markup (AIM) standard. This will enable clinical enhancements such as sharing of pertinent measurements from cardiovascular imaging or the quantitative imaging results from oncology studies.

The overall goal of these refinements will be to enhance the exiting abilities of an open, IHE-based reference model of image exchange mechanism for HIE’s, one that can be readily adapted to sustainable businesses offering products and services that enhance the patient experience and the quality, efficiency, and safety of care in radiology.