FHIR bundle example for Edited BG Values (Former approach for BG Integration)

NOTE: This is the former approach that was used in the basic BG Integration of mySugr. For the latest approach please refer the final approaches folder    

   

Use Case: a Blood Glucose value (BG) previously sent has been edited manually on MySugr

Pre-conditions  

  • The patient has been performed all required actions on MySugr to get BG data from a glucometer (GM) device or manually entered those BG values on the app. We can call this BG_1 and TS_1 values
  • On ST_1 point of time, these first BG_1 and TS_1 values have been successfully uploaded to HDS and RDCP and they can be visualized correctly on RDCP (as GM device measurements or manual...this is outside the scope of this use case).

Steps

  • The patient edit manually the blood glucose values (BG_2) and/or the effective time (TS_2) of one of a previously sent value BG_1/TS_1.
  • On ST_2 point of time, the new values have been properly stored on the system.
  • The patient edit manually again the blood glucose values (BG_3) and/or the effective time (TS_3) of one of a previously sent value BG_2/TS_2.
  • On ST_3 point of time, the new values have been properly stored on the system.

**FHIR Modeling (use case 1 step-by-step data table)

Command 'link' could not render: File not found for 'subject=EditedValuesApproachold'

Command 'json' could not render: File not found for 'subject=example-bgip-mysugr-edited-values'

EDITED values

  • MySugr maintains a unique identifier for ALL the editable resources. NOTE: This identifier is unique for the resource. If a log entry has more than one data point resulting in more than 1 resource, each resource should be identified uniquely.

  • If there is any update on any entry, mySugr shall send the updated resource alone (no history) carrying

    • the same identifier with which it was previously ingested
    • the registeredTimestamp holding the timestamp of the update

  • RDCP shall maintain the history so there will be no need to send the history through ACSPIX

More details at - https://confluence.rochedc.accentureanalytics.com/x/wwb4Aw

This section contains a generalized approach for each resource type. If a particular data point is editable in mySugr, one needs to follow the approach based on the FHIR resource type used for that data point. For instance: meal-carbohydrates, exercise-duration, blood-glucose etc are observation resources and therefore follow the approach given under "Observation resource" category.

Deleted Values approach

The DELETE operation will be performed as a status change on the resource rather than a DELETE operation. This will increase system traceability because a DELETED FHIR resource is not searchable.

  • MySugr maintains a unique identifier for ALL the deletable resources NOTE: This identifier is unique for the resource. If a log entry has more than one data point resulting in more than 1 resource, each resource should be identified uniquely.
  • If any entry is deleted, mySugr shall send the deleted resource alone (no history) carrying
    • the same identifier with which it was previously ingested
    • the registeredTimestamp holding the timestamp of the delete
    • updated status indicating that it has been deleted (this depends on the resource)
  • RDCP shall maintain the history so there will be no need to send the history through ACSPIX

More details at - https://confluence.rochedc.accentureanalytics.com/x/wwb4Aw

This section contains a generalized approach for each resource type. If a particular data point is deletable in mySugr, one needs to follow the approach based on the FHIR resource type used for that data point. For instance: meal-carbohydrates, exercise-duration, blood-glucose etc are observation resources and therefore follow the approach given under "Observation resource" category.

IMPORTANT: If a data point is modelled as a separate resource then the above aporach applies (For example: BG, body-weight etc.). However, the following data points are not modelled as a separate resource but as a a part/child of another data point. So, the deleted approach in these cases are different:

mySugr data point FHIR modelling Deleted approach
exercise_description_text activity-observation (observation.category=257733005; observation.code=280147009) This observation resource is a parent to the child observations exercise-duration, steps and exercise-intensity. So, if a user deleted the exercise_description_text while 1 or more of the child entries still exist in the logentry, the parent resource should not be cancelled because it holds the references to the child observation(s). Only the valueString should be made blank in the parent resource.
meal_description_text; meal_image(s); logentry_nutritional_constituents diet-intake-observation (observation.category=364395008; observation.code=246251008) These 3 datapoints together are modelled in a single Observation resource. So if any one of the entry is deleted the entire resource should not be cancelled, but the resource should be "edited" by removing/updating the respective item.
bolus_correction_insulin_units; bolus_food_insulin_units MedicationAdministration (medicationCodeableConcept.code=411531001) These data points are modelled as a part of the MedicationAdministration resource for the pen_bolus_insulin_units. So if any one of these are deleted the entire resource should not be cancelled, but the resource should be "edited" by removing/updating the respective item.

NOTE: The approach for deleting GOAL resource is not outlined because even if the user has not mentioned a target range (for example, weight), then the default values are considered. So there never is a scenario when this setting can be deleted completely. The same applies to the CAREPLAN resource which holds the settings like therapy type and references to the GOAL resources that contain the target ranges which have a default value and cannot be deleted.