How secure is this method?

You could use a version of this in a real setting, although I think you'd need to make some significant modifications if it were to handle real patient data in a real environment.

A few issues I see are:

1) Quality control. If your app has bugs and people don't get their scan, or perhaps worse, they get the wrong scan, that's obviously a potentially harmful outcome. Clinically deployed apps have vigorous quality control measures in place. 2) Authentication. At the moment, the request.php script will respond to HTTP requests sent from essentially anywhere. As a result, a malicious third party could send a harmful request. In the real world, ideally you'd be able to authenticate the sender with a username and password (depending on where you deployed your application). 3) Data security. While this app only stores a minority of patient information (the last .pdf that was generated), it likely doesn't meet your jurisdiction's criteria for storing health information (and relying on email in the pipeline is also an issue in this regard).

Naturally I find this all a bit disappointing as an optimistic health-tech innovator, but it wouldn't be right to tell you otherwise. Our health IT infrastructure just hasn't caught up.

I note that you can dramatically lower the threshold for deploying a tool like this by modifying it not to handle patient data, and instead to automate some payroll/administration process, somehow repurpose it for medical education etc. The use-cases can have as much or more utility and benefit to patient care than genuine clinical tools can. Alternatively, you and your health service may come to some level of agreement about risk and be willing to compromise on a modified deployment in some way.

I hope that helps Ryan. Happy to answer any further questions you may have.

joshcase / code-blue-auto-imaging

How secure is this method? #2