Is it possibly just the case that many of these systems were never intended for the mass selection of patient groups?
This has absolutely nothing to do with it. Even if this software was only used in scope of retaining patient information when the patient visits their GP, the calculated BMI would've been incorrect.
The issue with mass harvesting of data is that people don't invest any time in looking at specific entries anymore, and therefore they don't see obviously wrong data. In comparison, that doctor who looks at the patient info for the patient who is in front of them will notice that 28000 number.
Is this just a flaw in their particular software?
If the software was never required to put boundaries on data input, then not having boundaries isn't a flaw in the software. At best, it's a flaw in the requirements.
The 28000 also wasn't a bad calculation either. It was a correct calculation based on the data that was input. You cannot blame a calculation for the correctness of its input, or what I like to refer to as "shit goes in, shit comes out".
So you want to limit the height input then (and weight, but let's focus on height for now). What should the minimum limit be?
Well, the shortest person recorded is about 62 cm. But what about when that record is broken? Because most records tend to get broken once in a while.
Also, babies are generally 50cm, so maybe that's where the limit should be. But what about premature babies? Even only accounting for the viable range of premature births who have a reasonable chance at survival (which is 24 weeks), they can be as small as 22cm.
So if you want to account for all humans, we could argue that 22cm is a reasonable minimum boundary.
You should already notice that 22cm is still close to the 6.2cm figure we started with.
I reverse engineered your example. For a 28000 BMI and a height of 6.2cm, you'd need to weigh about 108kg. But even if you disallow this height, yet still allow a height of 22cm, that still leads to a BMI of 2231.4.
The BMI data is still nonsensical, even though both input values are within their individual normal ranges. We established that a height of 22cm is possible, and a weight of 108kg is also realistic.
Your question is built on the assumption that such data validation would be trivial to implement without fault. The above calculation shows you that this assumption is incorrect.
Or are there valid reasons that you might not want to introduce input ranges and sanity checks to biometric data?
While people's height and weight isn't going to change overnight, it's generally inadvisable to add more restrictive validation to data than what was asked, based on nothing more than what a developer thinks might be a possible reasonable restriction.
For example, my country's license plates used to be of the format AAA-000
(and initially, vanity plates weren't legal). Should software have only allowed this format?
Well, it seems like you would have forced that. But when those license plates ran out, we started using 000-AAA
. And when that ran out, we've started using 0-AAA-000
.
If you had written those validation checks, you would've had to change and redeploy your application every time the format changed. And this is a relevant topic, because that is precisely what happened in my country. They had to manually update thousands of devices (speed cams, parking lot cameras, police vehicle cameras, ...) because they were unable to register these new license plates.
Had they not bothered with this format validation, they wouldn't have had to update their software. Given that in this case it was embedded software on devices, having to redeploy is a cumbersome and expensive task.
Similar issues could be encountered with:
- Landlines are 9 digits here, whereas cell phones are 10 digits
- Postal codes here are 4 digits, but they've introduced 5 digit codes recently
- House numbers are numeric, but there is a fringe case whereby a property that is split into two properties will get a "A/B/C/..." suffix. So what once was number 1 becomes numbers 1 and 1A. This is not the same as a box (i.e. number 1 box A). For example, we live at address Redacted Street 14A, but the building next door (Redacted street 14) is an apartment building, and labels their apartments A/B/C/... 14A is my house number. 14 box A is the nextdoor apartment on the first floor. You can imagine my frustration whenever I fill out a form and notice that the developers needlessly decided to enforce a numeric format in the number textbox.
Colour me only mildly concerned, given the AI-based future of medical decision making!
You're putting the cart before the horse here. Even if the patient info registration tool allows for inputting nonsensical data, that doesn't inherently mean that the interpretor of this data must blindly believe anything it is told.
If you only could implement one validation, you'd put the validation on the AI, not on the data collection tool. If you blame any mistakes your AI makes on the input data rather than the AI, then your AI isn't an AI, it's just an algorithm.