BookZurman is proud to share a recent post featuring the insights from guest author, Thomas Beale.
BookZurman is proud to share a recent post featuring the insights from guest author, Ioana Singureanu, BZ's Chief Innovation Officer.
Fast Healthcare Interoperability Resources (FHIR®) have a lot of promise, however, to be successful with collective adoption, we must remember to apply useful lessons of 30 years of HL7-based interoperability.
Ioana Singureanu
It's important that we learn from decades of experiences: the good, the bad, and the non-conformant that have led to implementation divergence, data of limited reusability, and clinician frustration. Patients want seamless healthcare and that requires providers with fewer interoperability problems. The stakes are high and failure at the scale of our industry is simply not an option.
Lesson One: Have Patience for Maturity
While other standards have had a chance to evolve and mature before adoption, Health Level 7 (HL7®) FHIR is still a very young standards framework with many projects around the globe working to test and mature portions of the framework.
To achieve the community goals of interoperable, robust information exchanges, we have a lot of needs:
- Consensus among stakeholders, organizations, and communities of interest.
- Very carefully considered content and standardized terminology.
- Coordination between public and private sector organizations.
- Rigorous testing and certification.
- Information exchanges that align with the purpose and granularity of the business objective being supported with exchange.
The point of unleashing information is to analyze it and implement better treatment options, adopt precision medicine to evaluate outcomes at the individual and population level, and to empower patients to have a stake in their own well-being with preventive care and lifestyle changes.
At this point in FHIR’s maturity lifecycle, no one has attempted to aggregate and apply information collected from FHIR APIs across vendors and providers beyond a type of healthcare information browser. It can be frightening not to have this in place yet, but we will not be able to get to that future without taking the necessary steps to make it possible.
We have to be prepared for the amazing amount of work and discipline it will take to move from raw data to the careful exchange of high-quality information.
Lesson Two: Understand the Relationship Between Flexibility and Community Consensus
Another thing to keep in mind is that interoperability requires an entirely different set of concerns from application development. These requirements create a tension between strict enforcement of a standard versus the flexibility necessary to create applications that are responsive to the needs of users. FHIR has yet to deliver a truly smart application that can consume and create useful clinical, form, and device information.
We don’t have the evidence that existing monolithic systems can be enhanced by using standards-based, SMART (Substitutable Medical Applications, Reusable Technologies) applications (i.e., SMART on FHIR, FHIRcast, and CDS Hooks) or will be an effective mechanism. The applications we have seen are relatively trivial and use read-only data from EHRs (electronic health records). From a business standpoint, we have yet to look at those apps as third-parties to EHRs, and don’t have the data to show effectiveness.
Interoperability requires a great deal of consensus-based, testable, well-defined criteria, creating implementable specifications that will be adopted the same way across the industry. This rigor requires great focus and discipline. The standards development organizations are meant to provide a process that ensures fairness, balancing the interest of all the stakeholders, and openness—but the process itself is not meant for speed, it is meant for consensus. Any attempt to circumvent the process will lead to underdeveloped specifications that allow ambiguity over precision.
With interoperability, the community strives to reach consensus around the task at hand. That ownership and buy-in are the heart of interoperability. In contrast, when using a standards-based application programming interface (API), we need flexibility. We can’t always follow the consensus-based process when our goal is to “move fast and make things.” We need to be able to add new data elements as we discover them. We need to be able to create a flexible graph of related resources at the speed of the business for interoperability.
Lesson Three: Educate on Cost Over Time Vs. Speed Now
FHIR is an excellent option for standards-based data services, creating new standard methods of extracting and mapping data from existing systems, and wrapping existing legacy systems in standards-based interfaces.
So, what’s the greatest obstacle to adopting FHIR-based APIs?
It isn’t the installed base of HL7 Version 2 messaging, X12 transactions (i.e., American National Standards Institute Accredited Standards Committee electronic data interchange standard).
It isn’t National Council for Prescription Drug Programs (NCPDP) transactions.
Nor is it Clinical Document Architecture (CDA) document management information exchanges.
FHIR is not competing with legacy interoperability solutions that deliver solutions to organizations and end users. FHIR is competing with the lightning speed the industry can create an entire custom RESTful API. It is competing with the ease that application developers can create new RESTful APIs ad-hoc – without the use of standards, overhead of implementation guide documentation, and concern for standards-based terminology and other content-related concerns.
While it’s true that FHIR is a more challenging option than creating ad hoc RESTful APIs (because interoperability is seldom a concern when someone is creating a RESTful API for a specific purpose). In the long run, maintaining and scaling up non-standard APIs becomes expensive. This leads to too much variability across the enterprise and, over time, the cost of maintenance and upgrade becomes prohibitive.
Lesson Four: Conformance is a Must for FHIR Interoperability
In general, conformance is the process of testing to see how well something meets a specified standard. It sounds trivial, but it isn’t. Nor is it a given that conformance happens naturally to implementations of standards.
FHIR shed a lot of its lessons learned and decided to go with a slender approach to conformance. We need to rediscover those lessons and adapt them for API testing valuation. The objective is for interoperability to share high-quality information that is understood in the same way by all systems and is acted on safely by all systems and their users. We’re not doing anything different with FHIR, so shouldn’t the same best practices that worked then work now? Because of its dual purpose as enabling application development and interoperability specification, FHIR conformance, by design, was optimized for application development—leaving interoperability somewhat ambiguous.
By now, the benefits of the standards for health information exchange are very clear and a methodology is already in use. The first exemplars were consumers and producers of information as the same entities – so they did not have to explain their terminology to an external body. However, the message that FHIR is not defined has not resonated among colleagues in the trenches.
We have defined profiles, implementation guides, testing criteria, test cases, and we base testing on well-defined requirements. While there is an old interoperability mantra for testing/validation to, “test, test, test,” like other disciplines, we should only have to test to meet planned requirements. That's all, no more, no less.
If we follow the processes of software development, we will identify the corner cases that cause the majority of the problems to develop robust, reliable, and predictable interoperability solutions – instead of getting stuck on the treadmill of testing and retesting the same solution based on incomplete requirements.
So, How Do We Get There?
Solution One: Adopt a Mutual Approach
We need to develop a nuanced understanding of the standard if we are going to “do” FHIR correctly and be part of its eventual success. We all must be part of the solution to ensure that FHIR implementation guides and profiles are fit-for-purpose and implemented correctly by vendors, providers, and payers.
We also need to pledge to ensure that any implementation guidance mandated by regulatory requirements is complete and clear so that it does lead to an interoperability infrastructure for the 21st century, rather than divergence.
Solution Two: Create Clarity and Consistency
We need straightforward guidance that can go a long way to reduce the complexity of adopting FHIR. We need clear, predictable, and scalable conformance to ensure successful production-level implementation of interoperable FHIR resources rather than siloed solutions.
Solution Three: Learn from History
By learning from our field’s 30 years of successes and failures, we can do better with FHIR than HL7 Version 2. We can’t wait to standardize FHIR conformance. We need:
- A clear set of conformance verbs that cannot be redefined by each implementation guide. For interoperability, it’s necessary to have common universally understood conformance verbs, including indicators of missing data. Those concepts were fixed for other standards, but FHIR chose to break that tradition and allow each implementation to redefine conformance to a higher or lower level of precision.
- Profiles that are truly reusable and completely implementable, and we need to distinguish them based on their applicability and potential use. Some profiles are meant to be used as is and adopted in the same way by all implementers, other profiles lend themselves to further refinement and added precision. It’s important to distinguish between these two types of profiles and arm adopters with the methodology to use them correctly.
- Terminology extensibility that moves at the speed of medicine. The COVID-19 pandemic is a great example of standardized terminology that emerged very quickly to support public health, treatment, and immunizations. But a pandemic is not the only time when medical breakthroughs happen; this velocity will hopefully be a routine process. Our standards must be able to adopt that terminology as needed.
Balancing Lofty Goals with Reality
If we can put decades of lessons into practice, we will be able to ensure that conformance happens where FHIR is concerned. Conformance is the necessary step toward quality.
We need robust conformance to get consistency before we can accurately and meaningfully interpret the data elements. Colleagues in the trenches are starting to feel the trickle-down effects from too many ways of doing the same thing and remain conformant with the standard. Someone could claim conformance yet not be interoperable. Once we tackle this issue, quality will be the next challenge.
With these ideal goals in mind, we must remember the reality of what is reasonable and remember that we’re all in this together. Truthfully, failure IS an option. APIs will happen. But success will come in increments. First, it will be letting information flow and making it available. Then comes making it perfect and, eventually, value-based healthcare and measuring care for effectiveness and good outcomes.
Right now, we can control how we take time, utilize a conservative approach, and continue to embrace communication. FHIR is the future. FHIR is here to stay. FHIR is not just a new fad.
While, initially, there will be flexibility for how FHIR is applied, and there will some leeway to get it wrong, we have to get it right eventually. We anticipate that adoption will take longer than we think, and that it is in sync with CMS policies. We may not meet everyone’s expectations, but we will persevere. Early adoption is not automatic success, but success is within reach.
BookZurman is ready to help you clear the smoke and reduce the complexity of adopting FHIR. However you choose to apply FHIR, whether it’s application development or interoperability, or both, contact us today to find out how we can light the pathway to 21st century interoperability.
Get to know the guest author!
Ioana Singureanu
LinkedIn
Ioana Singureanu, MSCs, FHL7, Chief Innovation Officer, has been working with BookZurman for more than a decade and is an HL7SM FHIRTM Foundation Founder. Ioana focuses her decades of domain expertise in standards development and healthcare integration to address the needs of BZ clients toward digital transformation. Ioana has assisted federal agencies (FDA, VHA, ONC, SAMHSA, NIST) to develop consensus-based specifications in applying health IT standards to national policy and regulatory requirements (using HL7, NCPDP SCRIPT, LOINC, RxNorm, NCIt, SNOMED CT, GMDN).
Additionally, Ioana is co-chair of health IT standards development organizations critical to the adoption of health IT standards consistent with the Center of Medicaid and Medicaid Services (CMS) and the Office of National Coordinator for Health IT (ONC) rules. Ioana is also co-chair of HL7 Conformance, HL7 Community Based Care and Privacy work group and a member of the HL7 US Realm Steering Committee that manages policy and governance for US-required HL7 implementation guides, guidance, and best practices referenced in the CMS and ONC rules. Ioana is an HL7 Fellow and a certified HL7 professional (HL7 V 2) and Oracle DB Administrator.
Ioana’s clients often refer to her as “5G” due to her ability to work quickly and from an innovative and high-tech perspective.
