Guidelines for Application Developers

  1. When PHI is viewed or modified, your application should record the identity of the person and the timestamp (other metadata, e.g. IP address, is not required but can be useful). A natural place to store this kind of information is within the database schema. Note: only identifiable information requires this level of auditing - for a list of the 18 PHI attributes, see http://cphs.berkeley.edu/hipaa/hipaa18.html.
  2. If PHI is being removed from the system, ensure a copy of the PHI is logged by the application's auditing mechanism. Another approach is to implement "soft deletes" in which a deleted record is rendered inactive but not physically removed from the backend.
  3. If your application generates any documents or files and persists them to a storage mechanism (local filesystem, Amazon S3, etc.), do not embed PHI attributes in the filename. Using an internal ID scheme is fine, however.
  4. Strengthen the application's authentication mechanism to make it harder for unauthorized individuals to gain access to the system. There is an obvious trade-off between strong security and usability, but since the majority of breaches are caused by application-level vulnerabilities, it makes sense to start there. Examples:
    • Require strong passwords (at least 10 characters in length and a mix of alphanumeric characters/symbols; there are open source libraries that already do this)
    • Implement automatic session timeout after a specific amount of inactivity
    • Implement multi-factor authentication (roll your own with Twilio or use an existing service like Duo)
  5. Use application roles to authorize access to PHI on a need only basis. If there are dashboard and/or summary views that every user can access, consider removing or masking the PHI, if possible.
  6. Generally, any emails and SMS messages generated by your application should not contain PHI since the recipients might not be using a secure mechanism to receive these messages. In most scenarios where PHI needs to be transmitted, an application can embed a link back to a Web page that requires authentication prior to displaying the PHI. If your application cannot use this approach and must embed PHI, the Direct Messaging project is another alternative.
  7. Ensure your application is protected against cross-site scripting (XSS) and SQL injection attacks. Many Web frameworks include some level of functionality to address these concerns. Keep your application framework and its open source dependencies up to date with regard to security patches.
  8. Security assessment of external services / APIs. If your application is integrated with any external service for a specific function, it is your responsibility to protect sensitive data. For example, if your application is using an error capture or performance profiling service, the default configuration might permit access to PHI and other sensitive information. The vendor or maintainer of the API client might provide documentation that describes how to filter out sensitive data before it goes over the wire. If you are shipping PHI to an external service, the receiving service provider should have a Business Associate Agreement with your organization, so that it's clear how the data is being handled at their end.
  9. Safeguard data containing sensitive information (PHI, PII, financial data, etc.):
    • Data migrations should be performed directly between the source and destination environments, avoiding a developer's personal machine as a pass-through environment.
    • Instead of using a production database extract for development or testing purposes, create seed/fixture data or create a scrubbing process that can duplicate real data, masking or removing sensitive values, before the dataset is shipped from the production environment.
    • If you must store a copy of sensitive data on your local, non-production machine, be sure the disk is encrypted (Mac example).
  10. Avoid storing secrets, API keys, and sensitive data inside code repositories.