A Guide to the ONC's
Final Rule and FHIR
Integration
What is the ONC’s Final
Interoperability Rule?

In 2016, Congress passed the 21st Century Cures Act to drive electronic access, exchange, and the use of health data. The Cures Act breaks down barriers in the U.S. health system. It improves interoperability and unleashes innovation, allows patients better access to their health information, and reduces the burdens on payers and providers.

The ONC's Final Rule clarifies exceptions to information blocking while establishing new rules to prevent "information blocking" practices (e.g., anti-competitive behav- iors) by healthcare providers, developers of certified health IT, health information exchanges, and health information networks as required by the Cures Act. When data is able to flow more freely and securely between payers, providers, and patients, the healthcare system can hope to achieve more coordinated care, improved health outcomes, and reduced costs.

The rule focuses on changes in the existing health IT certification program. Specifi- cally, the rule implements the interoperability provisions of the Cures Act to allow for seamless data exchange among providers, payers, and patients. The rule also holds health IT developers accountable as a condition of certification.

The ONC's key regulatory requirements – information blocking and information exchange via application programming interfaces (API) – will also apply to health- care providers and healthcare information networks. To make sense of the final ruling, we have gathered and analyzed the needed data. First, we need to understand the concept of information blocking and who is affected by the rule. Then, we will demonstrate how the Fast Healthcare Interoperability Resources (FHIR) standard comes into play and highlight some key dates to remember. Let's dive in!


Information Blocking
Section 4004 of the Cures Act defines information blocking as a practice by a health-
care provider, health IT developer, health information exchange, or health information
network that is likely to interfere with, prevent or materially discourage access,
exchange, or use of EHI.
The Act specifies certain practices that may constitute information blocking:
  • Imposing formal or informal restrictions on access, exchange, or use of EHI
  • Implementing health information technology in ways that are likely to restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between HIT systems
  • Discouraging efforts to develop or use interoperable technologies or services by exercising influence over customers, users, or other persons
  • The discrimination that frustrates or discourages efforts to enable interoperability
  • Rent-seeking and opportunistic pricing practices that make information sharing cost-prohibitive
FHIR is a framework standard that solves the interoperability challenges
by increasing access to electronic health records and data sharing.
FHIR combines the best features from previous standards – HL7 v2, HL7 v3, and
CDA. while also adding some improvements. Unlike HL7 standards, which were not
freely available until 2013, the specifications for FHIR are free for use without any
constraints.

With FHIR care providers can access patient health records and export specific data,
such as medication history or vital signs records, to email, provider documentation,
or other EHR systems.
While there are a variety of relevant healthcare standards for connecting
labs, images, claims processing systems, and other pieces of the provider
world, when we look at the app economy and the clear trends in modern
computing, one API approach seems to clearly emerge–Health Level Sev-
en's Fast Healthcare Interoperability Resources standards.
Don Rucker, National Coordinator for HIT.

2
FHIR Isn't So Hard To Implement
FHIR makes use of well-known technologies – HTTPS, JSON, XML, REST, and OAuth. It means you don't need to hire a highly specialized team for it: engineering skills needed to develop FHIR-compliant apps are similar to any team working in website or web app development. As those technologies are mobile-friendly, you also can create mHealth solutions faster.
Larger talent pool makes FHIR-compliant development cost-efficient.
Book design is the art of incorporating the content, style, format, design, and sequence of the various components of a book into a coherent whole. In the words of Jan Tschichold, "methods and rules upon which it is impossible to improve, have been developed over centuries. To produce perfect books, these rules have to be brought back to life and applied."
Front matter, or preliminaries, is the first section of a book, and is usually the smallest section in terms of the number of pages. Each page is counted, but no folio or page number is expressed, or printed, on either display pages or blank pages.
From a technical side, the FHIR framework is endowed with the benefits of the REST architectural style simplifying the incorporated HTTP operations. RESTful API also enforces consistent documentation as a byproduct.

3
FHIR Uses Resources As Basis
Resources are a collection of information models that define the data elements, constraints, and relationships between the objects.

FHIR is built by Resources, that are broken down into distinct categories that can refer to each other to show you a big picture. Meanwhile, FHIR messages can be sent independently of each other.

Resources may be extended, combined, or customized to deal with clinical and operational issues focusing on common use cases. To operate the resources, FHIR uses a simple set of interactions: Create, Read, Update, Delete, Search, History, Transaction, and Operation.
FHIR Resources make health information sharing easier, so you need less time to onboard a partner in data exchange.
There are 6 categories of resources: Clinical, Workflow, Conformance, Identification,
Financial, and Infrastructure. Let's take a look at the most popular:

Clinical
Allergies
Medications
Care plans
Identification
Patient
Service location
Device information
Financial
Billing
Insurance coverage
Eligibility data
COMMON FEATURES FOR EACH RESOURCE:
► A URL-identifier
► Metadata
► XHTML summary
► A set of defined data for each resource type
► Extensibility framework to support variation in healthcare

4
FHIR Represents Operational & Clinical Concepts
FHIR Resources Specification
5
FHIR Is Vendor-Neutral
Trying to simplify the data exchange and improve the global interoperability in health- care, numerous EHR vendors have initiated the Argonaut project.

The project is dedicated to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for EHR's and other health information technology based on Internet standards and architectural patterns and styles.

As a result, there are dozens of apps built with SMART on FHIR platform, all of which are vendor-neutral and can be plugged-in to existent EHRs.

Things to consider before starting FHIR Integration
Does your system or vendor support FHIR APIs?
Does your vendor provide all the FHIR functionality?
What's the time and cost of the FHIR implementation?

Pro tip
While many third parties implement FHIR only partially, it's crucial
for you to use official HL7 documentation, or access the Newfire
Global Partners expertise to solidify the data exchange
requirements and de-risk your FHIR integration process.

© All Right Reserved. Newfire Global Partners.
email us: marketing@gonewfire.com
Made on
Tilda