What kind of a complete idiot is still writing their own numeric parsers? Okay, now I’ll sheepishly hold my hand up and say “me”... because I’ve had to work with fixed-precision maths on microcontrollers. And that’s what’s happened here, I think. The device most likely uses only integer maths, so the “decimals” are possibly held as millis (i.e., three digits of decimal precision).
That is, however, not an excuse for this bug - you’d have to go out of your way to not automatically handle what happens when you get to the decimal point, regardless of whether there’s a digit in front of it or not. The only way I can think of is that the values are always less than ten, so someone is padding the end with zeros, doing replace(".","") on the string, then passing the result to whatever passes for atoi() on their platform and using that as a millis value. That’s so much fucking harder, more longwinded and more error-prone than actually writing a proper conversion function, so I suspect it’s exactly what happened.
But even with such a bodge of a solution, the most basic of unit testing should have found this; let alone quality assurance testing. That’s where I get angry: I don’t know how they’ve managed to skate around the approval process for medical devices, but this is a clear safety-of-life issue and one that should have been found with even the most rudimentary of testing.
The manufacturer should at least be hit with a massive fine, if not a charge of criminal negligence. Agile development is fine when your fuckups misalign some text on a form; when they put people at risk of potentially fatal hypoglycaemia, you need to take a bit more fucking care and think before you hit “deploy”.