Health data sharing


Health data sharing service allows discrete health data synchronization between patient PHR and EMR.
Data sharing service applies to patient that were created by the hospital and provided the data sharing consent.

Data Flow


In the Health data sharing flow, we offer two distinct options to facilitate seamless data retrieval from the S3 bucket:

  • Option 1: involves downloading files using a Secure Token Service (STS) Authorization token, providing a robust and secure method for accessing the data.
  • Option 2: offers the use of pre-signed URLs, which streamlines the process by granting temporary access links to the desired files.

These two options cater to different needs and security requirements, allowing flexibility in how health data is accessed and integrated into your system.

Option 1: Using a Secure Token Service (STS) Authorization token


EMR-output interfaces


  1. Every time new health data is shared by the patient, RDC Data integration pipeline will make the new data available in a S3 bucket.

  2. Roche DC calls EMR middleware notification API sharing that a new file is available. For more details related with notification interface please read the following File availability notification

  3. EMR Middleware connects to Roche DC API to get Authorization token. For more details related with Authorization interface please read the following section Get S3 Temporary Token

  4. EMR Middleware retrieves the FHIR bundle from S3 bucket. For more details related with File retrieve interface please read the following File retrieve

  5. EMR Middleware transforms FHIR file bundle into the EMR message format.

  6. If the transaction is successful, Middleware sends an acknowledgment message to Roche DC. For more details related with Notification receiver service please read the following Notification ACK Service. Otherwise, Roche DC will retry to send the notification again 3 times waiting 30 minutes between each retry (Step number 2)


Option 2: Using pre-signed URLs


EMR-output interfaces-PRESIGNED


  1. Every time new health data is shared by the patient, RDC Data integration pipeline will make the new data available in a S3 bucket.

  2. Roche DC calls EMR middleware notification API sharing that a new file is available. For more details related with notification interface please read the following File availability notification

  3. EMR Middleware retrieves the FHIR bundle from the S3 bucket using the pre-signed URL received from Roche DC. For more details related with File retrieve interface please read the following File retrieve

  4. EMR Middleware transforms FHIR file bundle into the EMR message format.

  5. If the transaction is successful, Middleware sends an acknowledgment message to Roche DC. For more details related with Notification receiver service please read the following Notification ACK Service. Otherwise, Roche DC will retry to send the notification again 3 times waiting 30 minutes between each retry (Step number 2)


Health data types

This service allows the EMR to synchronize the following health data types shared by the patient

Entity Main data points FHIR resources
BG observation
  • BG observation
    		•
  • BG observation
    		•
    Nutritional Values Observation
  • Carbs Intake
  • Recommended carbs
  • Fat intake
  • Calories consumed
  • Meal intake
    		•
  • Carbohydrate Observation
  • Carbohydrate Advice Observation
    		•
    Medication Administration
  • Insulin dose (Short acting (bolus), long acting (basal), mixed etc.)
    		•
  • Medication Adminstration
    		•
    Device
  • Status
  • Type
  • Model
  • Version
  • Manufacturer
    		•
  • Device
    		•

    Data volumes

    Only the Delta will be provided, meaning, only new Health data values added from last synchronization.
    Depends on the number of patients created by EMR, for each patient expectation is:

  • 3 FHIR bundle files per day.



    Frequency

    Near real time - from the point the user uploads data it may take up to 5 sec to synchronize with EMR.


    Note to the developer

    Notification service (step number 2) may send duplicated notification messages. In some scenarios the percentage of duplicated notifications can be up to 2%