What archetecture to choose.

[Rainbow6]

Hi,

from my very German/European point of view I would start to develop the architecture from the data upwards.

First thing to think about - someone else already pointed out - is: Who owns the data? And the answer is simple - it’s personal data and only the patient owns it. Not the doctors, not the application provider.

Second thing - do you have a permanent Internet connection? Or can it be disrupted? Has to doctor to work, if there is no connection?

A central data store is always easier to maintain and to secure as a distributed one. And 2-way synchronization/replication is a task best left off to pros and not programmed yourself.

Last point from me - REST is NOT always the best solution - dealing with highly sensible data I always would prefer a VPN connection and then you can use every access method you like.

Just my 2cents.
Regards,
Daniel

[PascalDragon]

Are you sure you want to do a REST server with the tools available under Lazarus?
I'm probably saying this because I've never used mORMot, but that's only the ORM.
What are you planning on using to do the whole Web Framework thing?

mORMot is - despite its name - not only an ORM. It provides various facilities for client/server communication as well. And in the Lazarus field its one of the choices with the broadest coverage.

In general, I'm all for the go-for-it approach, learn-on-the-fly. But medical systems are not the place to grit your teeth. There's too much at stake, including peoples lives.

I however agree with what Trenatos and the others said. First check the legal implications of you writing and providing such a software.

[BSaidus]

Thanks you all for your clarification.
Concerning the laws here in Algeria ( north Africa ), frankly I do not know anything.
This idea comes to me because we really suffer ( mostly old people ) from, NO centralized data , doctors do not use software for best following the health of patients .... ( so many problems ).
Here, some one can visit doctor A today, doctor B next week, and Doctor B do not know what treatment that Doctor A gives so there is a risk that the 2 treatment are similar.
Adding to all that, We do not have a good internet connection ( at every moment you can experiment disconnection ) this is why I must keep a cache in local.

This initiative is personal to try help patients & doctor and it will be opensource.
YES !! I totally agree with legals and law ( that I do not know for the moment ).


For connecting to remote server I thinked about using VPN. (but what VPN server supporting for exemple 10K doctors ????  )


I do not know ... I'm lost.

Thank you for your advices .

[PierceNg]

For connecting to remote server I thinked about using VPN. (but what VPN server supporting for exemple 10K doctors ????  )

Nah. In your scenario VPN doesn't add much security, but will add to your problems. Put another way, don't let adding a VPN give a false sense of security. If you cross the legal hurdles and proceed to build this thing, treat the architecture the same whether there is or isn't VPN.

[DonAlfredo]

For connecting to remote server I thinked about using VPN.

Its easy with the mORMot.
It uses REST. Over https. Using nginx with a (free) certificate.
Will be very safe.

[BSaidus]

For connecting to remote server I thinked about using VPN.

Its easy with the mORMot.
It uses REST. Over https. Using nginx with a (free) certificate.
Will be very safe.

Do you mean by using nginx, creating web services with mormot ??

[DonAlfredo]

The mORMot will [automagically] create webservices for you. You get them more or less for free !
However, that's not what I meant.
To make the communication between client and server safe, you might use https.
To prevent a lot of mistakes and configuration problems, the most easy way to do this is to use a kind of proxy. Nginx will be your https frontend (and also load-balancer). And will redirect all https traffic on your server to a standard http port on your server itself (localhost).
E.g. from 443 to 80. Or from 8443 to 8080.
So, nginx listens on 8443 (https,0.0.0.0) and redirects traffic to 8080 (http,localhost,mormot). Easy !

[BSaidus]

The mORMot will [automagically] create webservices for you. You get them more or less for free !
However, that's not what I meant.
To make the communication between client and server safe, you might use https.
To prevent a lot of mistakes and configuration problems, the most easy way to do this is to use a kind of proxy. Nginx will be your https frontend (and also load-balancer). And will redirect all https traffic on your server to a standard http port on your server itself (localhost).
E.g. from 443 to 80. Or from 8443 to 8080.
So, nginx listens on 8443 (https,0.0.0.0) and redirects traffic to 8080 (http,localhost,mormot). Easy !

Great, I will explore this way and I'll keep in touch

[ASBzone]

In general, I'm all for the go-for-it approach, learn-on-the-fly. But medical systems are not the place to grit your teeth. There's too much at stake, including peoples lives.

I however agree with what Trenatos and the others said. First check the legal implications of you writing and providing such a software.

While many people have weighed in on this point already, it is important enough that more caution is required here.   Writing an application and maintaining a system that will handle ePHI (electronic protected health info) securely, is no joke.   Development is a hobby for me, but cybersecurity and compliance is how I pay bills.

In terms of architecture, you need to include security in the following areas at a minimum:
-- Authentication:  how users logon and how you determine that they have done so successfully
-- Authorization:  how you determine/control what their application and data rights are after they have authenticated
-- Audit:  tracking their usage of the system all the way through
-- Encryption:  Full encryption for data in transit and data at rest

Feel free to direct message me with info about what your app is supposed to do, and I can help you understand additional considerations such as data management and obtaining/tracking patient consent, as appropriate.

[Gustavo 'Gus' Carreno]

Hey PascalDragon,

mORMot is - despite its name - not only an ORM. It provides various facilities for client/server communication as well. And in the Lazarus field its one of the choices with the broadest coverage.

Humm, interesting!! I really need to dive into a mORMot tutorial of some kind!!

Many thanks for the clarification!!

Cheers,
Gus

[LeadGuit]

I try to make some points as well - less on the architecture as OP intended, but more on the general thing:

Making it secure from MitM is not too hard - https and keeping the logic on the server gets you pretty far. Now for some context what I'm about to say:
I live in Switzerland - and a couple days ago, a NetSec group tested our main Vaccination platform on security - unfortunately, they found quite large and critical holes. The platform currently is offline and the creators are being looked at legally (not sued yet, but officially investigated). If you are speaking german, security report in full is available here: https://mezdanak.de/wp-content/uploads/2021/03/2021_03_21_Report_meineimpfungen-v1.1.pdf. Yes, those points are mainly due to the web interface, but some things in it are simply bad practice and a no go.

The crucial points they found on the platform that they found are:
- Vulnerability for Password reset: If a Doctor account isn't authenticated yet by the authority, a Password reset can still work and create access to the system
- Activation of doctor accounts without proper check: Doctors had to send their "Health Professional Card HPC"
 (some kind of ID Card) and a Diploma in, so a human can verify their legitimacy. Needless to say that these can be forged, and that legally that this "validation" is not enough for this kind of data
- Non-Web Issue: Every Doctor could access every patient: Iirc you wrote in your initial post that this would be a requirement for the app - the security researchers put that as critical risk - each doctor can access all private data of a patient (name, address....). The Thing is - if one doctor account get compromised, all patient data is at risk. That is not good.
- Non-Web Issue: Generation of a patientID: Well, this one made me laugh for it's simplicity...the patient ID is simply the UNIX timestamp when the person registered! So you would be able to crawl patient Data without any problems...usually you would create a hash or the like...
- Auth of doctors account without proper "trust niveau": For some reason, doctors who have registered via a different federated ID mechanism, aren't able to use 2 Factor Authentication - according to ISO/IUC 29115:2017 this has to be the case ("high trust niveau" which 2FA is)
- And there were some XSS vulnerabilities too.

Now, I know you were talking about distributing the software to doctors directly, and patients wouldn't have access, and there would not be a webinterface in the classic sense. But keep in mind what can happen - in case of a REST service, authentication is needed. Else, if somebody, be it by chance or targeted attack, finds the REST endpoints you use your database is compromised. Same goes for the Application you distribute - Authentication so nobody could get a hands on that software and scrape your database. Also keep an eye out for the ISO/IEC standards for "medical grade software". There could be regulatory requirements at your place - from proper IT security (where is your server? Have you hardened it, and how?) over Risk Management, Life Cycle etcetc. as far as I know, ISO 13485 is one of the ISO lizences/standards that you would have to follow. But I'm sure you will find the better ones for your specific use case.

So overall - If you are a software pro and have experience in creating Medical software and are just new to the Webservice aspect - find a NetSec firm or group to work together with for hardening and securing, and pay attention to your countries legal obligations with such interconnected systems. If you are a networking pro and simply have never dealt with medical software, then all the vulnerabilities above should have made you laugh and cry. Make sure to read through the ISO standards and the legal requirements to run software at a doctor.
If you not experienced in either - put your idea in a nice form, a nice proposal and maybe work together with a software company who has developer such software, and maybe you can make a deal with them that they develop it and give you some fair money in return for the idea (As a film/TV composer myself, I love royalties  )

I don't want to talk you out of it - but I want to make sure that you know what medical software entails and what can happen. It's not as straightforward as an application for a local SMB or an app for your own use.

[DonAlfredo]

That are some very good replies ! With lots of info and considerations when designing a med-system.
I know (for sure) that the mORMot is able (and used) to take care of all that is written. But designing this from scratch will be a lot of work and will consume time until bugger-free.
Again, you might ask for help on the mORMot forum. However, designing such a system (by a mORMot expert) might need more than just a few free beers.

[Josh]

Thought I would add an additional idea, that would be patient oriented.

How about creating a Mobile App, that stores only the patients data; with facilities for user to add their own information( ie taking herbal medicine, taken paractetomol ibuprofen etc), add when symptoms occur, how often do you forget about symptoms when you see a doctor .

If you could convince the Other IT providers to have a facility that creates a QR code after you have finished your appointment, so you can scan and get the details, results of the visit, you then create your own database of the patients information, the advantage is if your admitted to hospital in an emergency anywhere in the world, you would have access to all your treatment and where and when it was done. ( this way your solely repsonible for only your data).

I do not think they would allow you to download scan/xray images etc, as these are the property of the health board. Think of a photo the owner is the photograher not the subject.

With this system, you could have a paid service where user can upload a highly encrypted/password protected by (finger print tech) backup of their data, but not mandatory.

I think this approach would be far more attainable, and more likely to accepted by other medical apps, as your main point is its only after the users private data and nothing else, that a patient can get if they applied for a freedom of information request ( but you would have to apply to all authorities/companies that hold data).

You may have to limit use to phones that have fingerprint technology so as to secure the data on the phone that way a doctor disgnosing you, if your are unconscious, can still get access to your data by using your print. Very handy if your going abroad regularly.

I know a totally differnet idea to OP idea, so you may recomend moving to a Seperate thread.

[BSaidus]

Thank you all for your recommendations and help.
First of all, I understand that the MED is a sensible field that I must know all legislation about that, after that I notice that it will consume many time.
@josh
Yes I planed a MobileApp for patients with a minimum ( taking randez-vous, get certificate .. ).

Thanks you all.

[zamronypj]

- Non-Web Issue: Generation of a patientID: Well, this one made me laugh for it's simplicity...the patient ID is simply the UNIX timestamp when the person registered! So you would be able to crawl patient Data without any problems...usually you would create a hash or the like...

I think patientID only needs to be unique. As long as generated patientID is unique, even only using  unix timestamp, it is ok.

If you are able to crawl any patient data without problems then it is authentication and authorization problem. proper authentication and authorization mechanism is solution.