HAPI vs Google-Healthcare

[bwalsh]

HAPI vs Google-Healthcare API

The architecture consists of several key components:

1. Client Applications: These applications (e.g., command line utilities, notebooks, etc) will connect to the system.
2. Reverse Proxy (Nginx): Nginx acts as a reverse proxy, receiving all incoming requests from client applications. Critically, it terminates SSL/TLS encryption at this layer and manages certificates.
3. FHIR Server

• Google Healthcare FHIR Server: This is the backend service responsible for storing and managing FHIR resources. It receives requests from nginx and a custom proxy that enables public access by adding an authorization header. This improves security as the FHIR server's IP address is not directly exposed to the public internet. A proxy is required for public access because the Google Healthcare API does not support CORS or public access. "Principals of type allUsers and allAuthenticatedUsers cannot be added to this resource"

• HAPI FHIR Server: This is the backend service responsible for storing and managing FHIR resources. It receives requests from nginx via an internal, unencrypted connection.

Cost Considerations for Implementing FHIR Solutions with a Reverse Proxy

When choosing between Google Cloud Healthcare FHIR API and HAPI FHIR JPA Server, cost is a crucial factor that depends on deployment strategy, infrastructure, and scalability needs.

1. Google Cloud Healthcare FHIR API with a Reverse Proxy

• Cost Structure:

  • Costs are based on API usage (reads, writes, and storage) as per Google’s pricing model.
  • No need for infrastructure maintenance, reducing DevOps costs.

• Additional Costs:

  • Networking: Cloud Load Balancer, Cloud Armor for security.
  • IAM & Security: Access control and auditing.

• Ideal For: Organizations looking for a managed, scalable solution with minimal infrastructure overhead.

---

2. HAPI FHIR JPA Server with a Reverse Proxy

Getting Started Version (Docker-Compose)

• Low-cost setup using a single virtual machine with Docker.
• Includes HAPI FHIR, PostgreSQL, and a reverse proxy in a self-contained environment.
• Ideal for development and testing but not suitable for production due to limited scalability.

Scaled for Production (GKE Deployment)

• Infrastructure Costs:

  • Google Kubernetes Engine (GKE) for high availability.
  • Cloud SQL (PostgreSQL) for database persistence.
  • Managed Load Balancing for secure API access.

• Operational Costs:

  • Higher compute and storage costs compared to a managed API like Google FHIR.
  • Requires ongoing DevOps support for scaling, monitoring, and security.

• Ideal For: Organizations that need FHIR R5 support, advanced search capabilities, and full customization of their FHIR implementation.

---

Conclusion

Choosing between these options depends on the trade-off between ease of deployment and long-term cost efficiency versus customization and control over the FHIR implementation.

• Google Cloud Healthcare FHIR API → Best for low-maintenance, managed scalability.
• HAPI FHIR JPA Server (GKE) → Best for custom FHIR deployments with R5 support and advanced queries.

nginx/proxy

Either service will require a SSL and reverse proxy

GOOGLE:

See https://cloud.google.com/healthcare-api/pricing#data_storage

Storage 1-1,024 GB (1 TB) (per GB per month)

Structured Storage: $0.39 per GiB per month

Request Pricing
The following table lists the pricing for requests to the FHIR store.
Priced per 100,000 requests per month.

Standard requests $0.00 $0.39 $0.29
Complex requests $0.00 $0.69 $0.59

HAPI-Docker-Compose

HAPI-Kubernetes:

Pro/Con

Comparison of Google Cloud Healthcare FHIR API and HAPI FHIR JPA Server

1. FHIR Version Support

Google Cloud Healthcare FHIR API

• Supported Versions: R4, STU3, DSTU2.
• Limitations:
  • Does not support R5 (latest version).
  • Each dataset must be created with a specific FHIR version and cannot be changed later.
  • Limited flexibility for handling mixed-version datasets.

HAPI FHIR JPA Server

• Supported Versions: DSTU2, STU3, R4, and R5.
• Advantages:
  • R5 is supported, making it more future-proof for newer FHIR implementations.
  • Can support multiple FHIR versions simultaneously in the same deployment, providing better flexibility.

---

2. FHIR Search Capability

Google Cloud Healthcare FHIR API

• Strengths:
  • Implements most of the FHIR Search API, including _id, _lastUpdated, identifier, and name.
  • Supports _include and _revinclude for relationship traversal.
  • Optimized queries using _count and _sort parameters.
  • Custom search parameters can be defined to suit specific use cases.
• Limitations:
  • Does not support all combinations of _include and _revinclude. Chained searches limited to 100 results

HAPI FHIR JPA Server

• Strengths:
  • Fully implements FHIR Search API, including _include, _revinclude, _has, _elements, _summary, and _filter.
  • Allows complex queries spanning multiple resources using chaining.
  • Custom search parameters can be defined to suit specific use cases.
• Limitations:
  • Performance may degrade with large datasets unless optimized (e.g., adding indexes or sharding the database).
  • Requires more technical expertise for setup, maintenance, and handling potential limitations in advanced search capabilities.

---

3. Deployment and Scalability

Google Cloud Healthcare FHIR API

• Deployment:
  • Fully managed service, eliminating infrastructure management.
  • Seamlessly integrates with Google Cloud services (e.g., BigQuery, Pub/Sub).
• Scalability:
  • Automatically scales to handle large datasets and high query volumes.
  • Ideal for organizations already using Google Cloud infrastructure.

HAPI FHIR JPA Server

• Deployment:
  • Open-source, requiring self-hosting and management (e.g., Kubernetes, Docker).
  • Supports various relational databases (PostgreSQL, MySQL).
• Scalability:
  • Scalability depends on manual setup (e.g., load balancing, clustering).
  • Requires DevOps expertise to ensure availability and performance.

---

4. Customization and Extensibility

Google Cloud Healthcare FHIR API

• Limitations:
  • Minimal customization options.
  • No native support for custom search parameters or non-standard resource types.
  • Strictly compliant with FHIR standards.

HAPI FHIR JPA Server

• Strengths:
  • Highly customizable to support:
    • Custom resources.
    • Custom search parameters and extensions.
    • Hooks for implementing custom business logic.
  • Suitable for use cases requiring non-standard FHIR extensions or functionality.

---

Summary of Key Differences

Feature	Google Cloud Healthcare FHIR API	HAPI FHIR JPA Server
FHIR Version Support	R4, STU3, DSTU2	DSTU2, STU3, R4, R5
Advanced Search	Partial (limited _include/_revinclude)	Full (includes _has, etc.)
Custom Search Parameters	Supported	Supported
Managed Service	Fully managed	Self-hosted
Scalability	Automatic	Manual setup required
Customization	Minimal	Highly customizable
R5 Features	Not supported	Supported

---

Conclusion

• Choose Google Cloud Healthcare FHIR API if you need a fully managed, scalable solution and can work within the constraints of limited customization and search functionality.
• Choose HAPI FHIR JPA Server if you need R5 support, advanced search capabilities, or custom extensions and are comfortable with managing your own infrastructure.

For most research-heavy use cases or projects requiring R5 features, HAPI FHIR JPA Server may be the better choice. However, for production workloads integrated with Google Cloud's ecosystem, Google Healthcare FHIR API offers simplicity and scalability.