Questions to be discussed
Security
on front end
No reason to hide .js files as we are open source (should we sign them?)
Cosmetic restriction will be useful
However, might be useful to add certificates/signing to make sure javascript file that is being run is *our* file, not some other weird version
Downside: performance
Example: user queries all patients, scrolls through all patients in the front end
Should we log this?
Login
OAuth, SSL
OpenMRS currently only has Basic Authentication
Solve man-in-the-middle attack with SSL
State based security on back end
Many EMRs have only wide permissions – Doctor X can either see all patients, or no patients
We already have this
Prefer to have granular permissions - Doctor X can see Patients A,B,C, Doctor Y can see Patients B,D,E
Where to put the permissions?
Recommended by Michael to customize OpenMRS
Would make updating OpenMRS more difficult
Eventually may want to write our own entirely new system
Should start document designing our own system
Downside: updating JSS off OpenMRS will become more difficult later
Database Encryption
Would want to encrypt only sensitive data
Separating sensitive and non-sensitive is prone to error (almost never works)
Any medical information is sensitive in an Indian village
Separate sensitive patient data and general medical information (Heart Burn, Aspirin, etc) into separate tables
Logging
Put in a log file or in separate database? need to be able to search + audit, but don't want it to slow down our system
Whichever is faster
Probably log file with a large buffer
Is it sufficient to only logging REST calls?
Eventually want to log front end data as well (which module is being used)
Analytics to see how users go through the system
Types of breaches:
Downloading of all patient data, selling it
Nurse/doctor is curious, looking up data on them
What to cache on local device
Make sure to clear patient data after a session
Start document on vision comparing with other EMRs