Data Management and Transfer
The following sections describe the data exchange from Smile CDR to Amazon HealthLake through this module.
Authentication and authorization between SmileCDR and Amazon Healthlake uses AWS Security Token Service (AWS STS) for customer’s IAM role that enables Smile CDR, on behalf of the customer, to request for temporary, limited-privilege credentials that will be used to invoke HealthLake APIs. These temporary credentials consist of an access key ID, a secret access key and a security token. The duration of the temporary credentials is based on the maximum session duration configured on the Customer’s IAM user account.
The diagram below illustrates the sequence flow of getting temporary credentials to be able to send a request to HealthLake.
Data transfer between Smile CDR and Amazon HealthLake only supports one-way flow, that is from Smile CDR to HealthLake with the following considerations:
Smile CDR supports versioned resources but Amazon HealthLake does not. Smile CDR will store the versioned history of all resources in its own storage and transfer only the updates for a resource that is of the latest version with the latest lastUpdated date. This is the reason why the extension, Delivering Latest Version, needs to be included and set to true in the subscription.
Historical data could be data dated prior to enabling the subscription or data that have already been indexed in Smile CDR data store and need to be reprocessed. Historical data transfer to Amazon HealthLake will be performed by manually triggering the subscription.
To trigger the subscription, submit a POST request to Smile CDR's $trigger-subscription operation endpoint:
http://<hostname>/Subscription/endpoint-awshealthlake-out/$trigger-subscription
, which triggers the resource for the subscription that is specific to Amazon HealthLake.
Manually triggering the subscription based on search criteria can only be done on indexed resources, which are resources whose corresponding data fields have been defined in the search parameters for the system to set them as key in Smile CDR FHIR repository as and when they are created or updated so that they can be used for searching. If the subscription's intended search criteria is already defined as a SearchParameter resource, any indexed resources that meet the criteria will be transferred once the subscription request has been submitted. Otherwise, manual reindexing of the data in the FHIR repository is required prior to submitting the subscription request.
HealthLake troubleshooting logs will be logged to the AWS HealthLake Export Troubleshooting Log when it is enabled.
HealthLake Subscription activities will be logged to the Subscription Troubleshooting Log when it is enabled.
Error responses from Amazon HealthLake will be checked, logged with useful troubleshooting information and handled gracefully.
With data validation and data version management in Smile CDR, potential errors that could be encountered between Smile CDR and Amazon HealthLake are unsupported resource types. When transmission for an unsupported resource type is attempted, Amazon HealthLake will send an error response with HTTP status code 400 and issue code “not supported”:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "ResourceType <resource type> is not supported."
}
]
}
Failed requests, other than the unsupported ResourceType, as shown above, will be retried until accepted. This, however, needs to be configured under Message Broker Failure Management indicating the number of retries, the time delay between attempts in milliseconds, and the retry strategy. After reaching the maximum number of retries, the message is published to the failed channel. If a customer requires guaranteed delivery after reaching the maximum number of retries, a dead letter consumer needs to be built. If the retry mechanism is not configured, then retry will not happen.
For general troubleshooting of the AWS HealthLake Export module, enable the AWS HealthLake Export Troubleshooting Log.
Problem | Possible Reason | Solution |
---|---|---|
No messages is going to the delivery queue | Subscription resource may not be active |
|
Messages in the delivery queue are not being processed | Connector module may be stopped |
|
Unsupported resource type (HTTP 400) | Resource is not supported by Amazon HealthLake |
|