Smile CDR v2024.08.PRE
On this page:
   48.1    Getting Started
  • Amazon HealthLake Outbound REST Connector
  • 48.0 Introduction
  • 48.1 Getting Started
  • 48.2 Data Management and Transfer
    •    Table of Contents

    Data Management and Transfer

    48.2.1Data Management and Transfer
    Trial
    Premium

     

    The following sections describe the data exchange from Smile CDR to Amazon HealthLake through this module.

    48.2.2Security
    Trial
    Premium

     

    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.

    Amazon HealthLake Request Authentication Sequence Diagram

    48.2.3Data Access and Transfer
    Trial
    Premium

     

    Data transfer between Smile CDR and Amazon HealthLake only supports one-way flow, that is from Smile CDR to HealthLake with the following considerations:

    • All data from the end-user which can come in a number of different data formats is ingested through Smile CDR and converted into FHIR as necessary.
    • All data transfer from Smile CDR to HealthLake is through an HTTP client in FHIR R4 format and happens near real-time.
    • GET operation (reading/searching) for a resource is done directly on Smile CDR. This means that all requests with GET operation will not be forwarded to HealthLake.
    • All new and updated resources are transferred to Amazon HealthLake using the PUT operation.
    • DELETE operation is supported - if a resource is deleted in Smile CDR, a delete operation for a resource is sent to HealthLake.
    • Not all resource types are currently supported by Amazon HealthLake. Smile CDR supports all resource types and will attempt to transmit to Amazon HealthLake. Where a resource type is not supported by HealthLake, Smile CDR will handle this gracefully by logging the occurrence without blocking the transmission of other data. In the event that Amazon HealthLake expands the supported resource types, there will be no change on Smile CDR. For the list of Amazon HealthLake’s supported resource types, please refer to Amazon HealthLake’s documentation.

    48.2.4Data Version Management
    Trial
    Premium

     

    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.

    48.2.5Historical Data Transfer
    Trial
    Premium

     

    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.

    48.2.6Logging
    Trial
    Premium

     

    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.

    48.2.7Error Handling
    Trial
    Premium

     

    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.

    48.2.8Troubleshooting
    Trial
    Premium

     

    For general troubleshooting of the AWS HealthLake Export module, enable the AWS HealthLake Export Troubleshooting Log.

    ProblemPossible ReasonSolution
    No messages is going to the delivery queueSubscription resource may not be active
    Messages in the delivery queue are not being processedConnector module may be stopped
    Unsupported resource type (HTTP 400)Resource is not supported by Amazon HealthLake
    • No action required. It is a known error which is handled gracefully by the error handler.
       48.1    Getting Started
  • Amazon HealthLake Outbound REST Connector
  • 48.0 Introduction
  • 48.1 Getting Started
  • 48.2 Data Management and Transfer