Image sharing using Facebook: fact or fiction?

There are several mechanisms and methods for sharing medical images between healthcare practitioners depending on the workflow scenario and the architecture used. Some of these applications have been in use for at least 20 years, some of them are still being developed, and some of these solutions might not make sense today but could very well change how we share images in the near future. Some of these applications might seem far-fetched, in particular with regard to exchanging images 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 the 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 look at the Facebook image-sharing scenario, I want to describe the use-case scenarios and then look at how we can accomplish this using different architectures, list the communication options, and discuss the maturity of these solutions.

Use cases: There are many clinical disciplines that need to exchange images, the most common is  the exchange of radiology images for review and evaluation, however, practitioners in pathology, ophthalmology, dermatology and many other specialties also require image sharing. The most popular use cases are as follows:

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 timeframe, e.g. 15-30 minutes. A more detailed report is often created when a radiologist or other specialty practitioner is available, e.g. during regular working hours.

Primary radiology coverage

This is when a radiologist is not present onsite, such 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 commonly used when new modalities or acquisition techniques are implemented, such as CT/PET or MR/PET, or if the occurrence of a certain disease is not common in a particular region, for example, when a patient returns sick from travel to a tropical country to the US where physicians might not be familiar with let’s say malaria. This scenario is where social media also might play a role.

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, the previous study could be used to assess the patient’s condition without having to repeat that procedure again. This scenario “re-uses” the studies and reports as input to diagnosis and further treatment.

Implementation: Each image sharing application does not necessarily have a single implementation but a certain use case can be implemented using different methods, however, 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 ER, 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 system 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, but the advantage is that there is a copy available at the PACS as that is 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, which 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 system. The same workflow is used whether the radiologist reads the images locally, or he or she accesses the PACS from a remote location.

Aggregate PACS: If the radiologists have to read from multiple different PACS systems, 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 systems from different vendors. The images are therefore routed from either the modality or the PACS to a Teleradiology PACS server, which aggregates the multiple work lists. The radiologist retrieves them from the Teleradiology server and does the reporting. The workstation uses a new “combined” worklist.

PACS web server: Several PACS systems 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, which 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 less sophisticated as when using the aggregate PACS worklist. The advantage of a separate vs. 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 that 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 health record 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 one could do its own 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 or 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, i.e. 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 uses the same architecture as used by the commercial cloud provider, however, the implementation follows open standards. The HIE can be private, for example as established within a provider network with several hospitals and/or clinics, or it can be public, for example as those being established as part of the incentives by the US federal government to improve healthcare.

Image sharing using a Personal Health record (PHR): The main application of the many PHR’s that are being rolled out are scheduling appointments, re-ordering prescriptions, having access to physicians notes and maintaining a communication channel between the patient and provider. The ultimate PHR would also allow for maintaining certain healthcare information, and it could be used for a patient 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, which has its own logistics and interoperability challenges. A chronically sick patient might have literally dozens of CD’s that need to be exchanged at each appointment with a different specialist. There are still institutions that do not create images compliant with standards, making them impossible to read and/or import in a workstation for comparison. The AMA has complained about the wide variety of embedded image viewers, however, the resulting IHE profile definition, which is an attempt to standardize features and icons, does not seem to have gotten much traction. This is still the most common method of exchanging images for referral, which hopefully 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 that use their own Facebook or other social network to ask for advice. This is still an exception, and seems to contradict the increasing emphasis on patient privacy, however, I would argue that if a patient has no interest in keeping his information private, but rather would like to get as much exposure as possible for these images in order to get as many opinions as possible, this might be a valid option.

Connectivity: The 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:

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. In the case that one uses the public Internet, a 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, making sure that delivery is taken care of. This edge server talks to a server or a destination that has the reverse gateway, i.e. 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 not common.

EML- Email: Emailing an image poses quite a few issues as 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, which are created for that purpose. DICOM has addressed this but the DICOM email has never taken off in the US, 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 CDA or Clinical Document Architecture, which can exchange all relevant information between the Personal Health Record and a Electronic Medical Record.

XDS-I - Cross Document-Image sharing: 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 a 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 Vendor Neutral Archive or VNA, however the number of institutions that actually use this protocol, especially in the US, 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 Image exchange method (XDR-I). These are not using a registry but providing 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 which 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, however 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 using 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 impacts the image quality. Therefore, one can typically only see gross anatomy and small findings are almost certainly not visible.

The table below shows the use cases with their typical architectures and the communication options that would be commonly used.

		Use cases
		Em. Medicine	Prim. Reading	Second Opinion	Referral
Implementation	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

Maturity: Some of the architectures and connections as described above are very mature, as a matter of fact, Teleradiology was implemented widely during the 1990’s, but some of these methods such as cloud services, the use of the XDS protocol, and Restful Services are still very much in their infancy. One way  to express the maturity is by using the “hype cycle” used by the IT consulting firm Gartner, which is used to represent the maturity, adoption and social application of emerging technologies. It maps maturity against visibility in a curve and it identifies five phases:  1) the technology trigger, where a potential new technology kicks off, 2) the peak of the inflated expectations, when a number of success stories as well as failures are produced, 3) the trough of disillusionment, when interest wanes as implementations fail to deliver, 4) the scope of enlightenment when the technology is starting to be understood and 5) the plateau of productivity when mainstream adoption takes off. I have listed my assessment of these technologies on this curve in the figure below.

In conclusion, there are many reasons for image exchange, and several different architectures and implementations with different communication mechanisms. Each has its advantages, some of which are very mature and some still very immature. 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 hype cycle. Time will tell which method and protocol will prevail, but, as with any technology, at that time there will be other technologies pushing the curve, which makes this field so interesting and never boring.