azure-fhir-service

The FHIR service in Azure Health Data Services enables rapid exchange of health data using the Fast Healthcare Interoperability Resources (FHIR®) data standard. As part of a managed Platform-as-a-Service (PaaS), the FHIR service makes it easy for anyone working with health data to securely store and exchange Protected Health Information (PHI) in the cloud.

Use Cases

The Azure FHIR service offers the following:

• Managed FHIR-compliant server, provisioned in the cloud in minutes
• Enterprise-grade FHIR API endpoint for FHIR data access and storage
• High performance, low latency
• Secure management of Protected Health Information (PHI) in a compliant cloud environment
• SMART on FHIR for mobile and web clients
• Controlled access to FHIR data at scale with Azure Active Directory Role-Based Access Control (RBAC)
• Audit log tracking for access, creation, and modification events within the FHIR service data store

FHIR Data Standard

The healthcare industry is rapidly adopting FHIR® as the industry-wide standard for health data storage, querying, and exchange. FHIR provides a robust, extensible data model with standardized semantics that all FHIR-compliant systems can use interchangeably. With FHIR, organizations can unify disparate electronic health record systems (EHRs) and other health data repositories – allowing all data to be persisted and exchanged in a single, universal format. With the addition of SMART on FHIR, user-facing mobile and web-based applications can securely interact with FHIR data – opening a new range of possibilities for patient and provider access to PHI. Most of all, FHIR simplifies the process of assembling large health datasets for research – enabling researchers and clinicians to apply machine learning and analytics at scale for gaining new health insights.

REST API

The FHIR service in Azure Health Data Services makes FHIR data available to clients through a RESTful API. This API is an implementation of the HL7 FHIR API specification. As a managed PaaS offering in Azure, the FHIR service gives organizations a scalable and secure environment for the storage and exchange of Protected Health Information (PHI) in the native FHIR format.

Design

Our bundle includes the following design choices to help simplify your deployment:

Diagnostic logging

Access to diagnostic logs is essential for any healthcare service. Compliance with regulatory requirements like Health Insurance Portability and Accountability Act (HIPAA) is a must.

Data export

The FHIR service supports the $export operation specified by HL7 for exporting FHIR data from a FHIR server. In the FHIR service implementation, calling the $export endpoint causes the FHIR service to export data into a pre-configured Azure storage account.

Autoscaling

The autoscale feature adjusts computing resources automatically to optimize the overall service scalability. It requires no action from customers. When transaction workloads are high, the autoscale feature increases computing resources automatically. When transaction workloads are low, it decreases computing resources accordingly.

Best Practices

The bundle includes a number of best practices without needing any additional work on your part.

Network security

Both storage accounts that can be provisioned with a FHIR service deployment have public network access disabled. This setting keeps your storage accounts secure, even if attached to a VNet.

OCI Artifact support

We support multiple Azure Container Registries to store FHIR converter templates.

Security

In order to improve security, we implement a few key safeguards.

Unique database isolation

As part of the Azure family of services, the FHIR service protects your organization’s PHI with an unparalleled level of security. In Azure Health Data Services, your FHIR data is isolated to a unique database per FHIR service instance and protected with multi-region failover. On top of this, FHIR service implements a layered, in-depth defense and advanced threat detection for your data

Observability

Massdriver provides you with visibility into the health of your systems. By default, storage accounts will be created with alarms connected to Massdriver to alert you when performance drops below a key threshold or fails completely. You will be notified when the total latency, server availability, or total server errors received reaches certain thresholds.

Trade-offs

• CMKs are not currently supported