BETTER DATA FOR BETTER HEALTH: - FHIRBall

BETTER DATA FOR BETTER HEALTH:

FHIR HELPS FULFILL HEALTHCARE’S INTEROPERABILITY PROMISE

TABLE OF CONTENTS

EXECUTIVE SUMMARY 1

INTRODUCTION 3

THE CHALLENGE 4

HL7 v2 5

HL7 v3/CDA 6

THE SOLUTION 7

FHIR Evolution 7

Argonaut Project: Accelerating FHIR 8

FHIR Today: Simpler, Faster, Better 9

FHIR Community 10

FHIR Ecosystem 11Patient Access to Data: Putting the Patient at the Centre of Healthcare 13FHIR Mandated by Governments in US, UK and Ontario, Canada 14

Early FHIR Implementations 15

Current Challenges to Adoption 16

FHIR TOMORROW 17

FHIR: The TCP/IP of Healthcare 17

FHIR-First Development 18

FHIRBall 19

CONCLUSION 20

Copyright @2021 The FHIR Business Alliance www.fhirball.org i

EXECUTIVE SUMMARY

In healthcare, interoperability allows different systems—such as laboratories, clinics, pharmacies, hospitals, medical practices, and patients—to communicate with one another and safely exchange data. But it has faced its share of challenges—the largest of which is data ‘siloization’, where data is stored in a variety of ways in a variety of locations, and sharing it is not possible. A seamless exchange of records would require all these different systems and care facilities to be able to talk to each other.

To try to address these problems, Health Level Seven (HL7) International, an American National Standards Institute (ANSI) accredited Standards Developing Organization, began developing interoperability standards. This paper explores the history of the HL7 standards that led to the development of the Fast Healthcare Interoperability Resources (FHIR) standard, and consider how companies have come together to foster its adoption through contributing to the community and creating alliances such as FHIRBall.

In 1987, HL7 launched the v2 open standard, which specified a framework in which data could be exchanged between disparate clinical systems. The v2 defined a series of electronic messages to support administrative, logistical, financial, and clinical processes. It was not ‘plug and play’—it provided 80 percent of the interface and a framework for negotiating the remaining 20 percent on an implementation by implementation basis. However, as the joke goes, “when you’ve seen one HL7 v2 interface you’ve seen one HL7 v2 interface.”

In late 2005 HL7 released v3/Clinical Document Architecture (CDA) to address some of the challenges with v2. The v3 was not backwards compatible with v2, so existing v2 interfaces could not easily communicate with interfaces using the new standard. This incompatibility with the more widely implemented v2 hindered its adoption, and by late 2011 it had become clear that v3 was not working. Its extreme complexity, the size of its specification, and its highly abstract reference model made v3 anything but intuitive. Another barrier to both v2 and v3 adoption was that they were locked behind credentials on the HL7 website, which prevented people from easily sharing the information contained in the standards.

To address these issues and work towards making healthcare information more easily shareable, the HL7 board convened the Fresh Look Task Force to look at the best way of creating interoperability solutions. Using HL7’s data format standards as a starting point, the task force created an entirely new standard for data exchange using a modern web-based suite of application programming interface (API) technologies. Originally called Resources for Healthcare, the standard was subsequently renamed Fast Healthcare Interoperability Resources, producing the acronym FHIR.

FHIR Release 3 was published in March 2017, as the first STU (Standard for Trial Use) release. The standard’s development over the next few years enabled application creation using modern web technologies that developers were familiar with. As FHIR adoption spread across various Electronic

Copyright @2021 The FHIR Business Alliance www.fhirball.org 1

Health Records (EHRs), the US government, United Kingdom’s (UK) National Health Service (NHS), Apple, Microsoft, and Google were also soon on board.

Today, FHIR’s international role in addressing healthcare interoperability challenges and developing opportunities is widely understood. FHIR combines the best features of HL7 v2, v3 and CDA—it is a platform encompassing a robust data model, a RESTful API, open-source tools, a global network of servers, and a collaborative community to help FHIR implementers. It offers interoperability straight out-of-the-box, simple definitions, is written in plain language, and is easy to access.

FHIR is fast becoming the future of data interoperability and application development for healthcare, with a rapidly growing pool of users and expertise. The FHIR community, led by HL7, has open membership and is dedicated to using web infrastructure to make healthcare information exchange easier while maintaining a high security level.

FHIR’s success and usability has prompted the development of a suite of complementary technologies, such as SMART (Substitutable Medical Applications, Reusable Technology) on FHIR, CDS Hooks, FHIRcast, profile and implementation guide tools, open source FHIR Servers, and automated testing tools.

On demand access to Protected Health Information (PHI) using mobile phones, tablets and other devices is now possible through FHIR APIs. Patients can get data from an Epic Hospital Information System (HIS) on their phone with the Apple Health App. The success of early FHIR implementations has increasingly led governments and vendors to choose it as the foundation for new solutions—it is now mandated for specific purposes by governments in the US, UK, and Ontario, Canada.

Despite the great success of FHIR to date and its great promise for exchanging data, implementers still face some challenges: it is not yet fully mature; people are still learning best practices for implementations; implementers have faced scalability and performance issues. However, it seems clear that FHIR will become the de facto healthcare interoperability standard. As it gains traction across the globe, companies that adopt FHIR will find more and more value. Those that do not will struggle to catch up as FHIR becomes the de facto standard for new data exchanges in Canada, Europe, US, Australia, and eventually Asia.


Imagine having access to all your healthcare information in one convenient place. Doctors’ records, hospital records, medication records, immunization records—all together and available in real time, on your phone, tablet, or the cloud, wherever you are. It sounds simple, but in the world of healthcare technology it has been extremely complicated. To achieve this seamless exchange of records, these systems need to be able to talk to each other.

As healthcare technology evolves, we are seeing a rapid proliferation of more and more complex healthcare data from an increasing number of widely dispersed sources. This overwhelming flood of data makes the ability to access and use the data in real time increasingly crucial. This is where interoperability comes in.

In healthcare, interoperability allows different systems—such as laboratories, clinics, pharmacies, hospitals, medical practices, and patients—to communicate with one another and safely exchange data. It improves efficiency, reduces ambiguity and costs, and at the same time ensures confidential patient data protection. Ultimately, an interoperable environment improves healthcare delivery by getting the right data to the right people at the right time.

This white paper explores the history of the HL7 standards that led to Fast Healthcare Interoperability Resources (FHIR) standard development and consider how companies have come together to foster its adoption through contributing to the community and creating alliances such as FHIRBall.

INTRODUCTION

Getting the right data to the right people at the right time


THE CHALLENGE

Interoperability in the healthcare industry has faced its share of challenges. One of the biggest has been data ‘siloization’. Healthcare data production has increased exponentially, but this data has rarely been shareable. Each institution maintained its own data store as part of its application; every region defined its own data set. As a consequence, health data has been stored in unique ways in a variety of locations. These silos of information couldn’t easily exchange data and made every integration a custom effort. Interoperability was just not scalable. Another challenge was the lack of semantic interoperability—we had no consistent way of expressing the simplest concepts, such as agreeing on the definition of a health concern and how to express the thousands of concepts that could be considered a health concern.

To try to address these problems, Health Level Seven (HL7) International, an American National Standards Institute (ANSI) accredited Standards Developing Organization that operates in the healthcare arena, began work on interoperability standards.


HL7 v2

The HL7 v2 standard was created in 1987, mostly by clinical interface specialists, providing a framework in which data can be exchanged between disparate clinical systems. The standard defines a series of electronic messages to support administrative, logistical, financial, and clinical processes. It was built in an ad hoc fashion because no other healthcare interoperability standard existed at the time.

V2 is an open standard. Open standards are publicly available and are developed and maintained via a collaborative, consensus-driven process. They facilitate interoperability and data exchange and are intended for widespread adoption, implementation, and extension.

V2 defines HL7 encoding rules, groupings, cardinality, and the default character set (ASCII). It supports local variations in data exchange by allowing for optional fields and additional messages. V2 is not ‘plug and play’—it provides 80 percent of the interface and a framework for negotiating the remaining 20 percent on an implementation by implementation basis. However, as the joke goes, “when you’ve seen one HL7 v2 interface you’ve seen one HL7 v2 interface.”

HL7 v2 is still in use in hospitals all around the world, and this is not likely to change in the near future.


HL7 v3/CDA (Clinical Document Architecture)

In late 2005, after decades of effort, HL7 released HL7 v3, which was shaped by governments and medical information users rather than clinical interface specialists. V3 was not backwards compatible with v2, so existing v2 interfaces could not (without considerable modification) communicate with interfaces using v3. This incompatibility with the more widely implemented v2 hindered v3 adoption.

V3 was intended to address some of the challenges with v2, and to drive worldwide adoption of a single standard. It presented a new and consistent data model, and a more precise, less flexible standard—approaching ‘plug and play’. CDA is a model created using HL7 v3 and its underlying Reference Information Model to represent a clinical document. It specifies the structure and semantics of the document so that it can be shared between healthcare providers and patients.

HL7 v3 was developed following a ‘design by constraint’ methodology. Any concept that might ever need to be exchanged between health information applications was rigorously defined, and any content that didn’t apply to an implementation had to be removed, where permissible. As a result, v3’s development process slowed to a crawl while the specification got

larger and larger, placing a significant workload on implementers. To adopt v3, users would need to create and maintain v2-based interfaces with v2-based applications, while deploying new v3-based applications and implementing interfaces between them. For this reason, v3 was primarily only adopted for applications without legacy communication requirements, or in locations where it was encouraged by governmental organizations.

The extreme complexity of v3, the size of its specification, and its highly abstract reference model, made v3 anything but intuitive—implementers often had to take introductory courses in order to understand and use it. These factors created significant barriers to its adoption.

Another barrier to the adoption of both v2 and v3 is that they were locked behind credentials on the HL7 website, which prevented people from easily sharing information contained in the standards. To address these issues and make healthcare information more easily shareable, the FHIR standard was developed. FHIR effectively picks up where HL7 v2 left off.


THE SOLUTION

FHIR EVOLUTION

By late 2011, it had become clear that HL7 v3 was not working. It was taking too long to develop and simply wasn’t being adopted. In response, the HL7 board convened the Fresh Look Task Force to look at the best way of creating interoperability solutions. Putting previous HL7 standards behind them, the group went back to basics and considered what interoperability is trying to achieve.

By 2014, a small community of stakeholders had dedicated themselves to solving the healthcare interoperability problem. Using HL7’s data format standards as a starting point, they created an entirely new standard for data exchange using a modern web-based suite of Application Programming Interface (API) technologies. Originally called Resources for Healthcare, the standard was subsequently renamed Fast Healthcare Interoperability Resources, producing the acronym FHIR.

Standards organizations and governments worldwide became involved in the ongoing process of ensuring continual FHIR standard improvement, which went through several iterations before publication as a Draft Standard for Trial Use (DSTU) in 2014.

FHIR Release 3 was published in March 2017, as the first STU (Standard for Trial Use) release. It included coverage of a variety of clinical workflows, a Resource Description Framework format, and other updates. FHIR Release 4.0.1 was published on October 30, 2019. The standard’s development over the next few years enabled application creation using the modern web technologies developers were familiar with, such as HTML, JSON, XML and OAuth—internet standards and technologies already in use by industries outside of healthcare. As FHIR adoption spread across various EHRs, the US government, United Kingdom’s (UK) National Health Service (NHS), Apple, Microsoft, and Google were also soon on board.


ARGONAUT PROJECT: ACCELERATING FHIR

The Argonaut Project is a US private sector initiative comprising of leading technology vendors and provider organizations whose goal is to promote and advance the industry adoption of modern, open interoperability standards—specifically FHIR-based API and core data services—for health information exchange between patients, providers, and payers. Working collaboratively with other FHIR initiatives such as SMART on FHIR, the Health Systems Platform Consortium, and the FHIR Foundation, the project provides acceleration of funding and political will to publish FHIR implementation guides and profiles for interoperability and document retrieval.

Argonauts include technology vendors such as Apple, Epic, and MEDITECH, as well as provider organizations such as the Mayo Clinic and SMART at Boston Children’s Hospital.


FHIR TODAY: SIMPLER, FASTER, BETTER

By now, just about everyone working in healthcare IT has heard about FHIR. The standard’s international role in addressing healthcare interoperability challenges and developing opportunities is now widely understood. The aim of FHIR was to build a standard that meets the requirements of modern data interoperability, while at the same time being simple, straightforward, and easy to access (we know that the easier a standard is to implement, the more uptake it will have). These attributes make FHIR more and more valuable as it is adopted in more and more situations.

Today, FHIR combines the best features of HL7 v2, v3 and CDA. It is an easy-to-use, open source standard for exchanging healthcare data based on modern web technologies. FHIR makes interoperable healthcare applications dramatically simpler, easier, and faster to develop.

Among the many things that differentiate FHIR from previous efforts is that it is not just a standard. It is a platform, encompassing a robust data model, a RESTful API, open source tools, a global network of servers, and a collaborative community to help FHIR implementers —with forums wikis, and resources such as test data, code libraries, test servers and other supporting tooling that developers need to quickly create applications. This is a major plus for the developer community. There are even reference implementations in a variety of programming languages.

FHIR offers interoperability straight out-of-the-box, focusing on base resources that can be used as is, or adapted to meet jurisdictional requirements. This feature gives implementers a great deal of flexibility. In fact, FHIR is not specific enough to be plug and play, because almost nothing is mandatory. Its base specification is predicted to be about 20% of the size of the v3 specification, while

covering the data elements meeting 80% of the requirements common in most implementations.

FHIR’s simple definitions are written in plain language. Its developers want users to quickly understand how it works, including the ability to see all the FHIR resources on a single web page. You can click on a resource and see it expressed in UML, XML, JSON, or Turtle.

Finally, it is very easy to access. Anyone can go to www. hl7.org/fhir and use the standard and all its supporting documents without needing a membership or even registering an email and password.

FHIR is spreading fast, becoming the future of data interoperability and application development for healthcare, with a rapidly growing pool of users and expertise. It is now widely used, in thousands of applications that provide benefit for providers, patients, and payers around the world. It has been mandated by countries, states, and provinces. Its great value to interoperability lies in how well it interacts and can be used with other widely used standards. Most importantly, FHIR drastically reduces the cost of interoperability, giving implementers more outcomes for their investment.


FHIR COMMUNITY

The FHIR community is dedicated to using web infrastructure to make healthcare information exchange easier. Led by HL7, it has open membership. It is deeply connected to the worldwide health community, and produces open standards, built by iteration and continuous demonstration. The community uses modern communications channels — Wikis, GitHub, Slack— to share its work, as well as face-to-face meetings, teleconferences, and forums. Developers all over the world have tested their applications at FHIR connectathons—62 vendors participated in the last event, twice that of the previous year.


FHIR ECOSYSTEM

The success and usability of FHIR has prompted development of a suite of complementary technologies.

• SMART (Substitutable Medical Applications, Reusable Technology) on FHIR is a set of open specifications to integrate apps with EHRs and other healthcare IT systems. Funded by the US Office of the National Coordinator (ONC), SMART allows developers to create apps that can access data in a variety of source applications, leading to the phrase ‘create once, use across many EHRs’. It sits on top of FHIR interfaces and provides a security layer, giving approved applications access to the data within an EHR or any other SMART on FHIR-compliant repository.

Here’s how it works. A user of an Electronic Medical Record (EMR) launches a SMART app. The EMR passes information to the SMART app, such as the URL for the EMR’s API, which the SMART app can then query to get data from the EMR and do something with it, such as presenting a growth chart or calculating a cardiovascular risk score.

It’s becoming increasingly apparent that SMART on FHIR APIs will change how we integrate healthcare systems. SMART on FHIR has gained widespread support and adoption from major EHR vendors, government regulatory bodies, technology companies, payers, and providers. Ultimately, this must result in increased market size, potential for profit, and value for a larger number of users.

• CDS Hooks is an HL7-published open source specification for clinical decision support. Using

similar design patterns as SMART on FHIR, CDS Hooks describes how third-party clinical decision support (CDS) applications can access data in a source system to essentially present ‘cards’ to the user, offering advice or prompting action—the ‘hooks’. Several major EHR vendors are now providing support for the protocol as more and more third-party CDS applications become available.

• FHIRcast is a new way to synchronize context (e.g., patient or provider views of information) across healthcare applications in real time. For example, a clinician is looking at a patient record in an EHR and launches a SMART app that brings up additional information about the patient. The clinician decides to look at a different patient in the EHR. FHIRcast can be used to notify the SMART app that the context (i.e., patient) has changed in the EHR and should change in the SMART app as well. The FHIRcast specification is based on modern IT infrastructure and standards, and supports context sharing between anything from applications on the same computer to completely separate devices. Currently being developed by HL7, it has close connections with the FHIR standard. A major advantage to it is that FHIRcast is an Open Source project at GitHub, which means that anyone can easily contribute ideas, concerns, or even code.

• Profile and Implementation Guide Tools are freely available to help document the rules and expectations for specific FHIR implementations. These tools make it easy to create FHIR resource ‘profiles’ that constrain or extend the base standard, publish profiles for others to re-use,


and add implementation guidance in the form of use cases, examples, interaction diagrams, etc. Simplifier.net is a global FHIR registry where users can search for existing profiles and implementation guides. Some countries also have national registries on Simplifier.net, such as the Canadian FHIR Registry.

• Open Source FHIR Servers are also readily available. Implementers can deploy these FHIR servers on their local computer, server, or cloud-based infrastructure, and then configure it to adhere to the FHIR profiles and API rules described in the guide for a specific implementation. This allows developers to use both the implementation guide and a real test server to support their development activities.

• Automated testing tools provide the ability to easily develop test scripts and automatically test FHIR servers for compliance with the base standard and the conformance rules declared in implementation guides. These test tools offer ‘happy path’ testing to see if the FHIR server behaves as expected, as well as ‘unhappy path’ testing to see how the FHIR server behaves when subjected to unexpected conditions.

Collectively, the FHIR ecosystem of specifications and freely available tools are fostering rapid development of FHIR-based applications and servers, which in turn is creating greater demand for FHIR-based data exchange.


PATIENT ACCESS TO DATA: PUTTING THE PATIENT AT THE CENTRE OF HEALTHCARE

Pressure is building to finally put personal health information (PHI), particularly data in EHRs, in the hands of patients. Government regulators want to ensure compliance with interoperability legislation. Providers want to improve outcomes and lower costs by integrating patients into their care team. Payers such as health insurance plans and government programs such as Medicare and Medicaid in the US are looking for ways to reduce costs by increasing patients’ participation in their own healthcare. They are also considering new ways to connect with their clients.

Meanwhile, patients are more and more interested in accessing their healthcare data as they recognize that they are likely to receive better care when they are more engaged. They are increasingly looking for easy and secure ways to do so.

Fortunately, on demand access to PHI using mobile phones, tablets and other devices is now possible through FHIR APIs. For example, patients can now get data from an Epic hospital information system (HIS) on their phone with the Apple Health App. FHIR’s use in patient-focused apps puts patients at the centre of their own care, specifically through patient access to data and patient-directed data sharing. The potential benefits, to both patient and provider, are huge.

It is becoming clear that engaging patients (and their family members) in their own care leads to improved results, especially for those with multiple chronic conditions. Patients who play an important role in managing their own health are more likely to have favourable outcomes.

Today, we have apps that provide secure data sharing at a granular level and are available on a wide variety of devices—computers, tablets, phones. The patient is empowered by having direct control over who they want to share data with, such as their healthcare providers and care givers; they

can choose to share some or all of their data, set a term to the access, and revoke it at any time.

The benefits of this data sharing are not just for the patient. Any participant on the healthcare continuum will benefit from seamless patient data exchange. When patients are more actively engaged in their own health, overall costs to the health system are lower.

We know that there has long been a need for a more effective approach to the continuity of care. When a patient is admitted to the hospital for an acute care episode, they are often discharged to one or more temporary facilities, where they continue to get required care levels, before finally being released to home and/or home-based services. This transitioning of care providers is referred to as transitions of care. It is critical that accurate information follows the patient across their care continuum. Ineffective transitions of care are a major obstacle to patient recovery, as incomplete, inaccurate or missing information leads to inappropriate care, adverse events, unnecessary readmissions, failures in patient education, along with redundant tests and higher costs.

FHIR provides third-party application developers with the means to develop patient-centric applications that can be easily integrated into existing systems. As these new systems become common, we will finally have the patient at the centre of their healthcare.


FHIR MANDATED BY GOVERNMENTS AROUND THE WORLD

The success of early FHIR implementations has increasingly led governments and vendors to choose it as the foundation for new solutions.

In 2020, the US Office of the National Coordinator for Health Information Technology (ONC) rolled out the next phase of the 21st Century Cures Act, the Interoperability and Patient Access Final Rule. The rule aims to drive interoperability and patient access, as well as healthcare ecosystem innovation. It requires all agencies participating in Centre for Medicare and Medicaid (CMS), such as insurance companies, to make health information accessible through a patient access API, in a standard format—FHIR release 4 (R4) APIs as defined by HL7. It will empower patients by giving them access to their health information when they need it most, and in a form they can best use. The rule will result in better outcomes and lower costs, and will drive greater patient healthcare data sharing among CMS-regulated health plans.

To reduce the financial burden of compliance with the rule, the Da Vinci project was initiated. This is a private sector initiative that addresses the needs of the value-based care community by leveraging the FHIR platform payers and providers in the US. The goal of the Da Vinci project is to help payers and providers to positively impact clinical, quality, cost and care management outcomes, thereby reducing the burden of compliance on the industry.

In the UK, NHS Digital is the government-funded ‘national information and technology partner to the health and care system’ with responsibility for providing national scale information systems. NHS Digital adopted FHIR as the preferred standard for all new interoperability projects (https://digital.nhs.

uk/services/fhir-apis) and is fueling adoption with freely available tools (e.g., FHIR reference servers) and a blend of incentives and mandates depending on the degree of influence over implementers.

Meanwhile in Ontario, Canada’s most populous province, the purpose of the Digital Health Information Exchange (DHIEX) Policy (Draft for Discussion, 2020) is to enable the province of Ontario to more easily and rapidly adopt and implement standards for information exchange in local, regional, and provincial digital health tools. Simply put, the policy mandates that all health information custodians (HICs) must comply with Ontario Health-established interoperability specifications (Ontario Health is the province’s integrated public healthcare system), must modernize relevant digital health assets according to these interoperability specifications, and must make use of any Ontario Health resources including the Ontario Health-certified digital health assets. Finally, they must provide Ontario Health with a report setting out compliance with these requirements. The intent is that information will follow patients in an integrated way across the health system; digital health tools will be able to interoperate with each other; and patients will benefit from improved access to their own personal health information. DHIEX policy doesn’t mandate FHIR per se but does set the expectation that the majority of new health data exchanges are to be FHIR-based.


EARLY FHIR IMPLEMENTATIONS

Many examples of early FHIR implementations can be cited—from multinational vendors to government sponsored initiatives. In 2013/14 in the US, for example, the ONC signaled that patient access to data was a priority. In response to this, with the formation of the Argonaut Project, large EHR vendors such as Epic and Cerner decided to get ahead of the government and come up with their own common standards approach, embracing FHIR. This profoundly affected FHIR adoption. In 2018, the ONC reported that ten health IT developers; Allscripts, Epic, Cerner, GE, eClinicalWorks, Meditech and others, are already using FHIR. These EHRs create the largest market share across hospitals, clinicians, and patients.

Other notable implementations include:

• Apple Health: Apple’s Health application leverages the latest interoperability standards like SMART and FHIR to aggregate health records from different providers for secure viewing and storage on the user’s iPhone.

Integrating with Apple Health is great for organizations seeking to drive patient engagement. Having data on their iPhone gives patients frictionless access to their health records whenever they need them. It can also increase awareness and uptake of patient portals since users can self- authenticate in the health app with their existing portal credentials.

• PatientShare: One product that enables secure patient-directed data sharing is PatientShare, from Patient Centric Solutions. Powered by the FHIR API, it provides a means for a patient-centered record to be available across disconnected healthcare systems. True care collaboration across facilities can be achieved when combined with a read/write repository. With PatientShare, health data follows the

patient. The PatientShare system can be configured to support both organizational authorized exchange and patient-directed exchange, and can address the challenges in transitions of care.

• Epic MyChart: MyChart is a service available in 130 countries and currently available in seven hospitals in Ontario. MyChart allows patients to view their hospital records and to grant access to caregivers and clinicians.

• In Ontario, Canada, the FHIR-based Ontario Digital Health Drug Repository provides patient drug information to healthcare providers, such as publicly funded drugs, monitored drugs, and publicly funded pharmacy services. The aim is to enhance patient experience, improve patient self-care, improve patient outcomes and decrease adverse drug events, better integrate drug information through all digital point of care systems, and improve collaboration between healthcare providers through patient clinical information sharing. Also in Ontario, the FHIR-based Ontario Digital Health Immunization Repository improves health outcomes by making comprehensive immunization information accessible in real-time. It is a centralized repository of standardized electronic immunization data, and supports data sharing for public health purposes.


CURRENT CHALLENGES TO ADOPTION

Despite the great success of FHIR to date and its significant promise for exchanging data, implementers still face some challenges:

• FHIR is evolving. Now that people have a standard that is easy to access, learn, and implement, anyone can develop their own profiles and implementation guides, and create new APIs, using a blend of FHIR releases. This can create incompatibility between implementations.

• Governance of common localizations. For example, many Canadian provincial health insurers provide citizens with a health card that contains an identifier and version code. The concept of an identifier version code does not exist in the patient FHIR resource and Canadian implementers need to create an extension. It is in the best interests of vendors, governments and taxpayers to develop a common method for creating a version code extension instead of doing it differently in every implementation. However, there is no organization with the funding or mandate to lead these efforts in Canada.

• Scalability/performance issues: another challenge with FHIR implementation is the quantity of data that is created—millions of tiny pieces of data are created on a daily basis, and this is clogging up systems and causing deterioration in performance. The accelerated adoption of FHIR for healthcare information exchange between providers and payers will necessarily lead to scalability challenges.

• Investment in other standards: organizations that have invested substantially in infrastructure based on v2 or CDA are reluctant to make the quantum change that FHIR implementation would involve.

To combat some of these challenges, the ONC-led FHIR at Scale Taskforce (FAST) initiative brings

together a group of highly motivated healthcare industry stakeholders and health information technology experts to develop solutions to current barriers and accelerate adoption at scale. The FAST team has identified the following technical barriers to FHIR at scale adoption:

• Patient and provider identity management

• Directory services

• Version identification (governance)

• Scalability (some public cloud vendors are actively working to meet these challenges, such as Microsoft Health and AWS’ open source FHIR Works project)

• Barriers to the exchange process/metadata

• Testing, conformance and certification

• Security

The point to bear in mind is that FHIR is still evolving, and people are still learning best practices for FHIR implementations. The prevailing wisdom on a resource and its data elements may change from year to year—for example, the Patient resource is pretty stable and is not likely to change from one version of FHIR to the next; some of the newer resources, such as Device, are not yet mature, and may change in subsequent FHIR releases. While many FHIR implementations are viable today, FHIR also opens opportunities for new paradigms and innovations. The FAST efforts have both identified barriers to achieving the broader vision and are defining solutions to eliminate those barriers.


FHIR TOMORROW FHIR: THE TCP/IP OF HEALTHCARE

With FHIR, we are experiencing the kind of quantum leap that happened in the 1980s and early 90s, when the TCP/IP internet protocol suite was introduced. TCP/IP was also an open standard, and provided the conceptual model and set of communications for the internet. Before TCP/IP, we were not able to interact with other systems. Networks were internal. Then TCP/IP was universally adopted and the internet was born—the first truly open and collaborative environment, owned by no corporation, in which anyone can participate.

FHIR operates on the same level—now we have an open standard with which anyone can build, and semantic interoperability tools to allow for easy communication between participants. As with the internet, we can now establish connectivity between participants who have never had it before. And as a consequence we are seeing the emergence of an entire new business environment. As long as you use this open standard, as long as you use this ‘TCP/IP of healthcare interoperability’, you can share data in meaningful and useful ways, using tooling that you have built yourself or bought into. All of the major electronic health records now support the FHIR API, many for multiple versions.

The financial models for healthcare will change as a result of FHIR. Delivery and engagement models will be different. Over the past year it has become common for us to all work from home via video; in future, healthcare services will similarly be delivered online in different ways, with new devices and tools via FHIR.

FHIR will be the de facto healthcare interoperability standard. As it gains traction across the globe, companies that adopt FHIR will find more and more value. Those that don’t will find their value dwindling as the standard is mandated across Canada, Europe, US, Australia, and eventually Asia.


FHIR-FIRST DEVELOPMENT

FHIR-first is a relatively new but notable trend that can be understood as an “unexpected” side effect of FHIR. FHIR was initially designed as a data exchange protocol, but “accidentally” provided the answers to a number of challenging questions related to health IT systems development such as standardized data models and APIs.

The FHIR community has invested many resources in FHIR-first, and it’s a fantastic source of wisdom and expertise.

The community has a new approach to building health IT systems, where instead of splitting a system into internal core and external interfaces to enable interoperability, implementers can build the whole system on FHIR, achieving ‘“deep interoperability” by design.

There are some companies rewriting/refactoring existing systems and well-minded start-ups who want to do “health IT properly” and start on FHIR from scratch to accelerate development, adopting FHIR-based solutions to achieve interoperability and win the efficiency race.

Building systems on the FHIR foundation reduces time and effort because it provides the opportunity to reuse existing models and design decisions, improve quality with the organized collective intellect of the FHIR community, and build a system that’s ready for the “connected healthcare” of the future.

The FHIR server is designed for information exchange, and the FHIR backend is intended for systems development with deep interoperability. Taken together, it forms a comprehensive healthcare web.

The FHIR-first approach is still relatively new and there is a lot of space to investigate at the borders between standards and the world of development. What is certain is that there is a community to support FHIR implementers no matter where they are in the journey.


FHIRBALL

The FHIR Business Alliance (FHIRBall) is a global partnership of companies that believe FHIR is driving massive change in healthcare IT, which in turn is driving progress in healthcare by enabling true interoperability through standard, safe, and efficient APIs. Through these companies FHIRBall strives to propel the healthcare industry forward though their community-based approach to the FHIR standard.

FHIRBall’s purpose is to expand FHIR knowledge, spread awareness about health interoperability, and build more interoperable FHIR solutions around the world. By promoting FHIR, the group aims to empower openness and better collaboration across the healthcare industry.

FHIRBall’s core values are rooted in the principles of the FHIR community. They:

• believe healthcare data belongs to the patient or care provider, not the vendor

• put patients and healthcare providers first, by creating safe and standardized APIs

• avoid vendor lock-in by using open and standardized APIs to give access to data

• support open standards, open-source and open communities

• actively contribute to the FHIR standard and provide support to the FHIR community, with the intention of increasing healthcare IT standards globally

• put developers first by providing accessible platforms, events, training, and other developer-friendly products to support the FHIR developer community

• build interoperable solutions based on open standard FHIR APIs, driving change in healthcare


CONCLUSION

Today, all healthcare technology participants know about the FHIR standard and how it enables secure access to data across systems and devices in real time: an ‘internet for healthcare data’. There is an ever-growing body of implementers. We are sharing structured content in ways that are easily accessible to anyone who is interested in participating. But this is a recent development.

We have faced a number of tough challenges to interoperability. One of these was data ‘siloization’, in which everyone maintained their own data stores and their own data platforms as part of their applications; there was no other option. Another challenge was the lack of semantic interoperability—we had no consistent way of expressing the simplest concepts, such as what’s a patient, what’s a provider, what data is relevant for a provider.

HL7 v3 was an attempt to fix these problems but it was not successful. Enter FHIR, which provides semantic interoperability by establishing a clear data model, clear constraints on the data model, anticipated standards, and the mechanism to identify the standards. Baked into FHIR is the concept that with nothing other than the standard and references to external objects you can immediately start sharing data. And FHIR comes with an API that allows you to do useful things with the data you are sharing.

As was the case when the TCP/IP protocol arrived, quickly facilitating the development of what we now call the internet, FHIR facilitates connectivity between participants who have never had it before. Laboratories, clinics, pharmacies, hospitals, medical practices, and patients can now communicate with one another and safely exchange data in meaningful and useful ways. Like TCP/IP, FHIR is an open standard, owned by no one, and a truly collaborative environment.

FHIR’s success seems set. In today’s marketplace, when new healthcare data exchanges are being implemented, FHIR will be used. As a consequence we are seeing the emergence of an entirely new business environment and demand for new technologies and skillsets. FHIRBall members represent the range of product and professional services companies with the technologies and skills to support any aspect of FHIR implementation.


The FHIR Business Alliancewww.fhirball.org

Copyright @2021 The FHIR Business Alliance. All product names, logos, and brands are the property of their respective owners.

All company, product and service names used are for identification purposes only. The use of these names, logos, and brands does not imply endorsement.

Date post:	16-Jan-2023
Category:	Documents
Upload:	khangminh22
View:	0 times
Download:	0 times

BETTER DATA FOR BETTER HEALTH: - FHIRBall

Documents