Health IT, MedCity Influencers

Help! My Vendor is on FHIR: What CMIOs need to know about FHIR-based applications

What do Chief Medical Information Officers need to know about the role that FHIR can play in streamlining successful third party EMR deployments? Learn from this article that provide project management tips that simplify integrations and a list of all the key resources necessary for a successful roll-out.

Choosing the right technology partners is critical to the success of any organization, but it can be challenging to get all stakeholders to agree on a common solution. With the expanding role of technology in healthcare, the job of Chief Medical Information Officers (CMIOs) has expanded to keep pace with the rate of innovation.

Given the recent advances in Fast Healthcare Interoperable Resources (FHIR) technology, and major technology companies like Amazon, Google, and Microsoft participating in interoperability initiatives like Blue Button 2.0, it can be challenging to keep up to date on integration and EHR optimization models. As part of this shift, it’s important for CMIOs to be equipped with the right information so they can help their organization make better strategic technology decisions. This article will describe the role that FHIR can play in streamlining successful third party EMR deployments, present project management tips that simplify integrations and provide a list of all the key resources necessary for a successful roll-out.

Does your legacy system support FHIR?
After making the decision to move forward with a FHIR-enabled third party solution, the first step should be to ensure that your facility’s EMR implementation is equipped with the FHIR APIs. EMR vendors will have a slightly different mechanism for fitting their customers’ implementation with the FHIR API.

For instance, Cerner has their “Ignite” package that allows for the scalable deployment of validated partners in the Cerner open developer experience (code) program. Although the FHIR APIs are not automatically included in this package, Cerner will perform the installation quickly upon request to make sure your EMR setup meets meaningful use 3 (MU3) requirements. On the other hand, Epic versions 2015 and beyond have already been retrofitted with FHIR APIs. If your facility uses Epic’s EMR, there is minimal setup required to enable solutions available through Epic’s open program, the App Orchard.

Next, interrogate whether FHIR can fulfill all or only a portion of your integration requirements. In most cases, FHIR functionality is only partially implemented at the EMR level, with the majority of it focusing on read capabilities i.e. the ability for third parties to read in data from the EMR’s data centers.  It is often necessary to consider using HL7 resources or a partner like Redox, who’s well versed in both FHIR and HL7, to fill any gaps caused by missing FHIR functionality. Given that resourcing and communication between parties involved in the deployment are the rate limiting factors behind integrations, it’s important to solidify requirements with clinicians up-front and ensure minimal deviation moving forward.

There is one last oft-forgotten step required to bring a third party FHIR integration live, and that is provisioning access to the third party application’s URL within the EMR. As the FHIR framework is based heavily on Javascript, the “engine” responsible for executing this code will come in the form of a domain name alias. It is important to go through the steps of whitelisting this URL in both PROD and non-PROD environments. As whitelisting may require involving internal (or in some cases, external) IT groups that are otherwise not involved in the development effort it is essential to perform this whitelisting early on in the deployment.

Once the URL whitelisting/provisioning is complete, the FHIR components of the third party solution should be ready for use.

Orchestrating a smooth integration
In the process of introducing a third party solution to your health system, having an airtight management process from Kick-Off to Go Live is essential to the project’s success. As a health IT integration project most often requires three distinct development groups — the health system’s IT department, resources from the EMR and the vendor — it is important to ensure that all parties are aligned during the development process. The easiest way to ensure alignment is to establish weekly project calls with important members from each of the groups involved in the software development. During these weekly calls, the groups can discuss progress and action items on key areas.

Typically, these meetings and general resource gathering are run by an IT project manager (PM) on the hospital side. However, if your facility does not currently have the resources to source a dedicated IT PM, the third party or EMR should have the ability and be more than willing to drive the project on the PM side of things. One caveat to using an external PM to run the project is that you will have to be available to provide the necessary internal resources as needed.

Additionally, maintaining a non-PROD environment that resembles the prod environment is necessary for a smooth deployment. While this applies to any type of software development, it is especially important due to FHIR’s novelty. It is more than likely that, for the foreseeable future, your EMR’s implementation of FHIR will have kinks. It is essential to discover these kinks in the non-PROD environment well before the Go Live so the EMR can move the necessary fixes into their own production environment. Through this testing process, it is also necessary to ensure that clinicians, especially the key stakeholders, get a chance to play with the software themselves so that there are no surprises after going live.

The importance of delivering ongoing support
You’ve made it to Go Live and hopefully it was a smashing success. More than likely, the Go Live involved only a subset of your system’s target user base. Luckily, because FHIR is web-based, scaling across the organization is much more straightforward than it was when integrations were based solely on HL7.

Assuming that the upfront project planning was done well, and that new clinical users across the facility don’t come up with new software requirements, FHIR makes it such that the only tangible consideration for scaling is training and supporting new users.

Depending on the size of the third party software vendor, they may conduct hands-on training throughout the scaling process or utilize a “train the trainers” approach. Regardless, it is best to keep your system’s education department involved throughout the Go Live process as they will be the ones responsible for developing and implementing the training plan. Metrics such as training time per trainer and training time per end user should be established sooner rather than later. Web-based training is another very valuable tool that can be used, and the vendor may have a well-established process around this.

Supporting end users boils down to integrating your internal support (i.e. the “HelpDesk”) with the vendor’s support infrastructure. During the early days of the deployment, end users may opt to contact the third party’s support immediately. This process typically does not scale, however, and eventually the best move is to treat the internal help desk as tier I support. Problems that cannot be solved readily by the help desk can be escalated to the vendor’s support, which will serve as tier II and beyond. In this scenario, it is essential to make sure that the internal help desk is very well-versed on the ins and outs of the new software.

It is the vendor’s responsibility to provide strong, detailed documentation to aid your health system in both the training and support efforts beyond Go Live. With this documentation in hand, combined with a solid FHIR implementation, scaling the solution will be straightforward.

FHIR reduces and promises to eliminate custom development as it relates to deploying and scaling software across a health system. Some of the largest tech companies are realizing FHIR’s potential and are making more aggressive moves in the health IT arena. Government organizations are also starting to adapt to the potential for change that FHIR may evoke.

The VA has created an Office of EHR Modernization to prepare for its upcoming EHR upgrade. Furthermore the Centers for Medicare and Medicaid Services, which has motivated the wide-scale implementation of FHIR APIs by establishing MU3 in 2014, appears to be leading the charge in this area with its Blue Button 2.0 initiative. As these large, well-funded organizations start using FHIR more and more, the software is going to trend towards higher and higher standardization. It is thus important to ensure your health system’s FHIR-related IT practices stay ahead of that standardization curve.

 


Avatar photo
Avatar photo

Joshua Budman

Joshua Budman is a Baltimore-based technologist specializing in imaging and the development of integrated healthcare applications. He holds a B.S. in biomedical engineering from Johns Hopkins University and conducted graduate work in biomedical engineering at the Johns Hopkins the Center for Bioengineering Innovation and Design. Since 2014, Josh has been the CTO of the digital health startup, Tissue Analytics, where he has helped integrate his company's product with many of the major electronic medical record systems.

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers. Click here to find out how.

Shares0
Shares0