Healthcare practitioners can share medical images using a number of mechanisms and methods. Some of these applications have been in use for at least 20 years, some are still being developed, and some might not make sense today but could very well change how we share images in the near future.
Some applications might seem far-fetched, particularly regarding image exchange using social media. However, one should remember that the most common critique when Twitter was still in its infancy was that "it did not have a purpose" -- until the Arab Spring occurred, in which social media played a major role.
Therefore, I would not reject image sharing via social media as being far-fetched, but rather take it as a valid option. Before we consider image sharing on Facebook, I want to describe image sharing use-case scenarios and then look at how we can accomplish this with different architectures. I'll also list the communication options and discuss the maturity of these solutions.
Use cases
While radiology studies are the most commonly exchanged images for review and evaluation, practitioners in pathology, ophthalmology, dermatology, and many other specialties also require image sharing. The most popular use cases are described below.
Emergency medicine scenario: Often during off-hours, a study has to be reviewed and reported, causing a preliminary report to be generated and sent back to the requester within a very limited time frame, e.g., 15 to 30 minutes. A more detailed report is often created when a radiologist or other specialty practitioner is available, such as during regular working hours.
Herman Oosterwijk of OTech.Primary radiology coverage: This is when a radiologist is not present onsite, as is often the case in rural areas, or when a radiologist covers clinics in the suburbs or provides coverage for disaster or war zones. In this case, exchanging images with the onsite clinicians is essential. Instead of the "preliminary" read as used in the emergency scenario, the practitioner creates a final report.
Second opinion: When a specialist is looking for an opinion from a peer who might have more experience with a certain imaging modality or particular disease pattern, an image exchange is needed. This is common when new modalities or acquisition techniques are implemented, such as PET/CT or PET/MR. A sick patient may also present after returning to the U.S. following travel to a tropical country, and physicians might need a second opinion for a disease, such as malaria, that's uncommon in their particular region. Social media might also play a role in this scenario.
Comparison or referral: This occurs when the primary reason for the image exchange is not to make a diagnosis from the original study, as that already has taken place, but to have the previous studies available. For example, a patient is treated in another location, and previous exams have to be viewed for either comparison to a new study or, what is more often the case, to assess the patient's condition without having to repeat that procedure again. This scenario "reuses" the studies and reports as input to diagnosis and further treatment.
Implementation
Each image-sharing application does not necessarily have a single implementation. A certain use case can be implemented using different methods, although some of the architectures are more suitable to specific use cases than others. Let's look at the mechanisms to exchange the studies.
Point-to-point modality to viewer: A technologist can push certain studies directly from a modality, such as a CT in an emergency room, to a doctor's home for review at his or her DICOM viewer. There is a direct connection from the CT to the physician.
PACS to viewer: A PACS could be set up to route all stat studies arriving from a modality directly to a physician's workstation. This is similar to the point-to-point modality to viewer push approach, but it offers the advantage of having a copy available at the PACS to be used as an intermediary. If there are multiple modalities that have to share images, the sending can be centralized from a single source, i.e., the PACS router. If a PACS does not support sophisticated routing using rules determined by information in the image header in order to determine what information goes where, one could use an add-on image router that can be provided by several manufacturers.
PACS worklist: Images are sent to the PACS, and the radiologist has access to the PACS worklist using the PACS workstation. The workflow management features of the PACS can be used to indicate which studies are stat, which ones are being read, etc. This works well if a radiologist only reads from one hospital or multiple institutions that all have the same PACS. The same workflow is used whether the radiologist reads the images locally or accesses the PACS from a remote location.
Aggregate PACS: If the radiologists have to read from multiple, different PACS, it makes sense for them to use their own mini-PACS servers and worklist management. This is typically how nighthawk or emergency medicine works, as these radiologists support many different hospitals, each with their own PACS from different vendors. The images are therefore routed from either the modality or the PACS to a teleradiology PACS server, which aggregates the multiple worklists into a new "combined" worklist. The radiologist then retrieves the image from the teleradiology server and does the reporting.
PACS Web server: Several PACS provide a Web server, or one can purchase a Web server from a different vendor. The Web server can be embedded in the PACS core software or implemented as a separate hardware box that will have a copy of the images from the PACS. Images are typically retrieved over the Web and if one uses a true zero-footprint viewer, there is no trace left on the viewer after the user logs off, which satisfies privacy and security regulations. The worklist capabilities are often not present or are less sophisticated than when using the aggregate PACS worklist. However, the advantage of a separate versus an integrated Web server is that images are available even if the PACS might be down, and therefore this access type can also serve as a backup. One could also use a mini-Web server which gets the information directly from the acquisition modality, but this only makes sense for a small clinic with only one or two modalities and no PACS to speak of.
EMR: Instead of using a PACS, one can also use an electronic medical record (EMR) to view the images. The advantage is that there is much more contextual information available, including lab results, previous reports, patient history, etc. Image enabling of an EMR differs from vendor to vendor. One can use a PACS plug-in, which basically launches a viewer inside the EMR window after exchanging the appropriate context information such as an accession number, or do a query and retrieval from the EMR viewer to the PACS database or from an enterprise image manager and archive solution such as a vendor-neutral archive (VNA).
Image sharing using the cloud: Images can be exchanged using an external image-sharing service, which functions as a broker and forwards the images to the recipient. There are two versions: either the cloud service provider uses only a store-and-forward mechanism, or the cloud functions as a repository and keeps the images for a certain time period. Institutions need to subscribe to the cloud service provider for a fee. This solution makes sense for institutions that regularly exchange information but not often enough to warrant a dedicated link to each other. A good example would be an academic or specialty hospital with relationships with several other institutions in a geographic area that refer patients on a regular basis and want to exchange images. Note that the institution is tied into one particular cloud provider that exchanges the information, which is typically in a proprietary method.
Image sharing using a health information exchange (HIE): This implementation method employs the same architecture used by the commercial cloud provider, but it follows open standards. The HIE can be private, such as within a provider network with several hospitals and/or clinics, or it can be public, such as those being established as part of the incentives by the U.S. federal government to improve healthcare.
Image sharing using a personal health record (PHR): The main applications of the many PHRs that are being rolled out include scheduling appointments, reordering prescriptions, accessing physician notes, and maintaining a communication channel between the patient and provider. The ultimate PHR would also allow the maintenance of certain healthcare information, and it could be used for patients to upload their images to have them available whenever needed. A patient would simply authorize the provider access to the information, which can then be exchanged in a standard manner.
CD exchange: For comparison or referral purposes, images are often hand carried by the patient, a method that comes with its own logistics and interoperability challenges. A chronically sick patient might have literally dozens of CDs that need to be exchanged at each appointment with a different specialist. Also, there are still institutions that do not create these CDs in a standards-compliant manner, making them impossible to read and/or import to a workstation for comparison. The American Medical Association has complained about the wide variety of embedded image viewers, but, unfortunately, the resulting Integrating the Healthcare Enterprise (IHE) profile definition to standardize viewer features and icons does not seem to have gotten much traction. CDs are still the most common method of exchanging images for referral, which one hopes will be replaced in the not-too-distant future with other image-sharing options described here.
Image sharing using social media: It is not uncommon for patients to post their images publicly on the Internet, sometimes just to share them, but also to ask for advice, in particular if it concerns a rare disease or something that is hard to diagnose. It is similar to radiology portals posting their "case of the day" or of the week, but with the difference that the diagnosis is not (yet) known. There are also physicians who use their own Facebook account or other social network to ask for advice. This is still an exception, and it seems to contradict the increasing emphasis on patient privacy. However, I would argue that this might be a valid option if a patient has no interest in keeping his or her information private, but rather would like to get as much exposure as possible for these images to get as many opinions as possible.
Connectivity
Network connectivity between the sending and receiving sides can be implemented in different ways; some are more common for certain applications than others. The most common implementations are as follows.
SNKR -- Sneakernet: In the CD exchange scenario, the information is exchanged in person or by mail, commonly referred to as the "sneakernet."
PPDCM -- Point-to-point DICOM: Images are typically exchanged between modalities or a PACS and pushed to a remote viewing station or to a teleradiology PACS server using the DICOM format and protocol. If one is using the public Internet, a virtual private network (VPN) is set up to guarantee confidentiality of the information to be exchanged. The DICOM protocol relies on the reliable delivery by the underlying TCP/IP communication layers. If the bandwidth of the connection is limited and/or the study sizes are large, standard DICOM compression is used such as JPEG or wavelet (aka JPEG2000).
GTWAY -- DICOM to edge server/gateway: If the connection to the Internet is unreliable or not available, one might need to use alternative communication channels such as the phone network or dedicated satellite links. In that case, an edge server or gateway is used that converts the DICOM protocol in a proprietary protocol, which in most cases uses a high compression ratio and very robust communication protocol. The gateway functions as a store-and-forward box, ensuring delivery. This edge server talks to a server or a destination that has the reverse gateway, i.e., it makes sure the images are received without any corruption and preferably then uses DICOM to pass them on. This solution is common for teleradiology applications in rural areas or disaster and military zones.
PPP -- Point-to-point proprietary: This is commonly used by workstations that access the PACS server of the same vendor. They use the radiology worklist provided by the PACS, and, if they use a public network, a VPN is needed to encrypt the information being exchanged.
WEB -- Web-based protocol: The Web-server clients typically use a secure HTTPS protocol to access the images. Some PACS vendors also use HTTPS for regular in-house image access, but this is uncommon.
EML -- Email: Emailing an image poses quite a few issues because the images are quite large even if they are compressed, and there is no context information. This assumes that one uses secure email to start with and that the receiver can recognize the .dcm file extensions that are created for that purpose. DICOM has addressed this, but the DICOM email has never taken off in the U.S., although it has been implemented in Germany and is somewhat common there.
XPHR -- Personal Health Record Exchange: This is an HL7 version 3 document exchange definition using the Clinical Document Architecture (CDA), which can exchange all relevant information between the PHR and EMR.
XDS-I -- Cross-Enterprise Document Sharing for Imaging: The IHE organization has defined a series of profiles, including how to exchange documents and images. The XDS-I profile uses a series of transactions that allow an image producer and consumer to exchange both registry and repository information with an HIE. The image exchange uses the Web version of the DICOM protocol, aka WADO, or Web Access to DICOM Objects. The XDS-I protocol is widely implemented by PACS vendors, especially those who claim to offer a VNA. However, the number of institutions that actually use this protocol, especially in the U.S., is still relatively sparse. Note that there are also different variants of this mechanism defined by IHE, i.e., the Cross Community Access for Imaging (XCA-I) and the Cross-Enterprise Document Reliable Interchange of Images (XDR-I). These don't use a registry but provide a direct query/retrieve and push mechanism for image exchange. These implementations are also still in their infancy.
RSTF -- Restful Services: A new version of the DICOM protocol is being defined that expands beyond the WADO protocol and has greater functionality. The "traditional" DICOM protocol that includes a negotiation step to set up the association between two devices and uses the DICOM-specific set of commands is not that suitable for accessing information over the Web. This new DICOM extension is still very much in its early phases, but it might become popular as the need for Web-based access, especially from embedded viewers in an EMR, becomes common.
INT -- Internet: Uploading images on a server via a proprietary protocol is typically used by social media, such as Facebook or other image-sharing services. The image would have to be converted to a Web-friendly image type such as JPEG or TIFF, which almost certainly affects the image quality. Therefore, one can typically only see gross anatomy; small findings are almost certainly not visible.
| Use cases with typical architectures and communication options | ||||
| Emergency medicine | Primary reading | Second opinion | Referral | |
| Modality to viewer | PPDCM, GTWAY | PPDCM, GTWAY | EML | EML |
| PACS to viewer | PPDCM, GTWAY | PPDCM, GTWAY | EML | EML |
| PACS worklist | PPP | PPP | ||
| Multiple PACS | PPP | PPP | ||
| PACS Web server | WEB, GTWAY | WEB, GTWAY | ||
| EMR access | WEB, GTWAY | WEB, GTWAY, RSTF | WEB, GTWAY, RSTF | |
| Cloud sharing | GTWAY, EML, RSTF | GTWAY, EML, RSTF | ||
| HIE sharing | XDS-I, RSTF | XDS-I, RSTF | ||
| PHR sharing | XPHR | XPHR | ||
| CD exchange | SNKR | SNKR | SNKR | |
| Social media | INT | |||
Some of the architectures and connections as described above are very mature, while others are very young. Teleradiology was implemented widely during the 1990s, but some of these methods such as cloud services, the XDS protocol, and Restful Services are still very much in their infancy.
There are many reasons for image exchange and several different architectures and implementations with different communication mechanisms. Both the industry and provider community are trying to figure out how and what to do, knowing that many of the solutions are still in the early phases of the technology hype cycle. Time will tell which method and protocol will prevail, but, as with any technology, there will always be other technologies pushing the curve. That makes this field so interesting and never boring.
Herman Oosterwijk is president of OTech, a healthcare imaging and IT company specializing in EMR, PACS, DICOM, and HL7 training.
The comments and observations expressed herein are those of the author and do not necessarily reflect the opinions of AuntMinnie.com.
