2012-07-18 Privacy meeting

Participants: Surajit Nundy, Michael Tschantz, Nathan Leiby, John V Stoecker (Unlicensed), Prasanth, Sathyan VelumaniDaniel Pepper (Unlicensed), Jessica Tribbe

  1. Introductions
  2. Draft of Policy Paper: 
    1. The purpose of the paper
    2. filling in the gaps (in need of volunteers to help with specific sections)
    3. Additional Resources in a new Dropbox folder (Documents for best practices, etc)
  3. Deciding on Privacy Policy/Terms of Service
    1. Examples: VoxivaCommCare
  4. Technical Implementation: 
    1. Can we look at Markle Foundation or OpenMRS (The report on the audit of their system can be found here) for resources on making a plan?
    2. Best methods for reviewing current screens/workflows
  5. Discussion
    1. Legal Aspects  (Prasanth)
      1. There are specific rules under the IT Act which will apply to us
      2. Need to consider the data at three stages: Registration, Storage, and Retrieval / Sharing (within and outside of hospital)
      3. There should also be provisions for Sharing(within and outside of the hospital), and withdrawal of consent
      4. In addition to the IT Act, we should look at other existing best practices? 
        Markle, HIPAA? - who do we want to base our policy on, esp given the unique concerns of JSS?
        1. Michael warned that HIPAA may not be the best model, the word "may" is used throughout and it presents a series of choices, but we'll need to make a specific choice of our policy. Perhaps a better approach is to define what we want to do and then check if it complies with HIPAA, then decide where we stand
    2. What are our "minimum standards"?
      1. Can compare these against Indian law, ethicists
      2. Prasanth will put together a document that outlines what is required by Indian law, as well as according to some of the major policies internationally. 

    3. How long to make a privacy implement policy and tech elements for "minimum standards"? 
      1. Under a month? Can continue to refine. Iterative process needed to make sure we can implement what we promise in 
      2. Can follow a process, like OASIS Privacy process
    4. How to make existing code privacy compliant?
      1. What tweaks can we make to existing screens to make them more privacy-aware ... Michael will try to review screens and make comments
        1. Access Control
        2. Post-Access Logging
        3. Patient Autonomy - what kind of information does the patient get out of this system?
          1. Reasonable that patient might want to see what doctor is entering
          2. but also concerns about what sensitive data could be if a patient is watching the system in use
          3. See existing Patient-Facing module for conceptual ideas on how we'll interact with often illiterate patient population at JSS
            1. patient-facing.github.com (code: 
    5. "Google Search" (searches across all fields)
      1. First name and last name often mixed up ... so if we search by fields then we would miss this record
      2. Do a multi-field search on demographics?
      3. Feature itself doesn't seem to violate privacy, but seems like there might be many more illegitimate rather than legitimate uses –> worth doing? what are valuable use cases and do they outweigh the problematic ones?
      4. Prasanth: these can be addressed in the consent forms, but we will have to ask consent for different features.
    6. How does ToS apply to
      1. Patients
        1. Possibly illiterate – must explain by reading/recording it to them?
      2. Doctors/Nurses/etc
      3. Software developers
  6. Next Steps/Timeline
    1. Consider Splitting into 2 working groups
      1. Privacy Policy , high level
      2. Developer level feedback (we may schedule a separate call for this)
        1. how to ensure our screens respect privacy better... user-workflow
        2. code-level security concerns
    2. Aim is ~Aug 31st for completing a ToS document, since we want to begin implementing soon after that date
      1. We will be breaking the law if we implement the software and don't have a ToS
    3. Recommended ToS