Tuesday, May 1, 2018

Does a Deconstructed PACS make sense for you?


When I was a young student in engineering school I built my own “deconstructed” sound system. By Bombardon” bass speaker and tweeter (no, nothing to do with Twitter), veneered the enclosure and using speaker cloth for the front. It was a lot of fun but in a different time frame given the fact that Radio Shack just went bankrupt as people today don’t do this kind of thing anymore.
building I mean, tracing the printed circuit and etching out the tracks according to a published schematic, buying the components (capacitors, transistors, resistors, and transformer) at what was the equivalent of Radio Shack, building a chassis from aluminum and creating a front plate and enclosure. I even built my own speakers, using at that time what was the famous Philips “

So, why would anyone build their own PACS from the ground up? As with building any sophisticated electronics system, whether it is a sound system, a gaming computer, or a PACS system, it is not for the faint of heart. But, in some cases, it does make a lot of sense. Before deciding if it makes sense for you, let’s look at the pro’s and con’s.

Arguments “for” implementing a deconstructed PACS:

1.      You get best-of-breed – For example, you go to a trade show such as RSNA or SIIM and you see this really nice workstation that does everything you need, in other words it has all the bells and whistles you would ever want. Or you really need to use this super-duper modality worklist provider that allows you to filter the worklist by location, station name, referring physician, and much more. Or, you found a workstation worklist provider that allows you to manage different worklists from several PACS systems all from different vendors. You can’t just carve out one piece at a time from your existing PACS so you will have to start building your own.

2.      It addresses a specific need that nobody else in the market is able to provide – For example, despite the fact that almost every vendor says that they provide a VNA, a true fully functional VNA with full support of the applicable IHE profiles, comprehensive tag morphing and routing as well as DICOMWeb implementation is relatively rare among the “traditional” PACS vendors. Therefore, you might be forced to look around for third party solutions, hence the start of a deconstructed PACS.

3.      It provides a major workflow advantage – A single department consisting of one specialty does not pose a lot of workflow challenges, but if a radiology group supports let’s say more than 10 hospitals each having a PACS from a different vendor, and there is also a extensive teleradiology component, you might be forced to look at solutions that support that type of workflow.

4.      It provides economy of scale – Imagine you are the CIO of a large hospital chain, which could be 15 to more than 100 hospitals. Similarly, you can imagine being in charge of IT for a VISN (Veterans Integrated Service Network) within the department of Veterans Affairs. Having to purchase and support multiple systems leads to duplication, therefore, sharing resources makes good sense from an initial cost, support and maintenance perspective. That is why the VA has some of the best examples of deconstructed PACS implementations using a single image archive/VNA solution for the whole delivery network and uses third party routers, worklist providers, and workstations.

5.      It allows for a “gradual” implementation – If you have a large monolithic system, it is often implemented in a “big-bang” kind of manner, i.e. on Monday morning 8 am everyone goes from the “old” to the “new.” Using a deconstructed PACS, you can phase implementation, which can be advantageous especially if you have a large-scale deployment. You can start by first implementing a modality worklist, making sure all your modalities are connected and working, followed by the archive, then switching the workstations, voice recognition, etc.

Arguments “against” using a deconstructed PACS:

1.      Deploying it is a lot of work – Instead of shopping for one component, you’ll be shopping for a VNA, workstation workflow manager, modality worklist provider, router(s), radiologist workstations, physician workstations, 3-D and other miscellaneous capabilities such as dose reporting, critical result reporting, peer review package, and I probably missed a few more. You’ll have to work with many different vendors for selection, contracting and implementation.

2.      It requires expertise – You need an educated purchasing team, an IT team, integration team, you need dedicated PACS administrator staff for staging, managing the migration, training, and project management. You’ll need experts in DICOM, HL7, and IHE and very likely will need to train your staff in those skills and send them back to take a seminar or training course. Most of this is not needed or needed to a much lesser degree if you purchase everything from a single vendor.

3.      It could be more expensive – I say “could” because it is not quite clear. Note the analogy of building a car from its parts, it costs about 5-6 times as much, which is the reason stolen cars are typically cut up and sold as parts. Big contracts for monolithic systems are often discounted as well, so you could be paying more for these parts. However, you can also do better shopping for some of the components. Note that “best of breed” could include “best breed for the money.”

4.      There is no single vendor contact for support – Service for these relatively complex systems is still a big differentiator, so having a single number to call might be advantageous, as you reduce the amount of finger pointing. However, one could also argue the opposite, as service is rather expensive, you could potentially save a lot of money by managing the level of in-house support. But there is no question that having a single service contact point has its advantages.

5.      It is high risk – You can design the architecture and look at the specs but there is a chance that it might not work as expected. There are safeguards you can put in, if nothing else, you should spend a lot of time testing and verifying it. I have seen good examples of that, one of the major institutions I know of used a six months trial and test phase, but the chance of failure is higher than going down the beaten path.

Most decisions are not black and white or obviously one or the other, it is often a balance, weighing multiple pro’s and con’s. I would argue that if there is not a clear advantage for a deconstructed PACS, you might be better off sitting tight for a few more years until these early installations have matured and any gaps have been filled with additional functionality or middle ware solutions. However, I remember building my own deconstructed sound system, I had a lot of fun and a learned much more than I would have learned by buying it off-the-shelf. So, if you are up to it, I’d say go for it!

Wednesday, April 18, 2018

Why you should attend SIIM


Site of the upcoming SIIM conference:
Gaylord at National Harbor
Hundreds of healthcare imaging and IT professionals gather every year at the annual SIIM meeting,
which is coming up May 31 – June 2 in Washington DC. I have attended these events since they were called “SCAR” and have seen the changes in the medical imaging informatics industry being reflected at these meetings over the many years. I am looking forward to attending this year again and would recommend it for any healthcare imaging and informatics professional for the following top ten reasons:

1.      It’s a great place to network. We are working in somewhat of a niche profession. Many institutions have only a single PACS administrator for radiology, and even though you might have a colleague in cardiology and someone in pathology who is getting his or her feet wet in managing digital images, many of you might feel as if you are on a small island. You don’t have many people to talk with about your problems, issues and good practices. At SIIM you’ll find literally hundreds of people who all are in the same boat, many have the same systems you are using, and face the same challenges with their systems, vendors and users.
2.      You’ll be able to find out “what’s new” from a technology perspective. New applications for capturing dose information from your CT’s, software providing Decision Support, AI support tools, and using VNA as the core enterprise archive are all relatively new technologies you want to learn about, to find out if they make sense for your institution.
3.      You’ll be able to discover “what’s new” from a vendor perspective. Mergers, consolidations, acquisitions, new company names and branding are very common in our industry. If you are using a vendor who is not exhibiting at SIIM you might think about having a plan B i.e. replacement strategy. Sometimes it is just a matter of knowing the new name. Don’t be looking for your ACUO VNA, McKesson or Merge PACS but rather for Hyland, Change Healthcare and IBM.
4.      At SIIM you have a much better opportunity to kick the tires than at other tradeshows. Compared with large trade shows such as RSNA where you must make appointments to get a demo on a tiny monitor with three rows of people in front of you, at SIIM you can walk up to a friendly sales rep and get a one-on-one demo of the latest product features. This is important for new purchases and upgrades.
5.      You can talk with your vendor especially with large companies, and ask about specific problems, whereas it might take a while to get your messages through about certain features, issues, workflow solutions, or alternate solutions the rest of the year, at SIIM your vendors are easily accessible. Note that this works both ways, trade shows are key for vendors to collect data from customers about what features they like and don’t like, and what upgrades they would like to see prioritized in upcoming releases.
6.      Find out from other users about specific issues. Again, as an imaging professional you are somewhat on an island and you might find out that a nagging issue is not unique to your specific installation or use, even though a vendor might say “we don’t see the same problem anywhere else.” There is a strength in numbers, so knowing that your problems are not unique can give you more ammunition to get it fixed
7.      Learn a few new tools and tricks. This is my personal favorite as the learning labs are a great resource to become familiar with, for example using a DICOM sniffer to find out why a device does not want to communicate with the PACS or drops random packets, or is using a validation tool such as DVTK for validating a DICOM header so you’ll know what to fix to enable a physician to view the image. These workshops are highly recommended, and are very popular, so I recommend signing up for these as soon as you can.
8.      Understand what’s hype and what’s real. If you read the social media, radiologists will become obsolete in the next 5 years due to the increase in Artificial Intelligence (AI) applications, we’ll get reimbursed in bitcoins, and if you won’t have a VNA or deconstructed PACS you’ll be left behind by the competition. SIIM is a good meeting to not only hear from experts their opinions, but most importantly from real users, especially the early adopters, what their experiences are. This allows you to decide to jump ship and ride the next wave or wait a few more years until these fads either mature or fade away.
9.      Learn about best practices. Even though most hospitals are somewhat different regarding practices and workflow, there are a lot of best practices that can be shared among these institutions. Quality measures such as ER discrepancies and how to manage these, peer reviews, what is a reasonable number of retakes, and how to minimize these, are good KPI’s to compare against. These can be used to improve efficiency, patient care, safety and cost.
10.   Have fun. My kind of fun is participating in the early morning 5k fun run, have a beer and/or sushi with industry friends and colleagues, and sneak away for a few hours or take an extra day to visit a museum and do some sightseeing. Because of my involvement with the DICOM committee meetings, I have been to DC probably close to 100 times (imagine 6 meetings/yr for at least 15 years…) but there are still parks, museums, neighborhoods to visit or revisit.

When you visit, I suggest arriving prepared and set clear goals and objectives, such as meeting with a minimum of 5 people with the same system, looking for a at least three different replacement solutions, etc. However, have realistic expectations, don’t expect to come back an expert. There is a place for tradeshows such as SIIM, and a (different) place for fundamental, intense hands-on training. 

So don’t expect to become proficient in DICOM or HL7, different PACS architectures, or know the details of using Wireshark or Mirth. Tradeshows are a good place to enhance your training and career but view them as complementary to your other education and training options such as reading textbooks, attending in-depth training classes or seminars.

As a final caution, as you to get back to your own environment over-stimulated, but as you return to your own system with its limited versions, capabilities, budget constraints etc., be prepared for some disillusionment. But at least you can challenge your status-quo and be knowledgeable and share what you’ve learned! And last but not least know that you had fun!

Thursday, March 29, 2018

Critical measures to keep your PACS secure.


A recent article by a McAfee employee stated that more than 1100 PACS systems are currently exposed to the public internet and can be relatively easily accessed to the extent that intruders can retrieve and upload images with few problems. In doing research for his article, he did just that. The fact that certain image files were accessed is troublesome by itself. Even more troubling, medical data was changed. We wonder if someone is paying attention at those sites or if McAfee notified them.

According to HIPAA, if patient data is seen by someone who should not see it, federal law requires doctors, hospitals, and other health care providers to notify those patients of a “breach” of their health information. Patients in turn can file a complaint with the HHS office for Civil Rights (OCR). But, independent from privacy and possibly even ethical questions about this particular experiment, the fact remains that 7% of all PACS systems are completely unprotected.

What does it mean that a system is secure? According to a recent MITA white paper called “Cyber Security for Medical Imaging”:  A device can be considered secure if it defends unintended or unauthorized operation with respect to its intended environment and its intended use—as specified by its manufacturer. Therefore, providing security measures in the device and also infrastructure is a key requirement.

Security for medical devices also got the attention of the FDA. A premarket notification or 510(k) approval for PACS systems has to include a security assessment otherwise it won’t be cleared for use by the FDA. The premarket submission requires several additional documents addressing the security aspects.

Security is not only a PACS issue. At the HIMSS 2018 conference that just wrapped up in Las Vegas, the organization released its annual cybersecurity survey of its 70,000 health IT professionals showing that 75% of the respondents had experienced a recent significant security incident.

Now, back to what you can do to protect your PACS system. Below are the most important measures you can take to guard against internal and external security threats. It consists of three major phases: Identify, Mitigate, and Monitor and Review.
1.   Identify the Threats

·        Inventory your systems – Know your “surface area” for attack. Many times the weak link is an open workstation at a specialist’s office or a modality hidden in an OR that nobody checked. Remember to include your wireless systems as well. The increased connectivity within the enterprise of new specialties, POC ultrasounds and other imaging input and output devices being used by physicians create additional challenges for security.

·        Conduct a security review – Engage an outside auditor to review your systems and conduct penetration testing. Audit your systems’ compliance with the HIPAA Security Rule and PCI standards. PCI applies to payment systems, not healthcare, but they have many relevant and helpful guidelines. Even if you have a strong security team in-house, it helps to have an unbiased “outsider” to review your security plan.

·        Manage your vendor access – Vendors typically access their products as part of their service contracts, which means you could have multiple access points in your PACS. For example, one for the PACS server vendor, several for your modalities, which can be from a couple of different vendors, and you might have third party software for 3-D or other applications, as well as a speech recognition vendor, etc. Make sure that vendor access is limited to their device only and, most importantly, monitor it, i.e. check the audit trails and access logs. You want to know who accessed your devices and when, in case there are issues. It would not be the first time that a vendor made changes corrupting a database, upgrading a software release, installing patches, etc. without notifying the customer.
2. Mitigate the Threats

·        Switch off the promiscuous mode on your devices – Almost every PACS server has a “poor man’s” security mechanism, by which an unknown DICOM application, identified by a DICOM AE-Title that is not in its configuration file, is refused a connection at the Application level aka Association. However, if you have configured your PACS to be “promiscuous,” meaning that it will talk to any AE-Title, it will connect and potentially allow the upload or retrieval of data. The advantage of operating in a promiscuous mode is that every time a new device needs to be connected, you don’t have to change the configuration, however this is very poor practice.

·        Manage access configuration – PACS systems often have some granularity with regard to these privileges, for example, it might allow any device to query its database, but not allow images to be retrieved. If you look at some of the PACS user groups, this is probably one of the top-ten most asked questions: “Why can I not retrieve images from the PACS despite the fact that I can communicate with it.” The answer is that you need to add it to the access configuration file. Manage this access and configuration yourself as a PACS administrator; don’t rely on the vendor to do this for you.

·        Map any connected device to its port and IP address – As part of the access configuration file, most PACS systems will also keep track of who is connecting from what IP address and port number (hence the requirement to have fixed IP addresses using the DICOM protocol). If a device with a known AE-Title suddenly tries to access the server from another IP or to a different port, it should refuse the connection. Again, manage this configuration.

·        Use standard port numbers not port 104! – For security, DICOM applications should run in user mode without root access. Port numbers below 1024 are privileged ports that require root access by the application. The Internet Assigned Numbers Authority (IANA) has assigned a standard “registered” port number of 11112 that should be used rather than the well-known port 104.

·        Secure your perimeter – Use standard IT security best practices to harden your exposure to the outside, such as:

a.     Use a professional firewall – A Stateful Inspection Firewall can analyze packets down to the application layer. The simple packet filtering firewall you find in most routers is not effective against a determined hacker.

b.     Deny-first – Restrict access with a deny-first firewall policy, then whitelist systems and IP addresses that need access.

c.     Use intrusion detection systems (IDS) – An IDS can spot hacking attempts in real-time. An IDS can log and alert you when suspicious actions occur, like the administrative credentials logging into the EHR system at 3:00 a.m.

d.    Use Proxies and Routers – Proxy and router systems from vendors such as DICOM Systems, MedWeb, RamSoft, Osimis, Laurel Bridge and others sit between your PACS and outside systems. These proxies can automate encryption, authentication, anonymization, and more. They provide a security wrapper for DICOM devices to manage the limitations of the DICOM standard. When selecting a proxy system, it’s wise to use a professional vendor. Don’t try to roll-your-own security.

·        Use VPNs for remote access – If you must allow direct access to PACS, use a Virtual Private Network (VPN). These can be complicated to implement and require a knowledgeable IT staff to manage. Don’t be tempted to skip this and trust a password to protect your open ports. Your password will be broken or leaked.

·        Segment your network – Segment your network using Virtual LANs (VLAN) and demilitarized zones (DMZ) where appropriate. Put your public-facing servers in a DMZ. An attacker gaining control of these servers will have limited surface area to attack your internal systems. Use VLANs to segment departments where possible. There is no reason for the shipping computers on the loading dock to have direct IP access to the DICOM network systems.

·        Control access by removable devices – TechAdvisory.org has reported that 25 percent of malware is transferred through USB, therefore, you can eliminate this risk by simply not allowing unauthorized USB drives in secure networks. This protects you by restricting unauthorized data exfiltration and by cutting off a vector for malware intrusion. Disabling the USB ports is easy to do in Windows as an administrator. You can disable USB removable media across the entire domain via Active Directory Group Policy. Remember that this applies to your service providers as well, the last thing you want to have happen is allow a service engineer who just picked up a virus from a “dirty” site to use the same flash drive to infect your network (this happens!)
3. Monitor and Review
·        Check your audit trails – Audit trails for application level access are a HIPAA requirement. If you never look at them, they might as well not be implemented. Regular audits help detect both internal and external access violations of patient data. There are no “standard” guidelines on how often to check the audit trails, but most people we talk with seem to do it once a week, checking random accesses from random people. Support for standard audit trails is important, IHE defines a ATNA profile that provides this information to be recorded in a standard format. Check your IHE integration statement of your PACS system. Further transformation of your audit trails into XES event logs can facilitate process mining.

·        Rinse and Repeat – Go back to step 1. Inventory, audit and conduct reviews. This is a continuous process. You’ll never be finished, but you can be assured that you put the right practices in place.

Will these measures protect your PACS? As many security professionals will tell you, nothing is 100% secure. If someone really wants to get access to your data and/or modify it, there is likely a way. But instead of leaving the front door wide open and put your family jewels on the kitchen table, you can at least have a locked, security system and add another perimeter to secure it, so that potential hackers or intruders will go looking for an easier target.

Herman Oosterwijk is president of OTech and a PACS, DICOM, HL7 trainer/consultant, David Finster consults on security and data protection best practices. We encourage comments.


Tuesday, March 20, 2018

DICOM Experts, Where Art Thou?


This past month alone, I got three inquiries from high tech imaging companies looking for seasoned DICOM professionals; two are wanted on the east coast (Boston), two in rural Arkansas, and if you like skiing and hiking, there is a vacancy in Boulder, Colorado.

One of these positions does not even require US residency, as they are willing to sponsor a work visa for qualified applicants. The reason these inquiries came to me is that there are literally thousands of students who went through the OTech DICOM training over the past 25 years, and therefore, I have a large base of “alumni” among my Facebook and Linked-in friends.

This poses the question, what is an expert anyway? My first source is always the (un)-official source of truth, i.e. Wikipedia:
Historically, an expert was referred to as a sage (Sophos), was a profound thinker distinguished for wisdom and sound judgment. Informally, an expert is someone widely recognized as a reliable source of technique or skill whose faculty for judging or deciding rightly, justly, or wisely is accorded authority and status by peers or the public in a specific well-distinguished domain.
The next question would then be, how to define a DICOM “expert?” To define his or her skills, I like to refer to the official DICOM certification for professionals, which is managed and administered by PARCA. The requirements for this certification include knowing:
1.     Negotiation – How DICOM connections (Associations) are being negotiated and established, i.e. the handshake and agreement on the type of images to be exchanged and encoded such as compression. Note that “images” mean any DICOM file, including dose reports, measurements, presentation states containing overlays etc.
2.     Messages and data elements ­– How DICOM metadata (literally “data about data”), aka DICOM headers that are part of the DICOM file is encoded and can be interpreted.
3.     Storage and Image management – That DICOM protocol services include the capability to query a worklist at a modality, allow for images to be exchanged, get a commitment from an archive about its permanent storage and can communicate study status and changes to the procedure using “Modality Performed Procedure Step.”
4.     Print, Query/Retrieve and compression – There are still a lot of DICOM printers, especially in emerging and developing countries, communicating with the DICOM print protocol, while Query/Retrieve is the interface to a PACS database/archive. Compression specifies what compression schemes are supported and can be negotiated such a JPEG, JPEG2000, MPEG, and others.
5.     DICOM Media – Reliable CD interchange is still a major headache and pain point for many institutions, if only everyone would follow the DICOM standard closely, it would be much easier. One should be familiar with how images are stored on a CD i.e. as so-called “part-10” files and how the DICOMDIR or directory is structured.
6.     Image quality and Structured Reports – DICOM defines a so-called pixel pipeline which specifies all the steps that the pixel data is going through prior to being displayed such as different greyscale/color schemes, annotations, Look-Up Tables, etc. Displaying the images on a monitor that is calibrated using the DICOM defined standard greyscale and color mapping is critical to ensuring that every discreet pixel value is mapped into a distinguishable greyscale or color value. Structured Reports are used for measurements, CAD marks, dose information, key images and other information related to image metrics.
7.     VR’s and conformance – A VR or Value Representation defines the data types, i.e. maximum length and encoding of the DICOM data elements. Knowing where and how to evaluate these allows for spotting errors, the most frequent being exceeding maximum length, invalid codes in the fields, invalid characters, etc. Conformance is critical as it allows checking whether two DICOM devices can communicate using the conformance statements.
8.     Networking – This includes addressing, i.e. use of IP address, port number, and AE-Title, using tools such as DICOM network sniffers as well as interpreting the communication logs and dumps.
9.     Troubleshooting – To troubleshoot DICOM connections, one would use simulators and test tools. The most basic tool is the use of the DICOM Verification, as well as using multiple test images such as those for testing the imaging pipeline and be able to change negotiation parameters
10.  New DICOM extensions – There are several DICOM extensions, such as the specifications “for processing” aka raw data, which typically is used to perform CAD, the definition of the new multi-frame enhanced CT, MR and other image types, using the Universal Worklist and the new pathology image definition. Last but not least, is DICOMWeb, which uses RESTfull services, mostly being used for mobile access and through web browsers and is the counterpart of the HL7 FHIR services.
As you can see, there is quite a bit involved with being a “DICOM expert.” If you feel like honing your skills, you might want to check out available textbooks, training or pursue certification. If you feel you would qualify for one of the “expert positions,” feel free to forward your resume and I’ll be happy to share it with those inquiring about hiring.



Monday, March 12, 2018

HIMSS 2018: Wake-up call for the sleeping giants.

As I browsed through the vendor exhibits among the more than 45,000 healthcare IT professionals gathered in Las Vegas last week for HIMSS 2018, I noticed that the big IT giants Amazon, Google, and Microsoft (Apple was noticeably absent from the exhibit floor), as well as other businesses who are in the CRM space (Salesforce) are finally taking notice of the opportunities in healthcare. It was also not a coincidence that Eric Smidt, past chairman of Alphabet, Google’s parent company, was the keynote speaker for the conference. I believe that this is very promising as healthcare in many ways is very much behind other industries and can learn from their experiences.

As anecdotal evidence of the need for better technology in healthcare, I listened to a presentation from a vascular surgeon who explained how he annotates relevant images on a PACS viewing station, then takes a picture with his iPhone of the screen and shares it using Chat with his residents and surgical team to prep for surgery. The reason for him to have to use his phone, is that we don’t yet have the “connectors” that tie these phones, tablets, and other smart devices with our big, semi-closed healthcare imaging and IT systems. The good news is that Apple just announced an interface allowing information exchange, which can be used, among other things, for patients to access their medical information from a hospital EMR. Also Google cloud announced an open API.
Here are my top observations from HIMSS2018:

Demonstration of new Apple
App accessing health records
·       Patients are taking control of their medical information: Apple announced a FHIR based interface on the iPhone that provides access to personal health records. The interface is built into the recent Apple phone as part of its health app. Information such as recorded allergies, medications, lab results, etc. is copied to the person’s phone. Note that this is different from solutions where this information is stored in the cloud (e.g. Google, etc.).
Regardless, it allows patients to access and keep their own information. It provides a mechanism for patients to share the information, as the hospitals are struggling to meet that demand (only one out of three hospitals can share information according to a recent AHA study, despite the fact that more than 90% of them use electronic health records).
In reverse, it is not that hard to upload this information back into an EMR of a physician or a specialist, together with information collected from blue-tooth enabled blood pressure, pacemaker, insulin pump, and other intelligent healthcare devices as well as wearables. At the IHE interoperability showcase demonstration areas, there were several demonstrations of how this upload can be achieved using standard interface protocols, often using FHIR.

·       FHIR is gaining more traction: The new HL7 protocol allowing easy access, especially by mobile devices, to so-called resources such as lab results, reports, and also patient information is getting more traction. However, there is a still a big disparity between what is shown as “works in progress” such as the demonstrations at the IHE interoperability showcase, and what is actually deployed. Almost every use-case that was demonstrated at the showcase had one or more FHIR elements, such as used for patient information access, uploading images or labs, accessing registries, etc. However, when I asked vendors on the exhibit floor where they deployed the FHIR interface, many of them told me that yes, they have their FHIR interface available but are still waiting for the first customer to actually use it.
There are a couple of exceptions, for example, at the Mayo Clinic they are using FHIR to access diagnostic reports, utilizing the EPIC FHIR interface, but there are still very few. One of the major obstacles with FHIR implementations is that it took them a long time (5 years to-date) to get to a standard that has at least some normative parts in it, which will be release 4 to be balloted soon, which means that any implementation you do right now is subject to changes as upgrades are non-backwards compatible. As an example, the Apple FHIR interface is based on release 2. So, I am officially upgrading my FHIR implementation status from “very limited” to “spotty,” but I believe that there is definitely a lot of potential.

Demonstration of VA to DOD gateway
based on FHIR technology
·       The VA is making major strides in healthcare interoperability: I feel compelled to call out the US department of Veterans Affairs as there is a push to shift some of their care to the private sector, while the fact of the matter is that research shows that the VA scores higher than the industry in many of the quality scores, despite the fact that yes, there is still a lot of disparity between the different VA facilities. The high quality of care is not in the least caused by the early implementation of electronic medical records and the ability to be paperless. But, their current medical record system is becoming out-of-date, hence the intention to replace it with a new EMR at the cost of about $10 billion over the course of the next 10 years. Nevertheless in many ways, their current system still outshines what can be achieved today by commercial vendors.
As a case in point, there is a connection between the VA EMR and the one from the DOD that allows for a smooth transition of veteran data between these two entities, which is based on FHIR. What is significant, is that of the many FHIR resources that FHIR has defined (more than 100 up to now, planning to be at about 150), the VA is able to exchange all of the information needed with only very few FHIR resources, notably Patient, Imaging Study, Questinonnaire, Observation, Clinical Impression, Diagnostic Report, Encounter, Condition, Composition, Allergy and Medications. This means that implementing a relatively limited subset can still be very effective. Hopefully their replacement EMR (Cerner?) will have the same kind of interoperability, which seems to be a point of contention right now in the contract negotiations for replacement.

·       The big EMR companies are doomed (or are they?): This millennium has shown a major shift in healthcare IT as the past ten years the number of hospitals in the US having an electronic record has gone from 10% to more than 90%.
However, these monolithic, semi-closed systems which accumulate all the patient information in big databases that are hard to access with limited tools for dashboarding and quality metrics, and who often charge a hefty fee to provide yet another interface to get information in or out, might be on their way out unless they change their architecture and focus. For what it’s worth, even the White House is taking notice as Jared Kushner mentioned during the meeting that “Trump has a new plan for interoperability.”
Let’s look at an analogy on how other industries solve the information access problem, for example, a website for a hotel. If you would like to find directions to the hotel, you click on a link to Google Maps, if you want to know what the local sightseeing tours are, you click on “tripit”, for reviews you click on “Tripadvisor”, and so on.
Now let’s go back to our ideal EMR user screen, wouldn’t it be nice if you can get the patient information from a “source of truth,” which is a web-accessible source for patient information, the latest lab results from the lab, either internal and/or external, the past 6 months progress on a weight loss program from the patient’s Fitbit located in the cloud, diagnostic reports from the radiology reporting system, and so on. And by the way, arranging transportation for the patient is just another click on the Uber or Lyft App (note the announcement from Allscripts to embed a Lyft interface to their EMR).
The EMR would be a mash-up of multiple resources accessible through standard protocols (FHIR), in some cases guaranteed immutable, using blockchain technology, and the only functionality left would be a temporary cache and workflow engine that guides health care practitioners through their job in a very easy to use manner.
Currently user friendliness, especially, still leaves a lot to be desired, as a recent study showed that during an average patient visit, providers spent 18.6 minutes entering or reviewing EHR data on digital devices, and only 16.5 minutes of face-to-face time with patients. We’ll see what happens over the next 5 years and who will win and who will lose but it appears that FHIR might facilitate a disruptive development.

Standing room seats only for blockchain
presentations
·       Blockchain has some (limited) applications in healthcare. I purposely did not mention blockchain in the title of this write up so as not to overload my ISP as I found it to be the most hyped (according to the dictionary: “extravagant or intensive publicity or promotion”) subject of the conference. Presentations on this subject went beyond standing room only.
What is blockchain? It is an immutable, decentralized public ledger that could be used to securely share transactions without a central authority. Knowing that most of the patient’s health information is not intended to be public, and that some of the files (think a 1.5GB digital pathology slide) are just too big to simply move around and copy multiple times, it makes the application for blockchain very limited in scope. The immutable aspect is also hard to accomplish, even for objects or entities that you might think are immutable such as a patient/person.
Imagine that you would store the patient information in a blockchain (e.g. a url and “fingerprint” or “signature” of the data), can you really guarantee that there would be no changes? Some of the content might need to be updated such as a “disease status” in case someone dies, a different name in case a woman who marries, and it is not uncommon anymore for a patient to change sex.
Apart from the “content,” the structure might change as well, due to database changes such as allowing storage of multiple middle names, aliases, etc. Some of these solutions such as providing a unique, immutable person identification, will be resolved by other industries anyway as financial institutions have a lot of interest in making sure that they provide credit to “real persons” and identify if a financial transaction is requested by the actual person instead of a hacker or intruder.
There are however a few blockchain candidates for healthcare, one example was shown at the recent RSNA show dealing with certification and accreditation of physicians, which should be public and from a reliable source. Another example is dealing with consents, so that a healthcare provider can trust the fact that patient information can be shared with for example a parent or caretaker, and what part of the record can be shared and what not (e.g. limit access to mental illness records or the fact that a 16 year old daughter uses contraceptives). So, in conclusion, yes there are some limited applications for blockchain technology, many of them we can “borrow” from other industries, and some of them we can implement for medical purposes, but in practice it will be few.

Salesforce: Patients are
customers?!
·       Healthcare is learning from CRM companies: According to one of the major CRM companies, Salesforce, Customer Relationship Management (CRM) is a technology for managing all your company’s relationships and interactions with customers and potential customers. Replace the word “customers” with “patients” and you have a perfect system that allows a healthcare institution to manage their patients in a better manner. That is why not only Salesforce but other companies (I saw a demo at Microsoft) are using the CRM core to provide patient management solutions.

·       Artificial Intelligence is making small progress: It would not be right not to mention AI in this report as it is in the top ten tweets about the conference. However, machine learning and Artificial Intelligence is still not as easy as one might think. Some researchers indicate that the IQ of intelligent machines to be equivalent of a 4 your old right now. But, as of now, machines are unbeatable for chess and jeopardy, so there are definitely some applications that can benefit from AI. Examples are predicting ER re-admission rates of certain patients and taking action accordingly, assisting a physician to make a better diagnosis, or, even better, ruling out any findings with an almost 100% accuracy, which would assist in routine screenings. In addition to the technology having to become more mature, there is also an issue with data access as I talked with one user who is in charge of entering manually textual data from old records in structured format, and the fact that much of the accessible data is not very structured. There is a lot of emphasis on AI, so much that some companies are re-branding their whole healthcare business around it (think IBM: Watson Health), which also seems an overkill to me. But AI will silently enter into many applications where it can impact workflow, enhance diagnosis and clinical outcomes.

Yes, I want theVespa
·       HIMSS is still an IT tradeshow: Imagine walking around the RSNA (radiology conference) and being asked if you want to enter in a $200 drawing, participate in a magician performance or, enter a drawing for a motorcycle. It would be unthinkable, but it is still common at the HIMSS. This indicates that it gears towards a different audience than clinicians. In contrast with the last time, however, I did not see any showgirls on the floor this year for photo-ops, so the only decision I had to make was if I would enter the motorcycle or scooter drawing. Having driven a Vespa myself when I was young, it was not a hard choice for me.

In conclusion, this was another great event, with some hype as usual, but I found especially the promise of “outsiders” getting involved in the business of healthcare to be very encouraging. A “fresh look” from these companies using some of the practices that make our life easier when we are not sick, could definitely make our life easier and improve patient care when we are sick. There is no reason that financial transactions can freely move between banks so that I can go to an ATM any place in the world and access my account, while my physician has trouble getting timely lab results, medications, allergies and other pertinent information. I can’t wait for the sleeping giants to not only wake up but get actively involved and make an impact.

Herman Oosterwijk is a healthcare imaging and IT trainer/consultant. In case you like to learn more about new standards, in particular FHIR, check out the upcoming web training and in-depth face-to-face training.