Call participants: Prasanth, Phoram, Shuro, Nathan, John, and Jessica.

We reviewed Michael and Phoram’s questions on the registration module:

Why is the ID number displayed in reg? Is it to distinguish between people who have the same name? Different from OpenMRS ID? Some systems do implement multiple IDs. Ultimately, the user has to be accountable. The user must be logged in, otherwise the patient’s single ID number shouldn’t be exposed, if there is only number then it should only available to people who have logged so we can trace it back to who accessed.

This issue is solved by our required login for access, with role-based permissions.

Are second levels of passwords or additional authentication required? Legally there are not strict guidelines, but you have to be able to track access. The law specifies that ISO standards must be adhered to (this is an industry level standard, but also does not specify requirements, they are more like best practices. ISO recommends role-based authentication, and that the password should be complex, but doesnt specify 2 factor or 3 factor, etc. (Phoram will upload ISO standards to dropbox)
What is the best strategy for biometric authentication? (this will be important later, but not for first version) retinal scans are good but intrusive, fingerprints are okay but not good compared to other authentications (UID is doing both)
- how expensive in terms of hardware? retina yes, fingerprinting no.
- 2) Why show address, gender, etc in search results? Search results should show just enough info to distinguish, but as long as it isn’t “sensitive” information (as defined by law) then it is okay. Typically search results should be minimal
- Chronic illness and chief complaint seen by reg staff: because there are specific treatment plans and workflows that are different for chronic vs. new patients. there is a potential for exposing sensitive information to the reg staff. reg staff should not have access to the PHI, but a flag for chronic illness could be created as long as the type of illness is not revealed.
  - For screener: Assigning to a specific doctor should not be an issue... chief complaint,
  - Ultimately, every person must be assumed to have contact with sensitive info, so every user has to agree not to reveal that...
  - In order to bind the user legally to not leak is it easier to have blanket contract?

Prasanth summarized the key points of his minimum requirements document:

We must focus on the three key areas: Collection, Storage, and Sharing of data.
- For collection, we must focus on the current registration process and make sure consent is obtained at this point. Should also consider if data will be used for research.
- For storage in particular we should refer to ISO standards
- Sharing may come at a later stage, so may not be as crucial right nowThe option for pati
- If JSS uses software, who is liable? The agreement should read such that Raxa is not liable, even in the case of a security breach.
- We should pay careful attention to licensing components, they should all be compatible.
  - Nathan thinks its worth a thorough look. Github?
  - Which licenses are compatible with apache when people add code? (Prasanth please share with Nathan)

To do before next meeting:

-Finish answering Michael and Phoram’s questions in the google spreadsheet for other modules (to the extent that we can without discussion) (Jessica, Nathan, John, Shuro)

-Create document detailing layer based permissions/access – documenting who has access to what (hierarchy structures) – doctors, nurses, pharmacists, etc. This document will inform the Terms of Service and Privacy Policy. (All) Phoram will add specific comments on roles. John has already started this doc here: https://raxaemr.atlassian.net/wiki/display/RAXAJSS/Role+based+permissions

- Draft of Terms Of Service (All, led by Prasanth)

Browser not supported