基于FHIR works on AWS部署的FHIR服务器：如何使用客户端自定义ID创建资源及调整CapabilityStatement配置

Let’s walk through how to enable client-provided custom IDs for your FHIR resources deployed via the FHIR Works on AWS solution:

1. Enable updateCreate in the CapabilityStatement #

The core issue here is that the default deployment doesn’t allow upsert-style PUT requests (which let you create resources with custom IDs). To fix this, you need to adjust the CapabilityStatement generated by the FHIR server:

• Find the Metadata Handler Lambda: In your AWS Console, navigate to Lambda and locate the function handling metadata requests (it’ll likely be named like <your-stack-name>-MetadataHandler-<random-suffix>).
• Edit the Lambda code: Look for the section where the CapabilityStatement is built. For each resource type you want to support custom IDs for, set the updateCreate property to true in the resource’s definition. Here’s an example snippet for a Patient resource:

  resources: [
    {
      type: 'Patient',
      profile: 'http://hl7.org/fhir/StructureDefinition/Patient',
      interaction: [
        { code: 'read' },
        { code: 'create' },
        { code: 'update' },
        { code: 'delete' }
      ],
      updateCreate: true, // Toggle this to true
      // ... other existing properties
    }
  ]
  

• Deploy the changes: Save your edits and deploy the updated Lambda function to make the change live.

2. Ensure DynamoDB Accepts Custom IDs #

The default setup uses auto-generated IDs as the DynamoDB partition key. You’ll need to confirm the resource creation logic respects client-provided IDs:

• Check the Create/Update Handler Lambda: Locate the function handling resource creation (e.g., <your-stack-name>-CreateResourceHandler-<suffix>) and update logic. For PUT requests, the code should pull the custom ID from the request URL (instead of generating a new one) and use it as the partition key in DynamoDB.
• Verify no ID overwrites: Make sure the server doesn’t overwrite the client-provided ID with an auto-generated value during the resource save process.

3. Test the Workflow #

Once your changes are deployed:

• Send a PUT request to create a resource with your custom ID. For example:

  PUT /Patient/my-custom-patient-123
  Content-Type: application/fhir+json
  
  {
    "resourceType": "Patient",
    "name": [{"family": "Smith", "given": ["Jane"]}]
  }
  

• Confirm the resource exists with your custom ID by sending a GET request to /Patient/my-custom-patient-123.
• Validate the CapabilityStatement update by fetching /metadata and checking that rest.resource.updateCreate is true for your target resource types.

Key Notes #

• If you plan to redeploy your CloudFormation stack later, make sure to save your modified Lambda code as part of a custom template or use AWS CodeDeploy to track changes—otherwise, default settings will overwrite your edits.
• Ensure your custom IDs follow FHIR’s format rules: they must be ASCII strings with no spaces, and only use valid URI characters.

内容的提问来源于stack exchange，提问作者Hema Mounika