Posting Resources with client specific ids

[hemag24]

We are working on FHIR(Fast Healthcare Interoperability Resources). We have followed “FHIR works on AWS” and deployed the Cloud Formation template given by AWS in our AWS environment. Following is the template that we have deployed.

https://docs.aws.amazon.com/solutions/latest/fhir-works-on-aws/aws-cloudformation-template.html

Requirement : we want to maintain client specific/customized ids as primary key in the server. Problem : server not allowing us to override or maintain client specific (customized) ids as primary key. Infact, in the runtime, it is generating its own ids and ignoring the ids provided by us. Could you please let us know if there is any way to post the FHIR resource with client specific ids into FHIR server(Dynamo DB).

[maghirardelli]

Thanks for your message @hemag24 ! We're going to look into this and get back to you!

[ssvegaraju]

Hi, just to provide some additional context: We follow the FHIR guidelines as specified here for creating resources, and ignore any id fields submitted with a resource. However, if I am correctly understanding your use case, I would suggest exploring our Multi-Tenancy feature to separate ids per client. This would essentially allow you to prefix the ids for resources with a tenantId , logically partitioning the data in the FHIR Server. Hope this helps!

[hemag24]

Hi @ssvegaraju, Thanks for the reply, as mentioned we have gone through the concept of the multi-tenancy feature, but we found that it is to serve as multiple FHIR servers for different tenants but, we are not sure that it is going to suffice our requirement of creating client-specific resource ids. According to FHIR, we have observed that by using "PUT" call(https://hl7.org/fhir/http.html#upsert), we might be able to generate the resource with customized ids as primary keys, but there is a precondition stating that "CapabilityStatement.rest.resource.updateCreate" Flag to be updated as "True". Is there any way to update the "CapabilityStatement.rest.resource.updateCreate" flag through AWS console or by any manual process??

[ssvegaraju]

Hi @hemag24, I dug a little bit deeper, and it seems as though we do support update as create here: https://github.com/awslabs/fhir-works-on-aws-persistence-ddb/blob/bf556828f74c0ccfd33e597c9dd48927eb059b5e/src/dataServices/dynamoDbDataService.ts#L194. You can add support for this by changing the boolean in the constructor here: https://github.com/awslabs/fhir-works-on-aws-deployment/blob/6bfd49b1cbf15bd6591e8d37eec970d6a7c18fb4/src/config.ts#L38 and redeploying, as that will enable support in the persistence package linked to the deployment. Please let me know if those instructions aren't clear, and I'm happy to help!

[hemag24]

We have downloaded the code from lambda function: "fhir-service-dev-fhirServer", (this lambda function is the part of the reflected stack after the deployment of the template provided by FHIR works on AWS), but in the downloaded code we didn't found "src/config.ts" file instead there is "src/index.js" file, hence we have modified the code as mentioned above in "src/index.js" and redeployed it to the same function in our stack, yet we are unable to set client-defined ids as primary keys even after updating the code. Let us know if there is any other way?

[ssvegaraju]

Could I ask what modifications were made? I believe that index.ts uses the fhirConfig as described in config.ts. That is, it uses the persistence layer defined in the config file. It may work to modify the index.ts as you mentioned to await the getFhirConfig() method and manually edit the persistence property to be a new instance of the DynamoDbDataService (an export of the persistence package), but this is untested and may break other parts of the stack. I would suggest redeploying the stack as a whole after updating the config.ts, if possible. This should not change any existing data in the deployment.

[hemag24]

Do you want us to fork the "fhir-works-on-aws-deployment" project, update the code and update the template accordingly to target the forked repository? If yes, could you please let us know how to change the code target in AWS FHIR template.

[ssvegaraju]

It depends on how your deployment process for the stack is setup. If following the normal instructions for setup found here, it is just a matter of changing the false to true in this line of code: https://github.com/awslabs/fhir-works-on-aws-deployment/blob/6bfd49b1cbf15bd6591e8d37eec970d6a7c18fb4/src/config.ts#L38, and then running yarn build to compile the changes and serverless deploy with any additional parameters used for deployment.

[vcareit]

@hemag24 I think what you are looking for is that resources created - e.g. patient should have ids created by you and not auto created. You can update the code here : file name ( DynamoDbDataService.js or .ts) There is a method which creates resources - If you pass your own id then you can change this method as mentioned below. async createResource(request) { this.assertValidTenancyMode(request.tenantId); const { resourceType, resource, tenantId } = request; //return this.createResourceWithId(resourceType, resource, (0, v4_1.default)(), tenantId); return this.createResourceWithId(resourceType, resource, request.id, tenantId); }

Then you will have to update the logic here as well.

async createResourceWithId(resourceType, resource, resourceId, tenantId) { const regex = new RegExp('^[a-zA-Z0-9-.]{1,64}$'); if (!regex.test(resourceId)) { throw new fhir_works_on_aws_interface_1.InvalidResourceError(Resource creation failed, id ${resourceId} is not valid); } const vid = 1; let resourceClone = (0, fhir_works_on_aws_interface_1.clone)(resource); resourceClone.resourceType = resourceType; const param = dynamoDbParamBuilder_1.default.buildPutAvailableItemParam(resourceClone, resourceId, vid, false, tenantId); try { await this.dynamoDb.putItem(param).promise(); }

[hemag24]

Thanks a lot for your suggestions @ssvegaraju and @Bingjiling, we have successfully created resources with client-specific ids in FHIR store.