• Decrease font size
  • Return font size to normal
  • Increase font size
U.S. Department of Health and Human Services


  • Print
  • Share
  • E-mail
Super Search Devices@FDA
510(k) | DeNovo | Registration & Listing | Adverse Events | Recalls | PMA | HDE | Classification | Standards
CFR Title 21 | Radiation-Emitting Products | X-Ray Assembler | Medsun Reports | CLIA | TPLC

Device Problem Grounding Malfunction (1271)
Patient Problem No Clinical Signs, Symptoms or Conditions (4582)
Event Type  Injury  
Event Description
No adverse event [no adverse event] device malfunction [device malfunction] case narrative: initial information along with a product technical complaint (ptc) received on 12-apr-2021 regarding an unsolicited valid non-serious malfunction case from an other health professional in united states, initiated for my dose coach. Batch number and expiration date were unknown. Global ptc number: (b)(4). This case involves a patient of unknown demographics reported since the healthcare professional (hcp) could not see the data that came from patient application (device malfunction), while using the medical device my dose coach. My dose coach has been identified with a product use issue. It is unknown if the product was stored or used properly. The device was operated by other. The patient's medical history, past medical treatment(s), vaccination(s) and family history were not provided. Concomitant medication was not reported. On (b)(6) 2021 (unknown latency), after the initiation of the suspect device, looking at the patient data file it seems that the app was not syncing observations with the server. There are other requests coming in from the app which were being successfully responded to by the server. This was an indication that the app to server communication works fine. The last successful request to sync an observation was made on (b)(6). App had not made a sync request since that date. The hcp was still able to update or change the plan for the patient (if required) and the dose recommendations and reminders (which did not require any communication with the server) were still working as expected for the patient. There is no notification to the hcp or patient that the app was not syncing observation data. Further investigation shows that the server was receiving observations from other patients, so this problem exists only with patient (b)(6). To reproduce the issue, a care plan was created on the test environment with all the same parameters of this patient. It was sent to an ios test build to investigate further. The test failed to recreate the scenario. All observations logged during the test were synced with the server and were visible in the portal. Root cause - multiple causes were hypothesized and tested to see if they would reproduce the issue. 1. Secure storage key chain. The app was with the wrong storage key chain. This shows a message on the home screen saying that the plan had be deactivated (the default assumption if the app could nt confirm the user or plan online). Restarting with the correct key chain returned the app to normal. 2. Bad request. If the observation request was never sent, it was possible the request itself failed to be constructed. The app was altered to purposefully fail to created the endpoint url. The app would just crash continuously in that case as observations were attempted to be sent. 3. Corrupt database. If there were some issue accessing the data context for each observation in the database, their flag for syncing might reset and never be sent to the server. If this were the case, no events of any kind could be updated and only missed events would appear in the logbook. The root cause was not discovered. Software defect - failed requirement. Statement of safety this issue could result in a delay of therapy, hyperglycemia, or hypoglycemia. The hcp was missing patient data for one patient from (b)(6) 2021 onward and could not track patient compliance. In this situation, the hcp could incorrectly update the patient care plan based on missing data. In this specific situation, there was no patient harm as the hcp/clinical trial staff recognized that the data was missing and contacted the patient and support team. The other patients enrolled were not being impacted by this issue. It appeared isolated to just one user. Current risk mitigations helped prevent a s3 in this scenario, specifically, the clinical staff noted the missing bg readings were listed as unknown and that led them to reach out to the patient. The patient could still use the application and receive the necessary notifications, warnings, and dose recommendations. The dose was being adjusted as expected based on the patients care plan. The data was available on the patient application, but there is a risk of lost data as the data was not being transferred to the back end for the user. On (b)(6) 2021 (reported as this morning), data for this patient only, was not loading into the portal as of friday, (b)(6). Hcp (healthcare professional) called and confirmed with the patient the app seems to be working on their end and they were up to date on entering bg and insulin. On (b)(6) 2021, the patient accidentally entered their bg as an insulin dose. Event assessed as intervention required. No relevant laboratory data was reported. The action taken with the suspect device was not applicable. It was unknown, if the patient received any corrective treatment. The outcome of the event was not applicable. Sample status- not available investigation revealed: 2021-05-04 (b)(6) (analyst name abbreviation) added investigation detail from medtech_us, ptc number-(b)(4), defect management tool-esr-462 investigation details: us ((b)(6)) complaint origin - call center environment-production version affected-v2. 3 frequency of occurrence-seen once conclusion: two weeks after sanofi was notified on the issue, the (b)(6) study coordinator informed sanofi that all of the patient information was now visible in the portal. Completely up to date. No root cause had been identified for this issue so far and thus the case would be moved to the backlog for further monitoring. Final investigation complete date: 04-may-2021. Summarized conclusion for this case was; related to product. Corresponding fields and narrative was updated accordingly.
Search Alerts/Recalls

  New Search  |  Submit an Adverse Event Report

Type of DeviceSOFTWARE
Manufacturer (Section D)
d-65926 industriepark hochst -
building h500
frankfurt am main 65926
GM 65926
Manufacturer (Section G)
270 albany street
building h500
cambridge 02139
Manufacturer Contact
heather schiappacasse
55 corporate drive, ms 55b-220
bridgewater 08807
MDR Report Key11780706
MDR Text Key249222986
Report Number3010770778-2021-00005
Device Sequence Number1
Product Code NDC
Combination Product (y/n)N
Number of Events Reported1
Summary Report (Y/N)N
Report Source Manufacturer
Source Type health professional
Type of Report Initial,Followup
Report Date 06/28/2021
1 Device was Involved in the Event
1 Patient was Involved in the Event
Date FDA Received05/05/2021
Is this an Adverse Event Report? Yes
Is this a Product Problem Report? No
Device Operator
Was Device Available for Evaluation? No Answer Provided
Was the Report Sent to FDA?
Event Location No Information
Was Device Evaluated by Manufacturer? No Answer Provided
Is the Device Single Use? No
Is This a Reprocessed and Reused Single-Use Device? No
Type of Device Usage

Patient Treatment Data
Date Received: 05/05/2021 Patient Sequence Number: 1