Hi Tim,

There is a nice article on Wikipedia which introduces a few pointers toward a Common Data model, and standards for transefering / exchanging data: https://en.wikipedia.org/wiki/Electronic_health_record

In terms of privacy and information security you need to keep an eye on quite few aspects most importantly: confidentiality, integrity, and availability of the data and how to guarantee it. Start with privacy and information security in mind (don't implement this afterwards).

I would start by implementing an audit systems that tracks all access to records and all events (changes to records, not only the medical ones but also changes to user roles, logins etc.). Then think about all the different roles and permissions in the organization and application and how they need to access the records or events. The permissions (within the application and organization) need to be subjected to regular reviews, and I recommend so must the application security (proper pen-testing etc.). Encrypt all medical and person-identification data.

Some experiences from a semi-medical application I worked on:

- all medical related records in separate modules, only very few roles need access to that module

- review each others work thoroughly, don't depend on users finding issues

- make it very hard to link personal identifiable fields (and there are many!) to the medical records

- username/password is not enough, use 2FA

- go offline, not being connected to the internet reduces the attack vector by a lot, if you must go online, try to do and keep as much in system A (which is offline and e.g. for employees) and as little as possible in system B (like a patient portal). Be very strict how you transfer data from system A to system B, don't persist data in B unless absolutely necessary, verify requests with tokens or another system (so an authenticated user in B can’t request data from A eventhough he is authenticated, only his own data which matches his token).

- think about how you handle backups and how production data should never  end up on your local machine

Also worth a read: https://softwareengineering.stackexchange.com/questions/176992/my-father-is-a-doctor-he-is-insisting-on-writing-a-database-to-store-non-critic

Rules very a lot per country (US, EU, within the EU) make sure to get an expert on the matter.

Did I say encrypt the data?

There is a lot to think about, but start with privacy and information security in mind, read about it...and never cut corners…

edit as you may have seen in the news don't add export to excel buttons everywhere ;)

You can do this in Mendix, but it will require a lot of effort. A common requirement that springs to mind is to log access to dossiers. In Mendix, this is a hassle, because by default you can access dossiers (and related information) through the client API, and this cannot reasonably be logged. Therefore, a default implementation is Mendix is technically not compliant.

A workaround for such an issue could be to only access data through non-persistent objects, which you populate from your persistent entities. Your persistent entities do not have read rights. This way, whenever you create a non-persistent dossier, you can log it and there is no other way to access a dossier. However, this leads to a lot of additional work and you lose a lot of default functionality, such a using filtering and sorting on grids.

You either need to accept that technically savvy people will be able to access data without it being logged, you need to very strictly control endpoints so no JavaScript can be executed or you need to create workarounds in Mendix, reducing your development speeds, extensibility and maintainability.

This is just one example that springs to mind, carefully reading all non-functional requirements will probably reveal many more issues that you somehow need to tackle.