Comment by alexbanks | Hacker News Reader

Comment by alexbanks | Hacker News Reader

Parent Full thread

It's as though no one commenting negatively actually read this article.

> We created this software on a request from healthcare staffs. It is not a commercial application. Even with this system, we strongly suggest doctors to visit their patients, take real measurements. As this software was developed fast due to prevailing pandemic situation, we released it with the most urgent feature monitoring. We tested this for long run, with multiple devices as well. So far it worked out well. It does not indicate this is perfect, we are working on improvements and fixing bugs until its very stable. Thus we have adviced doctors to use this with CAUTION

It's almost as if the options were either "Do nothing" or "Do something", and they chose to "Do something." This does not sound at all like someone just decided to build their own version of a software they already had access to. It sounds very much like they could either make this software or try to get along without it.

I think people just don’t understand the budget difference between countries - Sri Lanka has two orders of magnitude less spending on healthcare per person than the US (Sri Lanka: 160 per person, US: 10200 per person, 2017 [1]).

2 orders of magnitude less means there is a lot of making do with what you have.

[1] https://data.worldbank.org/indicator/SH.XPD.CHEX.PC.CD

Yeah. The urgency vs. resources I think is getting lost.

I did read the article.

I understand the desire to "do something", but the certification and testing process for something like this is how you find out if this actually improves patient outcomes or not. Sometimes "doing nothing" in a certain area gives a better outcome.

I'm glad they're advising doctors to use caution.

I have some architectural concerns about how it's built (a browser's javascript engine is not reliable enough to be used as a safety-critical alerting engine!), but I can see how it's attractive.

It feels like you've lost the forest for the trees.

I expect there are a lot of viable and useful shades of grey in between official standards certified commercial products and from-scratch one-off Go/JavaScript.

Even if they're going to roll their own rapid uncertified solution, they could have still done so with more reliable and proven technology than what they appear to have chosen to assemble this system.

Many components for making safety-critical systems are commonly available in non-certified variants. These could be used to assemble a viable system, but would of course lack the process, practice, and evidence for certification that would normally be required. But, at least the technology choices would have, at a minimum, "proven in use" benefits if one is going to otherwise punt on the procedure & practice rigor that is typically applied.

Given that most of the components to build a safety-critical system are commonly available, or their non-qualified kin are, it doesn't make much sense to me why if you were tasked with putting this together quickly and cheaply, but were still taking serious the safety-critical nature of it, why you would cobble it together with the stack chosen here.

Even if the choice is "Do something" or "Do nothing", there's more than one way to "Do something", and this seems like a particularly odd way to have gone about it all things considered.

> Many components for making safety-critical systems are commonly available in non-certified variants.

Can you elaborate on this?

Sure. You can get application boards with ARM Cortex-R or Infineon AURIX MCUs, there are numerous free and/or open source RTOSes (some which have commercial variants where you pay for the certification evidence), there are certified compiler toolchains that are forked from specific versions of GCC, there are pre-existing safety-critical systems which already incorporated various open source SOUP (software of unknown provenance) that you could use knowing someone-somewhere made a successful certification claim for it (proven in use, etc.), there are approved commonly available languages (C, C++, Java, Ada, etc.) that are spelled out for use at different SILs in IEC 61508, and so on.

That's not to say that the use of any of these things would necessarily result in a qualifiable system (it wouldn't), but you'd at least be in the same general vicinity of what is usually used/required to build such a system.

But, let's consider even the simplest aspect specific to the system this article is about. There are already multiple open source HL7 parsers that have been in-use, tested, and maintained for quite some time. What was the point of reinventing that wheel here, and if one was going to reinvent that wheel, then why not in a way that improves assurances rather than reduces them?

I guess I side with the OP a lot more than you because I suspect none of the things you listed would've been obtainable/actionable in even close to as much time. Resources (knowledge, experience, money) are not infinite, nor are they irrelevant.

I'm not sure I understand what you mean. Which things I listed are difficult to come by? With the exception of the SBCs/application-boards (which may need to be ordered like any other piece of hardware), the rest of it is just as downloadable and available as anything else used in the OP.

But, even if one concedes that the technology stack they chose was somehow the only one available to them, then what level of rigor should be applied to adapting a stack that would typically be considered unfit for this task under normal circumstances? I couldn't find any mention of their testing methodologies.

Knowledge/experience/expertise are not readily available. And I would find it hard to believe that a person would be able to churn out a piece of technology worth using, first try, with tools they've never used before. So in terms of your "hard to come by" question, I would say "A depth of experience at a moments notice" as a response.

"Crisis" seems to be a scenario that your methods might not work well in. Groups of people were at risk of death. Would implementing a solution increase their chances of death? If you're continuing to monitor patients as you normally would without this tech, isn't worst case just "doesn't improve"? And isn't best case "We caught more problems than we would by normal monitoring" ?

I can't really tell what you're advocating here. Using both unproven/unfit technologies and foregoing safety processes is worthwhile risk because the people doing it also lack the expertise to do otherwise?

The "worst case" that can come out of false positives & false negatives in safety-critical conditions has a bunch of dimensions depending on an enormous number of environmental and contextual conditions. There's no PFMEA nor DFMEA supplied in the OP to indicate how one should consider their choices.

Best of luck.

Reply on news.ycombinator.com