Friday, March 4, 2016

FHIR Security and Privacy - tutorial outline

Rene asked for an outline of Security topics for FHIR for an upcoming tutorial he is giving.

The easy answer is go read all my blog articles under the #FHIR topic

The second easy answer is to point at the FHIR security pages.

I find it interesting is that I answered this same question back in January 2013.. I didn't notice this until after I completed the list below and was confirming I hit all my blog articles. Not much has changed in 3 years. http://healthcaresecprivacy.blogspot.com/2013/01/security-considerations-healthcare.html

The outline of the main topics to be covered:
  1. With HTTP REST interaction model for FHIR, it is designed to leverage any security model that HTTP includes. That is to say that HTTP interaction model has a set of security models that are transparent to the data-model contained in the HTTP transaction.
    • With messaging, you should be able to use http security, it is just not as obvious.
  2. We encourage use of HTTPS. Servers should enforce this as appropriate to their environment.
  3. We encourage the use of Federated Identity for Authentication
    • Most likely OAuth 2.
    • Profiles of OAuth 2 exist from IHE (IUA), HEART, and SMART. They are all about the same.
    • Equally useful is SAML, which might be more friendly to the Enterprise use-cases.
    • The most important part is to recognize that this is totally independent but totally supporting of the FHIR specification.
  4. We encourage use of the AuditEvent for recording whenever a security/privacy relevant event happens. (This is different than a provenance record). All actors should record AuditEvents from their perspective, it is through these various perspectives that security audit log analysis sees unusual events and thus starts an investigation.
  5. We encourage use of the Provenance for recording persistent record of provenance of any create or update transaction. There is also provenance built right into some FHIR Resources when it is so fundamental to the operation of that Resource. (This is different than an audit log) This is important to Security and Privacy; but also to Medical Records integrity.
  6. All resources have a 'meta' element that can hold security-labels (inclusive of privacy labels). These tags are used in an "Attribute Based Access Control" scheme. That is to say that an Access Control engine will use these meta tags to inform the decision that it makes; and can place tags into meta to inform any downstream Access Control engine (decision or enforcement).
  7. Some meta tags are 'obligations'; when in a trust relationship one party that trusts another party can communicate obligations which are constraints or actions the receiving party is obliged to carry out. When no trust relationship exists, obligations are of no value.
  8. Access Denied must, like in any standard, be carefully managed so as to give appropriate information but not give away important information. Sometimes it is best to tell the client that their query was perfectly accepted but that no results are available, sometimes one tells the client 403 or 404, etc..
  9. There are efforts underway to create a Privacy Consent Directive modeled in FHIR. This is a profile on Contract resource. This is intended to record the facts of a consent. This includes the various rules that would need to be enforced by the Access Control engine.
  10. There are efforts underway to show how to use UMA to enable Patients to control access to their managed data. This is an extension on OAuth for the purposes of "User Managed Access" (UMA). This should complement the Privacy Consent Directive.
  11. There are efforts underway to define OAuth 'scope' values. This is not an obvious science as the way that FHIR data-model is defined is not an logical set of access control restrictions.

There are a few other topics on my blog, but not much.

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)