6 ms·
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
by alexbanks 6y ago
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.
- kalleth 6y agoI 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.
- deleted 6y ago[deleted]
- alexbanks 6y agoIt feels like you've lost the forest for the trees.
- im_down_w_otp 6y agoI 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.
- alexbanks 6y ago> Many components for making safety-critical systems are commonly available in non-certified variants. Can you elaborate on this?
- im_down_w_otp 6y agoSure. 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?
- alexbanks 6y agoI 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.
- im_down_w_otp 6y agoI'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.
- robocat 6y agoI 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 https://data.worldbank.org/indicator/SH.XPD.CHEX.PC.CD
- alexbanks 6y agoYeah. The urgency vs. resources I think is getting lost.