aws-solutions / fhir-works-on-aws

A serverless implementation of the FHIR standard that enables users to focus more on their business needs/uniqueness rather than the FHIR specification.

FHIR Works on AWS

End of Life

FHIR Works on AWS has reached End of Life. This repository will be archived and set as read only. For migration alternatives please read the End of Life Notice below.

End of Life Notice

FHIR Works on AWS is reaching end of life and will no longer be available starting on January 31, 2024 — the End of Life (EOL) date. Customers will be able to use FHIR Works on AWS until the EOL date, at which time the FHIR Works on AWS solution repository will be made read-only and archived for customers.

Will there be any new feature releases for FHIR Works on AWS?

No. As the service is reaching EOL, we will not release any new features. However, we will continue to make security improvements and manage FHIR Works on AWS as expected until the EOL date. After the EOL date, FHIR Works on AWS will no longer receive any new feature updates, bug fixes or security updates from AWS. After the EOL date, customers who continue to use the software are responsible for the maintenance of the software and its dependencies.

Where should I migrate to?

AWS HealthLake is a HIPAA-eligible service that provides FHIR APIs that help healthcare and life sciences companies securely store, transform, transact, and analyze health data in minutes to give a chronological view at the patient and population-level. AWS HealthLake natively achieved feature parity with FHIR Works on AWS including SMART on FHIR and Bulk FHIR capabilities. Further, AWS HealthLake can support customer conformance with 21st Century Cures Act for patient access and interoperability requirements through a fully managed FHIR server.

AWS has released a migration tool in the FHIR Works on AWS GitHub repository to enable migration to Amazon HealthLake. The migration tool is a collection of scripts that automates the export of FHIR resources from FHIR Works on AWS and imports them into Amazon HealthLake.

What support is available?

Customers using FHIR Works on AWS can now move their workloads to AWS HealthLake leveraging the migration tool provided by AWS. Customers will be supported for migration from FHIR Works to an AWS Service such as AWS HealthLake beyond EOL. For you prefer not to migrate to AWS HealthLake or do not have AWS HealthLake support in your region, please contact your AWS account team for alternatives. If you have any questions regarding migration support, please reach out to AWS at [email protected].

Maintenance Notice

FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at [email protected]. If you are new to this solution, we advise you to explore using HealthLake, which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to [email protected] or contact your AWS Account team.

The FHIR Works on AWS solution helps software engineers at independent software vendors, system integrators, and healthcare information technology teams to enhance their own products. Using this solution, they can transfer medical records to both mobile devices and web portals in minutes rather than days or hours by integrating with the Fast Healthcare Interoperability Resources (FHIR) standard APIs. The FHIR standard was developed by Health Level Seven International (HL7) to improve the exchange of health data between software systems such as practice management, electronic health records, billing, and data exchange interfaces. It uses a serverless FHIR API that supports FHIR resource types and operations to help healthcare providers leverage the FHIR standard to manage healthcare records. It is a reference implementation, designed to be extensible.

To learn more about FWoA, download the FWoA Implementation Guide and see the following README files for individual FWoA packages:

and see the following README files for individual FWoA packages:

• deployment
• smart-deployment
• authz-rbac
• authz-smart
• interface
• persistence-ddb
• routing
• search-es

Contributing Guidelines

Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please review the Contributing Guidelines before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

Code of Conduct

This project has adopted the Amazon Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Security issue notifications

If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our vulnerability reporting page. Please do not create a public github issue.

Licensing

This project is licensed under the Apache-2.0 license.

For more information, see the LICENSE file. If you choose to contribute, we will ask you to confirm your contribution's license.

This solution collects anonymous operational metrics to help AWS improve the quality and features of the solution. For more information, including how to disable this capability, please see the FWoA Implementation Guide

fhir-works-on-aws's Issues

How to remove opensearch instances from code?

I deployed the project locally and encountered an unexpected bill totaling $1200 USD due to multiple instances of OpenSearch and approximately $150 USD attributed to Key Management Service (KMS) usage. To mitigate these expenses and avoid future cost overruns, I intend to remove the OpenSearch instances and optimize KMS usage from my codebase. I am seeking guidance on the most effective way to accomplish this while ensuring a seamless redeployment of the project. Any suggestions and best practices for code modification and resource removal are greatly appreciated.

Unable to Make API call's even using Cognito Token, API Key - Getting UnAuthorized Error

I have successfully deployed the fhir service in my AWS, however while I try to test even the basic postman calls, I am not able to do it. Getting an UnAuthorized Error. I took the latest code and the error I am receiving is 401 UnAuthorized.

Checked with the Lambda Authorization and have the latest code.

Screenshots

Need a little help on figuring out the missing elements.

[Bug] FWoA v5.1.0 deployment failed

Describe the bug
When I tried to deploy the FWoA, the deployment failed due to the error shown below.

Failed resources:
fhir-service-dev | 15:17:02 | CREATE_FAILED | AWS::S3::Bucket | fhirLogsBucket (fhirLogsBucket5D12405B) Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting (Service: Amazon S3; Status Code: 400; Error Code: InvalidBucketAclWithObjectOwnership; Request ID: 8E3GYWQVFQGXEE2E; S3 Extended Request ID: L86V77kg6kBTHkhI/B8jYKMEGKDFkzhA3VR5Z0RaxfhU4FPtlmbonpOSRxY03qrYKtmnm5lA9KM/nYNyJPqM4A==; Proxy: null)

To Reproduce
Run the command as below:

# fhir-works-on-aws-deployment-5.1.0
yarn deploy -c stage=dev -c region=ap-northeast-1

Expected behavior
Success the deployment

Versions

• FWoA v5.1.0
• nvm v16.19.0
• yarn v8.6.0
• aws-cdk 2.77.0 (build 06a0b19)

Additional context
Is this error related to the article below?
https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/
If so, do I need to modify the YAML?

[Misc] Is this still recommended for one datastore multi tenant?

What's on your mind?
Healthlake has a limit of 10 datastores per region, what if we have thousands of tenants, healthlake charges $0.27 per hour per datastore, I see in migration of FWOA to healthlake the multi tenant is being migrated to different data stores.
I was thinking on how to achieve one datastore with multi tenant for aws healthlake. I hope you could point me to the right direction.

[Misc] Observation date search is not working

Search based on dates about Observation resources is not working in v5.1.0.

For example, there is my data in Observation record:
"effectiveDateTime": "2022-11-05T11:16:00+09:00",

When I make search requests such as:
/Observation?date=ge2015-01-01
or
/Observation?date=eq2022-11-05
or
/Observation?date=lt2023-04-24

these all return a response of 0 records like below.

{
    "resourceType": "Bundle",
    "id": "xxxxxxxxxxxxxxxxxx",
    "meta": {
        "lastUpdated": "2023-04-24T07:55:05.777Z"
    },
    "type": "searchset",
    "total": 0,
    "link": [
        {
            "relation": "self",
            "url": "https://xxxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/Observation?date=ge2015-01-01"
        }
    ],
    "entry": []
}

If I dont specify "date" as below, the record will be returned correctly.
/Observation
or
/Observation?patient=Patient/xxxxx?_sort=-date

Versions :

• FWoA v5.1.0
  If I use v4.0.0, this search based on dates is working correctly.

I found similar issues, but i think those are all information about old FWoA versions, so I post this new issue.
・191
・129

Please let me know if you have any solution.
Thanks.

Storing large strings in dynamoDB

Dear Team,
I hope this message finds you well. I wanted to bring to your attention a challenge we've encountered with our current data storage approach in DynamoDB, specifically regarding the storage of extensions.

As it stands, we store extensions as a separate attribute within DynamoDB. While this approach has generally worked well, we have encountered instances where the string value within extensions exceeds the size limit supported by DynamoDB. A notable example is when we attempt to store a PDF file in base64 format within extensions, which can lead to HTTP 500 errors due to DynamoDB's constraints.

I'd like to initiate a discussion on how we can effectively address this issue. It's crucial that we find a solution to accommodate larger strings within extensions while ensuring data integrity and system performance.

Your input and expertise in this matter are highly valued.

Please let me know your thoughts on this matter, and if anyone has insights or suggestions, don't hesitate to share them. We're collectively invested in finding the best way forward to overcome this challenge.

Thank you for your attention to this matter.

[Bug] POST requests to APIG are limited to 100kb payload size

If you try to POST a document with a payload size of > 100kb you will receive an error of the form

"ERROR PayloadTooLargeError: request entity too large"

To Reproduce
Steps to reproduce the behavior:

1. Send an HTTP POST request to the APIG endpoint of the FHIR server that has a payload size greater than 100kb

Expected behavior
The lambda should be able to handle payloads of up to 6mb, according to main router configuration

Versions (please complete the following information):
7.0.1

Additional context
Examining the generated source code shows that the urlencoded module is not parsing the '6mb' correctly and is defaulting to 100kb, see last line of code snippet.

// ../../common/temp/node_modules/.pnpm/[email protected]/node_modules/body-parser/lib/types/urlencoded.js
var require_urlencoded = __commonJS({
  "../../common/temp/node_modules/.pnpm/[email protected]/node_modules/body-parser/lib/types/urlencoded.js"(exports2, module2) {
    "use strict";
    var bytes = require_bytes();
    var contentType = require_content_type();
    var createError = require_http_errors();
    var debug = require_src()("body-parser:urlencoded");
    var deprecate2 = require_depd()("body-parser");
    var read = require_read();
    var typeis = require_type_is();
    module2.exports = urlencoded;
    var parsers = /* @__PURE__ */ Object.create(null);
    function urlencoded(options) {
      var opts = options || {};
      if (opts.extended === void 0) {
        deprecate2("undefined extended: provide extended option");
      }
      var extended = opts.extended !== false;
      var inflate = opts.inflate !== false;
      var limit = typeof opts.limit !== "number" ? bytes.parse(opts.limit || "100kb") : opts.limit;