3 things to do now.
Whether you were able to stay through the entire FHIR interoperability considerations and impact on digital health integrations with Nick McKenzie or are planning on listening in via the replay—the takeaway was clear. FHIR has finally moved from an academic exercise to a real-world tool for use by healthcare developers. It is being adopted by healthcare organizations and EHR vendors. Payers are getting involved. Cloud vendors have jumped in. Momentum is now being built. To quote Nick, “If you don’t get on board now you might get run over a little later.”
With big organizations coalescing their health data backbone on the FHIR standard—it is time to closely analyze your infrastructure. Are you positioned to thrive moving forward? Or are you locked into the status quo?
Although the conversation with Nick went wide and deep, there were three key takeaways anyone building a healthcare product should consider when making infrastructure decisions. Whatever decision you make, you should be establishing an environment where you are able to:
- Bring immediate value to your customers.
- Instill market-leading value for your customers.
- Make your healthcare security, policy, and compliance partners comfortable.
ONE: Bring immediate value to your customers.
The best products demonstrate their value and encourage quick adoption with near immediate value delivery. Whether it is Canva making it easy to remove the background of an image or a 4WD truck easily driving across ice and snow– there is a clear “aha moment” when the user is sold on the value provided.
If leveraged properly, healthcare product builders can take advantage of FHIR to deliver immediate and sometimes novel value to customers. Here are a few examples Nick called out for consideration.
- Synchronous retrieval of data can deliver immediate value within your applications. Currently, there is good coverage, definition, and normative content around clinical concepts. Look to build some quick wins using this functionality.
- Want to differentiate the value your product provides? Think about pivoting to some niches or difficult things. Leverage implementation guides for complicated areas like oncology, genomics, precision medicine, and other very heavily structure-oriented, healthcare data concepts. Consider some of the harder problems that maybe haven’t been easily solved in previous standards. Can you deliver value where others have failed?
Focus on specific trigger moments where “something” happens, and the clinician needs to be notified “right then”. Because until recently, there has not been a subscription pub/sub style framework to trigger these actions—and then go enable a query. FHIR makes this more advanced workflow possible.
The key to building a successful healthcare product is providing value to the clinical teams, patients, or administrative staff using your product. Go beyond the basics and identify differentiating moments you can deliver using FHIR.
TWO: Instill market-leading value for your customers.
Nick referred to FHIR as a four-headed monster. Why? Because Nick sees four possible ways that digital health builders can harness the potential of FHIR, in a truly differentiated, market leadership fashion.
1.) Understand where FHIR can add value at a particular point in time. When does the clinician need to know something? Create an API operation to find this something out! Or, conversely, at this exact point in time, I need to put this piece of data back into the workflow. And with FHIR you can do this directly.
2.) Think of more of an API instance and operations kind of flow. Leverage the support of subscriptions within the R4B release of the FHIR standard. The synchronous flow that digital health builders used from V2 to say, “Hey, somebody was admitted;” or “Hey, an appointment was booked, or so on and so forth.” This can really inform and help clinical teams improve the continuum of care for patients.
3.) Take those FHIR-oriented events and then hand them off and do other things based on the triggering event. For example, take capabilities around HL7v2 messages and turn them into FHIR-oriented payloads and deliver them to your customer base.
4.) Don’t ignore existing formats. There are a ton of examples across different parts of the industry where digital health builders can leverage X12, and CDAs to do really powerful things. The current issue is that these formats are really dense. You may only want one part of the CDA. But if the entire CDA is sent, now you have to find out what to do with all the rest of it and store it. The ability to have a translation layer to take some of these existing standards—that served us well based on the capabilities of the technology at the time—but now take them and make them more componentized and enable them to get into a more “liquid fashion”. This enables digital health builders to move the data at exactly the point in time that is needed to move it.
THREE: Make your healthcare security, policy, and compliance partners comfortable.
A lot of the FHIR APIs that are supported by the major EHR vendors are set up so that the APIs will honor that user security—and what you have access to as a person. But if you use a system persona, you have access to whatever they’ve given the system user access to—which is pretty much everything. So put on a General Data Protection Regulation (GDPR) perspective lens. What are the auditing considerations? Understand the risks. “If you can propagate the patient identity in the slimmest fashion possible for your use case, do it. Don’t resort to the system access or the broad backend access key for all your requests; unless, there’s no other option to achieve your outcome. Because you’re just increasing your risk profile and potentially will own auditing and storage and persistence that you’re gonna have to do for your customers on your side.”
Words of wisdom from Nick, “…with great power comes great responsibility.” Know when system user access is necessary to the value it creates and the risk profile you create with the health system.
What to do next?
Not up on all the latest FHIR developments? Which version to leverage? Or if your health system will accept an FHIR action? You are not alone.
First step. Find out what your customers need. What is the most valuable thing for you to build? Once done, there is good news. Redox is continuously evolving our FHIR conformant API to make it easy for builders to deliver real value to end users. We are doing so in a way where builders can confidently make infrastructure decisions based on FHIR without worrying that it won’t be practical for use in the real world. With Redox you don’t have to compromise your future capabilities for today. You can build your ideal infrastructure and we ensure that it is still compatible with customers and partners that haven’t quite fully adopted FHIR.
To learn more about how Redox can help you architect your digital health product, send us a message. Our team of healthcare data experts are here to help you realize your vision!
Unanswered question(s) and resource share.
Q: “Do you think hospital ITs are trained enough to manage the FHIR integrations?”
A: We understand that FHIR integrations are being widely adopted and are the industry standard for innovation in healthcare. Hospitals who want to remain on the forefront, need to invest in their IT organization, if they have not done so already. Luckily, FHIR standards use a developer friendly framework and have clear benefits for any hospital. Because of this, we are confident that with a small push, most organizations can meet the challenge.
In response to the conversation around the 21st Cures Act—and the expansion of the U.S. CDI— here is a link to submit recommendations on elements and classes for consideration until September 30, 2022. ONC plans on releasing Draft USCDI v4 in January 2023. Per Jessica Bonham-Werling, “A way to participate in the community and driving it forward. So check that out!”