One of the most exciting developments in healthcare data management is the emergence of the FHIR, or Fast Healthcare Interoperability Resources standard. How exactly can the FHIR be best deployed on AWS cloud systems? It’s simpler than you think. In this article, we’ll examine how FHIR works on AWS and how to manage deployment.
What Prompted the Development of FHIR?
The days of visiting one general practitioner are long gone. Today’s healthcare environment is one of the multiple encounters with:
- gatekeepers like primary care physicians, nurse practitioners, and physicians assistant
- Multiple laboratories offering specialized testing
- Specialist physicians and medical groups
- Hospitals and clinics
Very often, each one of these providers may use its own proprietary data standards that aren’t interoperable. This causes an inconvenience and delay for treatment providers and patients alike.
The international standards company, “Health Level Seven International” or “HL7,” created the FHIR standard to allow the seamless communication and transmission of data regardless of the entity that collected it.
There are major healthcare players that are members of the HL7 community. The Mayo Clinic, Pfizer, Quest Diagnostics, and Kaiser Permanente are just a few. However, the system was designed to be open source, so membership is not required for use.
How Does FHIR Work?
The Fast Healthcare Interoperability Resources Standard uses what are called “resources” as its building block. Each block contains the following:
- Common definitions and representations
- Common metadata
- Human readable sections.
These resources are managed through operations called “interactions. The goal of FHIR resources is to define the contents and core information in a way that can be shared. It also has built-in extensions that can add additional information as required.
FHIR APIs have been engineered to achieve commonality across facilities and platforms. It's often compared to the “Open Banking” standards that have allowed communications between financial institutions, regardless of the platform they use.
When APIs are deployed on the front end, it unlocks all the information and services available in the backend. It also provides a high level of functionality regardless of the end user: for instance, doctors, nurses, patients, insurance companies, and more.
Achieving Serverless Implementation of FHIR with an AWS solution
The term “serverless” can be a little confusing. It simply defines a way to build and install your applications without worrying about the supporting server infrastructure. Of course, servers are part of the equation, but all of this is handled by a cloud service provider - in this case, AWS.
This lets your developers focus all of their expertise on building top-notch applications and achieving your core mission. AWS allows for utilizing a FHIR serverless architecture. Let’s explore some of the ways this is possible.
One build idea includes a server, which acts as a data repository. It also has a consumer application for entering and viewing patient data. With this type of install, you can:
Post bundles of collections
- Create an FHIR Capability Statement
In the cloud, you’ll find everything you need for a smooth deployment on AWS:
- Use of Cognito user pool for the generation of authorization tokens
- AWS Lambda to parse and validate JSON payloads, then load to DynamoDB.
- AWS S3 Bucket for document repository
- Additional helpful resources.
Using FHIR Works on AWS
One of the ways in which open-source FHIR APIs can be used is through FHIR Works on AWS. This is an open-source toolkit that works seamlessly with your existing applications. The key is its use of serverless implementation, which has maximum compatibility with FHIR operations.
The result is a much-improved way for end users to design and install applications that are better accessed through all interfaces, with healthcare APIs.
This exciting project is aimed at all sorts of healthcare-related customers who are seeking to migrate to an AWS FHIR server. This includes health-related software, system integrators, hospitals, clinics, medical groups and more. There is abundant documentation about how to apply this open source project to a multitude of use cases.
Integration in Multi-Cloud or Hybrid Cloud Environments
FHIR deployment is frequently found in situations where it’s necessary to be connected to a legacy environment. Since the whole goal of FHIR is to allow for ease of communication between different standards, an integration framework is built directly into FHIR Works on AWS.
Since data access needs can vary based on the specific legacy format, FHIR Works on AWS allows for quite a bit of flexibility in the storage architecture. Different services can be substituted, such as:
- Amazon Simple Storage Service (S3)
- Amazon DynamoDB
- Amazon Relational Database Service (Amazon RDS)
- Amazon Redshift
- Amazon Neptune
Amazon Cognito provides an access token for APIs in the AWS environment. The API gateway key is provided to the external client for authentication. This enables users to take advantage of extensive logging, which is helpful in maintaining HIPAA compliance.
Currently, FHIR Works on AWS utilizes a Role-Based Access Control methodology. This allows for a stringent definition of roles: auditor, practitioner, and non-practitioner. Future releases may expand upon this in more sophisticated ways. One of them is potentially using SMART.
Logging is, as stated above, of primary importance to healthcare organizations, which are covered under the Health Insurance Portability and Accountability Act of 1996, or “HIPAA,” as it is popularly known.
Ensuring that logs are kept of what private health data has been accessed, and who accessed it is crucial to a thorough audit. If there is a breach of security or confidentiality, tracking down the source becomes much easier if logs are accurate.
With FHIR Works on AWS, logs are, by default, sent to Amazon CloudWatch. Because CloudWatch has a higher cost associated with it, FHIR Works on AWS also allows for the use of encrypted S3 buckets and Amazon Simple Storage Service Glacier.
Using Binary Resources
In the healthcare environment, a binary resource is typically images, genomic data, or electrocardiogram wavelengths. The issue here is with timeouts. Additionally, the API Gateway has limits on its payload sizes which can be an issue.
This is oftentimes a difficult issue when working with REST APIs. FHIR Works on AWS utilizes a combination approach of S3 and RESTful APIs. Once a POST request is made, a response in the form of a pre-signed URL from S3 is issued.
Working with a URL, even a temporary one, can raise security issues. That’s why the link itself has an extremely short lifespan. On top of that, the link is, of course, encrypted with HTTPS TLS, making interception nearly impossible.
Using Amazon API Gateway
The most common managed service for creating secure APIs is the Amazon API Gateway. This is what is often called the “Front Door” for accessing functionality from the backend. In a typical build, definitions for the FHIR resources map to the API Gateway.
The API Gateway also provides for reference implementation for storage data. It seamlessly can interact with Amazon Elasticsearch Service to store, retrieve and search data.
The AWS environment is truly dynamic. As new solutions emerge, it can be difficult for developers to keep up. Thankfully, the AWS Solutions Implementations website has a great deal of information on using FHIR APIs on FHIR Works on AWS.
AWS Solutions also has ready to deploy native AWS services and code. There’s also always the option of engaging with SaaS and Managed services from AWS-recognized partners.
The AWS Solutions library has a large amount of guidance documentation, such as:
- Prescriptive Architectural Diagrams
- Sample Code
- Technical content.
The Limitless Application of FHIR APIs Using FHIR Works on AWS
The healthcare landscape is becoming more complex by the day. Providers and their affiliates are dealing with massive amounts of data, all of it vital to the care of patients. It’s not just providers that are becoming more numerous.
Every day new healthcare-related startups emerge, each with new ways of providing a higher level of patient outcome and satisfaction.
Through both the HL7 FHIR standard, and APIs running on FHIR Works on AWS, all of these different innovators and care providers can finally “talk to each other.” It will be exciting to see how this standard continues to evolve and improve.
Want to learn more about using FHIR Works on AWS to integrate FHIR into your products and services? Download the full white paper, Are You Ready for FHIR? Or schedule a free consultation with a healthcare cloud expert to learn how we can help.