Digital health innovation in a healthcare organization is not easy by any means. Doing research and development when your major concerns are about endless regulations, security and patient safety is a challenge. Bringing cool digital health startups with a totally different culture into a conservative hospital setting is hard as well. But why do you need to innovate in the first place? Isn’t it enough to just implement an EHR from a large respectable vendor?
When implementing an EHR from a large vendor, clients receive all the modules from this vendor, both the good modules as well as the bad ones. Сhoosing such a system is always a compromise as no single system can satisfy all user requirements. Opening a door to innovation on the contrary allows your organization to get what it really needs and wants without a compromise while spending significantly less.
There are great development teams out there. They can deliver what your organization needs in an agile way. They can do more with less. They can solve the problems that bother your organization but do not bother other clients of your EHR vendor. And I am not talking about minor tasks. I know small cross-functional teams under 10 people which successfully developed modern cloud EHR products, physician and patient portals, care coordination systems, and HIEs.
But innovation is still tough, expensive, and considered risky by many. These development teams struggle with getting into hospital doors and are slowed down by the need to integrate their modern applications with a siloed ecosystem of legacy software. Is it possible to make the whole process of digital health innovation easier?
I believe that nowadays there is a way to facilitate digital health innovation in a hospital without compromising on critical aspects of the hospital IT. Open your organization’s doors to innovative technologies but only to those that are compliant with the current industry standards. Do not waste your time on cumbersome custom integrations with fancy applications that are not interoperable out of the box.
First, set up a modern infrastructure for the next generation healthcare solutions. Pick and deploy a platform with a FHIR compliant clinical data repository.
Then, set up production and sandbox areas with production and testing data respectively. Provide sandboxes with test data to companies that see you as a potential client and let them integrate their software with these sandboxes via a standard FHIR API. Have your production environment configured similar to your sandboxes so that you can move the technology you like to production without a hassle.
After that, advertise your sandboxes to many innovation communities and watch out for great ideas.
The hospital will start building an ecosystem of connected healthcare applications. It will save
money on integration of new technologies through standardization. It will increase the number
and widen the selection of technologies that can be brought there. And the last but not the least,
it will make necessary steps to accomplish Meaningful Use stage 3 open API requirements from
What are your concerns? I heard a few so far and will try to address them below. But please share yours.
1. Integration of a FHIR platform with an existing legacy ecosystem is a challenge.
It might be a challenge for some legacy software or specific data but common medical data such as common meaningful use dataset is usually translated to FHIR without significant efforts. Quite a lot of data can be received in real time from HL7 v.2 feeds which exist in every hospital. There are many tools for translating HL7 v.2 to FHIR. Some HL7 engines like iFW Iguana can do it. And even if your HL7 engine doesn’t speak FHIR language yet, you can use HL7 v.2 to FHIR translator from other companies. Health Samurai’s FHIR platform Aidbox * can receive HL7 v.2 and translate it to FHIR.
2. FHIR is not mature and keeps changing. Migration to new versions is time consuming.
Any IT solution that is not dead is constantly changing. This is true for all IT verticals and should be true for healthcare IT as well. Look at all those changes as a positive sign. You are investing in a technology that will not be replaced tomorrow. And regarding the migration, FHIR community recognises the need. Grahame Grieve mentioned at the HIMSS conference in Orlando that he is thinking about offering scripts that will migrate data to newer versions of FHIR. Health Samurai is doing this for their clients as well.
3. How can I make a new infrastructure reliable, scalable and secure? I am not comfortable with the cloud.
First of all, standards of interoperability do not affect your choice of infrastructure. If you want to stick to your old in-house data center, go with it and deploy a FHIR platform of your choice to your old data center. But a cloud can bring the next level of reliability and scalability to you. Aidbox from Health Samurai is usually deployed to several servers located in different geographical zones or even cloud infrastructure providers (IaaS). Data is replicated between these servers and even complete shutdown of a single AWS region will not bring Aidbox down. There are several other infrastructure properties that a cloud Aidbox installation has by default: automated backups, all the data at rest and in transit is encrypted, detailed audit log with GUI and even point in time recovery service that allows to roll back any changes and repair your data after a harmful human error.
One other consideration I want to share with you. Do not wait for EHR vendors and their FHIR marketplaces. Most EHR companies have other priorities than disrupting their own business models via building an ecosystem of connected healthcare applications from 3rd party companies. They’ve been working on the FHIR API for years but still provide API access to a limited subset of data in read-only mode. You can do much better and it will not take that long.
* Health Samurai’s Aidbox.io is a t urnkey clinical data provisioning solution and development
platform for modern web and mobile interoperable healthcare applications.