I am working in medical devices but I am more familiar with the FDA regulations.
What I wonder regarding risk management is how you justify the safety of QT /iOS / Android. In its risk management, the FDA asks you to list of your SW dependencies you are using "off the shelf", and you have to analyze how any failure of any of your dependencies could lead to a failure of your device/application (which is good sense really).
So usually for a simple library it is easy to justify and identify the failure mode, but you look at the OS or big frameworks, it is always harder to find a clear mitigation. Especially at the OS level where potentially any part of memory could be corrupted, your thread not being scheduled, etc.
For example, in your case imagine you have a driver or QT rendering bug that makes the red overlay layer becoming transparent on some HW. That would lead to the user not identifying the correct area and in the end lead to a wrong computation. (I can see on some screenshots you have the percentage displayed so that could be a mitigation in itself)
I am working in the embedded space so generally we have less dependencies and a simpler code base, but we are always reluctant to use off the shelf SW because of the added risk management required. This is counter intuitive for safety but from a regulatory stand point it is sometimes easier to reimplement some features, than using a proven library, because this is less a hassle to justify or maintain.
So was it something raised by the regulator ? Can you give us some example of how you addressed it?
Yes, you can't reasonably control the risk of iOS not working as intended, and Apple will never guarantee it does work, and I'm not sure there is anything anyone can do about that on a consumer device. So there's a risk there.
But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly.
Reduce one big practical risk, but yes introduce one smaller more theoretical risk. And mitigate where reasonably possible.
These aren't official statements on UK app regulation or the NHS's policy on Mersey Burns, though.
I don't disagree with the sentiment but FDA asks you precisely to do this analysis piecewise by what they call "SW units". And for each SW unit, you have to define a severity of hazard that can result from a malfunction of that SW unit. (from minor injury to death or irreparable damage)
Now you can always say you have a single "SW unit" to not have to check the boundaries or interactions, but then all the SW should have been developed with the same methodology/process, and this is not possible when you are using SW coming from an external source. (because you have no idea how it has been developed, and it was likely not targeting medical devices)
As as aside, the recommendation by the FDA is that, prior any mitigation, you have to assume that a SW bug as a 100% chance of happening. (That tells you how confident are the regulators..) But all SW bugs do not necessarily create an hazardous situation.
> But what's the risk of not having the app because you were afraid of the other risk? Doctors getting fluids wrong - and we found in practice they did get them wrong regularly and significantly.
You are allowed to use the benefits risk analysis by the FDA, but you have to demonstrate first there are no other mitigations possible, that you are ALARP (As low as reasonably possible) . You need to explicitly write it in a risk management document to demonstrate you have analyzed that source of hazard.
To be fair, I am not anti regulation, but I think most of these standards are more applicable to SW written in the 80s or 90s when the SW stack where a bit smaller and simpler. And I have hard time to understand how they can be applied in practice in complex SW stacks like iOS. That's why I was interested by your experience, but it seems NHS did not challenge you on the finer implementation details. I understand this is complex because we are talking about 2 different regulation frameworks, so it is not necessarily transferable.
Thanks for chiming in, that is still great to know that is is possible to get something approved on a modern tech stack.
Katahdin sort of lives on in Truffle and TruffleRuby https://chrisseaton.com/truffleruby/ - Truffle is a framework for implementing languages that use partial evaluation of ASTs.
They have several such apps on the website.
Warning: it uses the Scheme programming language.
I would love to see a list of these.
Edit: I guess this is a partial list within the article itself, UK based stuff, though I would be more interested in a US based list:
Winner, Excellence in Mobile Healthcare and overall winner, eHealth Insider Awards, 2013
Highly Commended, Improving Care with Technology, Health Service Journal Awards, 2013
Highly Commended, Innovative Mobile App of the Year, BCS UK IT Industry Awards, 2013
Highly Commended, Best Use of Mobile Technology in Healthcare, eHealth Insider Awards, 2012
Winner, Excellence in Innovation, NHS North West Health Innovation Awards, 2011
It looks like the process has been refined since we did it
I'm not a lawyer or expert on regulation so don't take my word for it.
I have few friends who are pharmacists maybe I could develop something with them. :)
These are short-lived mixes that can't be stored for a long time, so must be prepared on-site.
Bonus if you can plug into an inventory system and get alerts for drug shortages. These can happen pretty regularly, on the order of six or seven times per year.
You'll write a lot of custom code to connect to that medical system API, and often there are surprise and sparsely documented features. That's mostly why you set a high price for it.
We did one of these and quickly saved the hospital millions because we had before and after photos of pharmacy waste generated. They weren't wasting drug mixes for cancelled orders any more when a doctor forgot to call/fax the pharmacy or the patient had been checked out/moved.
Before-hand, they were collecting this information manually with some cobbled together reports. It was nuts.
This isn't turnkey though. You will work for the money trying to sell to hospitals with bloated change management processes.
The great thing about our arrangement with the NHS was we gave them the IP, so they owned the app. They were also the only people using the app (the have an effective monopoly on emergency medicine in the UK), so if something went wrong it's the NHS using an NHS app and they could work it out themselves, and not companies suing companies.
I don't think that kind of simple arrangement would be possible in the US, but I don't know much about US healthcare apart from it isn't nationalised.
FDA protects people from a lot of bad devices, but it also makes it really difficult for people to innovate here. My last job was with a company doing a 510k and we were delayed 6 months while the branch of the FDA that handled ventilators tried to figure out how to work with the branch of the FDA that handled oxygen concentrators.
I don't blame you.
(I work in the medical software industry.)
This shows once again that building successful software depends not just on coding skills or UX design skills, but more on the connections we have. I'm betting most senior developers on HN could have come up with this kind of solution (or perhaps even more advanced ones). Connections determine, through a seemingly random process, our ability to actually find interesting stuff to work on. I just wish it was simpler to find interesting project ideas.
This. Exactly my sentiments. I believe coding could also be one of these easiest things to do. Hardest are - requirements gathering and selling.
The hard part is accepting that this is an ongoing cycle and that you need to find ways to build inertia and continually evolve the value proposition.
The first steam engines were riveted by metal workers who may have felt similarly.
Twitter, Facebook, and Reddit started as relatively basic apps, basically glorified message boards.
This sounds like sarcasm but I'm pretty sure every management consultant would admit that's what they do.
(technical consultants one hopes are actual domain experts, as you say, though I've often found it to be hit or miss even so).
There are a lot of things that might discourage a young hacker and we shouldn’t add “you don’t have a network” to that list.
Maybe a more positive message would be “it shows how building a network along with apps will increase the likelihood of success and certainly the likelihood of making it to the hacker news front page”