FHIR Today How Redox Works with FHIR Our Questions About FHIR Things to Keep in Mind The Path Forward...

Transcription

1 ON FHIR Billed as the solution to all of healthcare s interoperability woes, what does FHIR actually mean for healthcare organizations and technology providers?

2 FHIR is clearly a step in the right direction for health information exchange, but is it ready for widespread use in the real world? This white paper investigates how close FHIR is to delivering on its promise of unifying healthcare and outlines how Redox is ready to optimize using FHIR both today and in the future. FHIR Today... 2 Where is FHIR in terms of adoption?... 2 Does Redox support FHIR?... 4 Why does Redox have its own API?... 4 Does Redox make FHIR available today?... 5 How Redox Works with FHIR... 6 It s just another standard. Yes, really What changes for an application when FHIR is available?... 7 What happens to already-live integrations if a health systems adopts FHIR?... 7 Does FHIR eliminate the need for VPNs?... 8 How does the change from HL7 (transactional) to FHIR (REST) impact integration workflows?... 8 Our Questions About FHIR... 9 Things to Keep in Mind The Path Forward

3 FHIR TODAY Where is FHIR in terms of adoption? At the time of this publication, (May 2017) major EHRs have released a number of FHIR resources with athenahealth, Cerner, and Epic leading the charge. Early-adopter healthcare organizations are embracing FHIR, primarily the Patient and Appointment resources. The most recent release, FHIR v3.0.0, is classified as a Standard for Trial Use. This is a major step forward for FHIR and a sign that real adoption is on the horizon, as other well-used standards like C-CDA share this STU classification. HL7 s latest product roadmap lists October 2018 as the date when FHIR v4.0.0 will be released. The goal is for this version to be the first Normative Version, HL7 s classification for a standard that has been rigorously tested in production environments and will not be changed significantly. The entire standard won t be normative, but FHIR v4.0.0 will:...consider balloting the following parts of the specification as normative: Infrastructure (API, data types, XML/JSON formats, conformance layer resources like StructureDefinition and ValueSet) Administration (amongst others Patient, Organization, Practitioner) Some clinical resources may be considered, depending how implementation experience unfolds this year. ¹ What does this mean for adoption, the kind that is tangible and that people can actually use? Well, Micky Tripathi, President and CEO of the Massachusetts ehealth Collaborative and Manager of the Argonaut Project, is quoted discussing the realistic adoption strategy by EHR vendors, saying: Some of [the vendors] may decide to hold off, particularly if release 4 is really just around the corner, however, the Cerners, Epics, and athenahealths of the world are not sitting around waiting for the normative version of FHIR before they implement. Epic and Cerner already have FHIR implementations out there, and they re continuing to build on those. ² 1, retrieved on May 31, 2017, from 2, retrieved on May 31, 2017, from 2

4 David McCallie, MD, Cerner s Senior Vice President of Medical Informatics, has previously said, We re quite excited about FHIR and are actively supporting it both through collaborative work like the Argonaut Project as well as allowing developers to use FHIR to access data in the Cerner EHR. We will continue that and support expansion of the APIs that we can offer using FHIR as the standard. That doesn t mean we ll implement all of FHIR. There are parts of FHIR, even though they may become normative sometime later this year, we might not put them into the EHR for years, in fact, there are parts of FHIR that will never get implemented by any EHR vendor. It s not all equally relevant to us. ³ McCallie goes on to summarize the emerging standard as a giant moving target you can t sort of say the whole thing is ready, although there may be parts of it that are quite stable and mature. The Office of the National Coordinator s 2017 Interoperability Standards Advisory lists FHIR as an emerging standard at a pilot level with low adoption for all of its outlined interoperability needs. The purpose of the Interoperability Standards Advisory is... to provide the industry with a single, public list of the standards and implementation specifications that can best be used to address specific clinical health information interoperability needs. Currently, the ISA is focused on interoperability for sharing information between entities and 4 not on intra-organizational uses. What does that all mean? Put simply, it means FHIR needs further development before it s widely usable for health systems and third-party vendors. While it s come a long way, there are still more questions about its final structure and what elements EHRs will adopt than definitive answers. FOR THE FORESEEABLE FUTURE AND WITH IT SLATED TO BE INTRODUCED INCREMENTALLY THE ABILITY TO SIMULTANEOUSLY ENGAGE WITH FHIR AND LEGACY STANDARDS COULD NOT BE MORE CRITICAL. 3, retrieved on May 31, 2017, from 4, retrieved on May 31, 2017, from reference_edition-final.pdf 3

5 Does Redox support FHIR? Yes, we do. We didn t build Redox solely for mapping HL7v2 to our API we developed it with the understanding we d have CDA documents, vendor-specific APIs, and a variety of other inputs interacting with it. Our architecture ensures conforming to new methods will never be a roadblock and allows us to use a variety of different communication methods and data formats as part of any integration. Today, Redox integrations utilize HL7v2, CDA, XML, X12, and vendor-specific APIs (athenahealth, Allscripts, drchrono, Epic, etc.). FHIR is simply the newest input, and at the end of the day, FHIR is just another API specification in our engine s interface. The way we interact with vendor-specific APIs is very much the same way we will interact with FHIR when it is available for use. We re prepared to utilize FHIR for any integration. Whether or not we actually use it depends on if FHIR (along with the necessary resources) is available and in use at the health system with whom we re integrating. Above all, using FHIR will hinge upon if their IT team believes FHIR to be the best way to execute the project. THE BOTTOM LINE IS THAT REDOX SUPPORTS FHIR. REDOX SUPPORTS ANY HEALTHCARE DATA STANDARD AND EXCHANGE PROTOCOL. THAT S THE WHOLE POINT OF WHAT WE DO. Why does Redox have its own API? When we started building Redox, there was no standard that fit the model we wanted healthcare to adopt there was no JSON nor web-based standard for health information exchange. FHIR was on the radar, but it was still under development and not available for use in live production environments. We weren t willing to wait for a solution, so we built it ourselves. We created the Redox API as a foundation to which disparate systems could normalize. We needed the ability to consume different inputs across various standards, and by controlling the base foundation, we have been able to adapt to any standard or configuration we encounter. If we have a new input that slightly changes the way that structure should look, we can alter our API and make the change available to any entity using Redox. We re able to mature our standard at will and adapt it to our customers evolving needs, all while making the changes available to every node in our network at the same time. 4

6 There is a future where we may map to FHIR instead of using the Redox API, but only time will tell if that actually happens. As it exists today, FHIR fails to address several important and heavily-utilized domains the Referrals, Inventory, and Claims functionality of FHIR, for example, are extremely nascent and unlikely to gain traction. These are all core elements of healthcare integration which Redox supports, and until FHIR is robust enough to meet all the needs of our customers, it doesn t behoove us to completely tie our model to it. Instead, we will leverage all of the good parts and utilize other available methods to accomplish the data sharing requirements of our customers. Does Redox make FHIR available today? We support and utilize FHIR; however, we don t recommend it as the main standard developers should build against. This is because unlike our Redox data models, FHIR currently isn t stable, and beyond that, it s inconsistent across health systems and EHRs. We integrate our customers with partners who have wildly different technical infrastructures; with our standardized data models, we can accommodate that variance and still offer a consistent experience across sites. We wouldn t be able to do that if we relied completely on published FHIR resources. As with all early-stage standards, FHIR s value and usability are currently only hypothetical. While we appreciate all the work that has gone into getting it to this point, championing it as the de facto standard to build against would be short-sighted at this time. Beyond consistency and stability concerns, it doesn t yet cover all of our customers use cases. Until it does, the Redox data model is the only tested standard that ensures consistency across all integrations. As of May 2017, we have already executed several integrations with organizations who have FHIR available. However, no projects are actually leveraging it. The reason? It s never been the preferred, proven, nor easiest method for our health system IT counterparts. Because prioritizing projects can be challenging and health system resources are often stretched thin, our approach to integration intentionally finds the strategy that requires the lightest lift from a health system. While we go into every integration project with a proposed strategy, we engage and listen to health system feedback and tweak things to fit their preferences. SO FAR, HEALTH SYSTEM IT TEAMS HAVE PREFERRED USING SOME MIX OF HL7V2, CDA, AND VENDOR APIS RATHER THAN FHIR. THIS MAY CHANGE WITH TIME, BUT IT CONTINUES TO BE THE CURRENT STATUS QUO. 5

7 HOW REDOX WORKS WITH FHIR It s just another standard. Yes, really. No matter what language or standard is in use, Redox simplifies two huge healthcare integration challenges: connectivity and data standardization. For our healthcare application developers, we expose a consistent API and data transfer is handled via web services. For our healthcare organization customers, we audit their existing technical architecture and leverage what s already in place to expedite projects and simplify long-term maintenance. For instance, if a health system utilizes an HL7v2 interface feed, we ll establish a VPN and set up Redox as an endpoint to the appropriate interfaces. Then, we d build a reusable configuration record that maps that specific entity s HL7 messages to Redox so we can pass them along in our standardized format to a customer s secure webhook. Using this same configuration, we translate messages back into the healthcare organization s HL7 specifications for when they receive data. If an integration requires CDA exchange, we ll configure web services and set up mutual TLS. We take that CDA message and map it to Redox so that we can translate it to our data model for standardized consumption by all integrated parties. If we utilize a vendor-specific API, athenahealth for example, integrating means authenticating and, once again, building a configuration record to translate the custom API to our published data model for consistent use across other vendors. If FHIR is available, the process is the same. This adaptability ensures any node within the Redox network can exchange necessary data in the format they prefer. AN IMPORTANT THING TO KEEP IN MIND IS MOST INTEGRATIONS USE SOME COMBINATION OF STANDARDS. RARELY IS THERE A SOLUTION THAT IS ONE-SIZE-FITS-ALL, AND BEING ABLE TO LEVERAGE ALL AVAILABLE STANDARDS IN A SCALABLE AND REUSABLE WAY IS CRITICAL TO SERVING A WIDE RANGE OF INTEGRATION NEEDS. THIS IS WHY REDOX EXISTS. 6

8 What changes for an application when FHIR is available? When FHIR becomes more widely used, we don t envision it impacting our application partners much at all. We re in the business of normalizing and abstracting away all the variation and complexity from an app developer FHIR included. We constructed our model so application developers don t have to care about nor notice the difference between HL7v2 and FHIR. If an app receives scheduling information from one organization that uses HLv2 and another that uses FHIR, they will still receive the exact same Redox Scheduling data model. Essentially, whatever language we tap into at the health system to access the scheduling information will always be irrelevant to the application. One aspect of FHIR that may lead to workflow variations is the ability to issue GET requests. It s possible that we would make workflow changes to update an existing integration to take advantage of this previously unavailable functionality. In the grand scheme of things, these modifications will be minor, and, thanks to our model, built once and reused across any additional site that utilizes FHIR. An additional question will be what quantity of requests a health system will support. EHR vendors are taking different approaches to rolling out and monetizing FHIR some will charge integrated applications on a per-call basis. If it's a choice between using FHIR and some new EHR business model versus v2, it might make sense to stay with v2 if the EHR is charging more for FHIR. THE FLEXIBILITY WE HAVE GIVES THE HEALTH SYSTEM OPTIONS; OUR MODEL ALLOWS US TO ACCOMMODATE ALL CONNECTION MODELS AND EXECUTE THE MOST EFFICIENT AND EFFECTIVE INTEGRATION STRATEGY. What happens to already-live integrations if the health system adopts FHIR? Immediately, likely nothing. The full transition to FHIR might take upwards of a decade a lot of health systems would like to retire v2 interfaces, but realistically, these interfaces will live for a very long time, and because of this, modifying the integration wouldn t be necessary. 7

9 If the health system is retiring the v2 interface, Redox will execute a maintenance project to map and configure the integration to the new specifications while working to ensure the user experience remains consistent and the integration continues running smoothly. The key thing to keep in mind is Redox will always do the heavy lifting. Our team will do the technical discovery, develop the project plan clearly outlining responsibilities, ensure the execution of tasks across teams, initiate testing, and clearly outline the cutover process. This is a key component of our managed services approach to integration. There is a lot of uncertainty around FHIR and healthcare s ever-changing technical infrastructure. Our singular goal is to enable the free flow of healthcare data between authorized parties utilizing the best practices available. It s a big task, and that s why our partners lean on us instead of trying to go it alone. Does FHIR eliminate the need for VPNs? The short answer is yes. The slightly longer answer is that while FHIR uses a secure method of communication, many health systems still opt to use a dedicated VPN tunnel for connectivity. We see this today with CDA integrations still going through a VPN even though encrypted communication is inherent (when done correctly) in CDA exchange standards. How does the change from HL7 (transactional) to FHIR (REST) impact integration workflows? The major change lies in the ability to issue GET requests versus subscribing to real-time notifications of events. This will provide additional flexibility to designing integration workflows and allow for more request-based data transfer. With that in mind, integration workflows won t have to change very much. FHIR is a RESTful web service communication method. Right now, Allscripts, drchrono, and athenahealth each has their own, and Epic is offering more web service functionality every year. The fact that we can deliver a consistent developer experience while working with an athenahealth web service for scheduling while simultaneously leveraging an HL7v2 SIU feed has prepared us for integrations with FHIR. Standardizing all experiences with HL7, CDA, and vendor-specific APIs has laid the groundwork for maintaining seamless integrations with FHIR. 8

10 OUR QUESTIONS ABOUT FHIR What is the motivation to transition from already-built interfaces? It s not uncommon to find a health system that has over 500 v2 interface interfaces live and humming along, as they support integrations with critical systems (LIS, RIS, etc.) that can t be disrupted. Unless there is a significant problem, these connections are supported and maintained, but never changed. The work involved and the potential for something to go wrong puts transitioning away from these tried and true integrations low on the priority list. As a standard just now being tested at scale in production environments, there are outstanding maintenance and support questions around FHIR. Until IT staff are confident enough to implement the new standard into core functionalities (like in LIS, RIS, and EHR integrations), widespread adoption will take some time the process is too risky to rush, meaning it will happen slowly (and only after FHIR has proven itself across many verticals and use cases). To summarize: there aren t clear incentives to retire operable interfaces at this time, and transitions are likely to happen very slowly. Will vendors put a limit on the number of FHIR requests? How will vendors charge? One thing is certain there will be some limit, and there will be some fee. Right now, specifics are fuzzy at best, as EHR vendors are still experimenting with business models and will adjust them multiple times before settling on something consistent. For now, we have to wait and see. Will FHIR extensions actually solve all of the problems zsegments created? There s a saying in the healthcare integration world: If you ve seen one HL7 v2 implementation, you ve seen one HL7 v2 implementation. The culprit for this unfortunate reality? A little thing called zsegments. These message segments were defined locally, allowing implementers to add additional information as needed. This worked great on a one-to-one level but caused wild variation across sites, making data sharing much more challenging. This wasn t because implementers didn t follow the spec, but because they took it and tried to fit it on top of their existing systems. We re skeptical that FHIR is going to be very different you have the spec, but the underlying variance of legacy EHR vendors will persist. FHIR has learned from HL7v2, though, and the mechanism to add this flexibility through extensions instead of zsegments is more structured; however, when the rubber hits the road, and implementers are doing whatever they have to in order to finish a job, it isn t yet proven that extensions will be all that different. The way we see it, there is a right way and a wrong way to go about using extensions. The right way is by considering them solely as part of the process of core FHIR standards evolution. This means using them as sparingly as possible and considering them as part of the FHIR standard itself. It also means letting them die off in cases where they aren't catching on and adopting other organizations' extensions as they become popular so that they may eventually become a core piece of FHIR. 9

11 If the community as a whole abuses extensions and health systems insist on maintaining extensions with low adoption rates, it will hurt the overall effort to achieve greater levels of healthcare interoperability. However, proper use of extensions may hasten an ecosystem where healthcare data is universally free-flowing via applicationlevel standards that are as ubiquitous and robust as TCP and https are today. An interesting perspective on this topic comes from Stan Huff, MD, co-chair of HL7 s Clinical Information Modeling Initiative (CIMI) and Chief Medical Informatics Officer at Intermountain Healthcare: Even when FHIR is a normative standard, it will not be truly interoperable. A note of caution there s still a lot of work to do. Huff warns that what s needed is the standard use of terminology and codes to ensure that these systems are truly semantically 5 interoperable. All of which goes to say, FHIR is an exciting step in the right direction, but it is not going to be the holy grail answer to all of healthcare s interoperability woes. There will very likely still be site-by-site variance that will always need to be addressed. 5, retrieved on May 31, 2017, from datamanagement.com/news/timeline-is-uncertain-for -release-of-normative-version-of-fhir THINGS TO KEEP IN MIND EHR updates always take a lot of time and resources Even if an EHR update is free, implementing the change is usually a six-month project and can happen years after the update is made available. This is because health system IT teams need to review all the changes and updates to clinical workflows and test the configurations before switching over to the new standard. In other cases, EHR vendors create a barrier for adoption by charging for the upgrade. So what does this mean for FHIR adoption? It will be slower than most people anticipate. There will be press releases about EHRs making FHIR available in a new update and everyone will be very excited, but when it comes to making it available at the organization level where it is meaningful to IT teams, there will still be a year or longer to wait. The standard is still evolving Maturity levels of FHIR resources vary drastically. How long it will be until they are Normative is a moving target and impossible to guess. What we do know is that everything is assigned a maturity level, known as FMM. The FMM level is used to judge how advanced, and therefore how stable, an artifact is. FMM levels are very specific, and for a quick breakdown of what each level means, check out Table 1 on the following page. 10

12 LEVEL 0 1 STATUS AND DEFINITION The resource or profile (artifact) has been published on the current build. This level is synonymous with Draft. PLUS the artifact produces no warnings during the build process and the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation. 2 3 PLUS the artifact has been tested and successfully exchanged between at least three independently developed systems leveraging at least 80% of the core data elements using semi-realistic data and scenarios based on at least one of the declared scopes of the resource (e.g. at a connectathon). These interoperability results must have been reported to and accepted by the FHIR Management Group (FMG). PLUS the artifact has been verified by the work group as meeting the Trial Use Quality Guidelines and has been subject to a round of formal balloting; has at least 10 implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change. 4 PLUS the artifact has been tested across its scope (see below), published in a formal publication (e.g. a FHIR Release), and implemented in multiple prototype projects. As well, the responsible work group agrees the resource is sufficiently stable to require implementer consultation for subsequent non-backward compatible changes. 5 PLUS the artifact has been published in two formal publication release cycles at FMM1+ (i.e. Trial Use level) and has been implemented in at least 5 independent production systems in more than one country. 6 "Normative": the artifact is now considered stable. Table 1. Retrieved on May 30, 2017, from At the time of this publication, the majority of Resources had an FMM level of 2 or lower, meaning that while FHIR is headed down the right track, there s great deal of work left to be done before it consistently delivers on its many promises. 11

13 THE PATH FORWARD Value Flexibility If there s one key takeway from this document, it s that FHIR will improve aspects of healthcare information exchange, but it will not (nor was it designed to) solve all of the evolving needs within the medical community. The wants of developers and the needs of patients and providers will continue to evolve at a rate that requires the ability to mix and match methods of accomplishing end goals. Likewise, the rate of innovation will always outpace the ability of a standards organization to define, test, and release the means to support desired workflows. Meg Marshall, Senior Director of Health Policy at Cerner Corporation put it best when she said, There isn t one simple solution for interoperability and integration.there isn t a single button that says, if you implement this, everyone is going to have exactly what they need at all times. 6 The only way to accommodate for all these variables and to take advantage of new developments as they occur is to invest in architecture that is capable of utilizing a variety of standards and protocols both now and in the future. 6, retrieved on May 31, 2017, from TAKE ACTION If you re responsible for the technical infrastructure of your healthcare organization, the time is now to get your house in order to take advantage of FHIR. We ve partnered with industry-leading health systems like Intermountain Healthcare to help maximize this new hybrid landscape, and we can help support your initiatives, too. Niko Skievaski, Co-founder & President (480) niko@redoxengine.com Contact us today to learn about how we can help you integrate and benefit from the coming wave of change. If you re selling into healthcare organizations and need to seamlessly share data with all of your customers regardless of available standards, we re here to help. We enable innovative healthcare companies to bring game-changing solutions to market by handling all the technical connectivity and data transfer required to maximize their product s value. Tim Kessler, Business Development (608) tim@redoxengine.com Get in touch to learn how we can help you grow faster and stay focused on what you do best.