Healthcare should join OASIS Privacy Management Reference Model (PMRM)

This is the latest effort to focus on understanding the requirements of Privacy Controls, and buildin a reference model to manage privacy policies and support enforcement. I have added my name to the group, but because of OASIS rules of membership classification I get no mention as I am only an "Individual Member" and not an "Institutional Member".  I am disappointed that I have been unable to convince other healthcare organizations to bring healthcare needs to this group. I think healthcare is an especially critical and yet complex problem. That is to say that I want the needs of healthcare to be known, but don't have any expectation that they will be solved for years. But if they are not known by this group then they could very well go down pathways that healthcare can't follow, such as DRM.

OASIS has announced the creation of a new Privacy Management Reference
Model (PMRM) Technical Committee. It's principal objective is to "develop
and articulate a Privacy Management Reference Model that describes a set
of broadly-applicable data privacy and security requirements and a set
of implementable Services and interactions for fulfilling those
requirements.  The first meeting of the PMRM TC will be held as a
teleconference on September 08, 2010. Institutional member companies
approving the TC charter include CA, ISTPA, NIST, American Bar
Association, WidePoint Corporation, and Information Card Foundation.
The PMRM TC is expected to be of interest to privacy policy makers,
privacy and security consultants, auditors, IT systems architects and
designers of systems that collect, store, process, use, share, transport
across borders, exchange, secure, retain or destroy Personal Information.

The TC will accept as input the existing ISTPA Privacy Management
Reference Model v2.0 -- a structure for resolving privacy policy
requirements into operational controls and implementations -- developed
by the International Security, Trust and Privacy Alliance (ISTPA). It
is anticipated that this document will be contributed to the TC for
further elaboration and standardization at OASIS.

Specific goals of the TC are to: (1) Define a set of operationally-
focused privacy requirements which can serve as a reference for
evaluating options for designing and implementing operational privacy
controls. These requirements will constitute a useful working set of
'privacy guidelines', which can both serve as general guidance, and as
a feature set against which the PMRM and any implementation can be
tested. (2) Define a structured format for describing privacy managementServices, and identify categories of functions that may be used in
defining and executing the Services. (3) Define a set of privacy
management Services to support and implement the privacy requirements
at a functional level. These Services will include some capabilities
that are typically implicit in privacy practices or principles (such
as policy management or interaction), but that are necessary if
information systems and processes are to be made privacy configurable
and compliant. (4) Establish an explicit relationship between securityrequirements and supporting security services (such as confidentiality,
integrity and availability services) and the privacy management Services.
... More

See also the OASIS Privacy Management Reference Model (PMRM) TC public web page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pmrm

Tutorial on HL7 Security Cookbook at Boston HL7 meeting

The HL7 24th Annual Plenary and Working Group Meeting is going to be held in Cambridge, MA on October 3-8, 2010. There is a fine Plenary agenda focused on "Future of Healthcare Using Genomics as a Key Tool". 

In addition to the Plenary and all the workgroup meetings, there is yet one more reason to attend. I will be presenting the HL7 Security Cookbook as a Tutorial. I will be presenting Thursday Morning. The Security Cookbook is the process that HL7 is adopting to assure that as standards are written they have incorporated appropriate security considerations and document relevant risks that need to flow down. I discussed this in prior blog post How to Write Secure Interoperability Standards

The formal name I gave to this tutorial: Security Risk Assessment Cookbook: Incorporating Security in HL7 Standards (clearly it got shortened for the web site)

Brief General Description Of This Tutorial:
Healthcare today has some of the most diverse needs with regard to sharing of data and the need to securely move patient information among systems. Within Health Level Seven (HL7) there are multiple verticals that consider messaging, structures, data models, coding and the like. Security is the common thread that connects all of them. Increasingly, healthcare organizations and technology vendors are performing assessments (threat risk assessments, privacy impact assessments, business impact assessments, etc.) to ensure installed healthcare technology will have a positive impact on healthcare delivery. These assessments, often called risk assessments, are even mandated for healthcare delivery organizations in some countries. Unfortunately, key decision makers often have difficulty understanding the relevance of the risks identified, and often overlook them when writing standards.

This Security Risk Assessment Cookbook is intended to enable HL7 domain committees and working groups to publish standards that have taken privacy and security considerations into account. This guide introduces security risk assessments and a process to facilitate completing a security risk assessment for a specific standard. Using this process will facilitate the identification of gaps in a standard’s baseline security and privacy, allowing the working group to either update the standard on their own or to send a request to the Security Working Group for assistance in filling the gap. This will lead to standards that include privacy and security as part of their base, reducing the need to “bolt” security on later. As a result, the HL7 standards will better support patient safety and improved patient outcomes.

Who Will Benefit From This Tutorial?:

• HL7 committee members to understand how to consider Security when writing standards
• All those using HL7 standards to understand how to use the Security Considerations

Upon completion of this tutorial, students will know:

• How to publish standards that have taken privacy and security considerations into account.
• Introduction to security risk assessments and a process to facilitate completing a security risk assessment for a specific standard.
• Method of identification of gaps in a standard’s baseline security and privacy
• Method to send a request to the Security Working Group for assistance in filling the gap.
• How to interpret the security considerations when implementing systems based on standards

Healthcare use of Identity Federation

This is exciting times in Identity Federation. I have written about Identity Federation as a critical technology in : Federated ID is not a universal ID  Specifically I think that SAML is a specifically useful protocol for Identity Federation for the purpose of identifying users requesting cross-enterprise based transactions. This is specifically the purpose behind the IHE Cross-Enterprise User Assertion Profile. This profile does not fully leverage all of the power of SAML, but tries to constrain SAML just enough to get Healthcare going at using this technology. IHE is now extending this profile with some more attributes about the user. Specifically adding a descriptive string for the user, their organization, identifier of their organization, their National Provider Identifier, and such. Also adding their role and the purpose of their request, values that might be used for access control and/or audit logging (such as I describe in Accountability using ATNA Audit Controls).

There is also the recent release from the Whitehouse of "The National Strategy for Trusted Identities in Cyberspace".  From my read of this their goals are in the right place, they do seem to understand the potential miss-use, and they do seem to understand that the only way we can move forward today is to force the issue. This force is not to force a solution, but rather to force the discussion and encourage specific reasonable use-case developments. I think that Healthcare could be a very useful use-case, inclusive of Health Information Exchanges (HIE) and Personal Health Records (PHR).  My biggest concern with this initiative is that they seem to be leaning toward a Certificate (PKI) based solution, and may not see the power of SAML.

There have been many articles and blogs that discuss the issues, solutions, benefits, and risks.  I have specific concerns around any mandate, I certainly recognize that any one human truly does have many identities and has good reason to make sure that some of these identities are never cross-referenced. I understand that the Whitehouse initiative is not looking to a nation wide mandate on all citizens, but rather wants an open discussion to help inform how the federal government continues to evolve their use of trusted identities in cyberspace, essentially they understand that first they must 'eat their own dog food'. This is a good approach but they must recognize that the federal government infrastructure hits upon the non-federal infrastructure in many ways. For Healthcare this is very specifically the HIE.



There are some other solutions that are getting lots of press, and well deserved attention. Keith Boone blogged about his success at leveraging the OpenID mechanism to allow him to offload the user account management (including provisioning, de-provisioning, and such) from his purpose for having an internet present service. OpenID is a good tool to get started in this topic. Open ID is very low barrier to entry is very helpful, and the abiltiy to offload the user account management is a big plus. It however is not as formal on how to carry attributes and authorization decisions. This is not a good excuse to not start with OpenID.


I think the power of how OpenID and SAML can be used together is showed by a Clinical Trials project that Medtronic was involved with. Their solution is documented nicely on the Kim Cameron's Identity Blog. This is a project that offered their solutions to open-source and used both OpenID and SAML when the specific tools were the right tool to use. This is the kind of Healthcare use-case that I think should be encouraged by the Whitehouse initiative.

HHS Releases New Proposed HIPAA Security and Privacy rules

I am amazed that out of one side of HHS they ask for healthcare-IT to be adopted quickly, while they continue to release HUGE new documents. In this case it is an update of the HIPAA Privacy and Security rules, probably a worthy thing to do. But does it need to be so big and vague?  Why is 234 page really necessary? Yes the first 175 pages are introduction that is not legal, but still this is excessive. The deadline for the comments is 60 days past the official publication. So, I am sure no one will do anything in the next 120 days for fear that they are doing something that might be in violation of these new rules.

HHS has announced the release of a HIPAA Privacy & Security NPRM which will modify aspects of HIPAA as amended under the HITECH Act. The NPRM has not officially been published in the Federal Register, however, the pre-publication PDF of the rule was released and can be found at: http://www.ofr.gov/OFRUpload/OFRData/2010-16718_PI.pdf

I will be further dissecting this NPRM on my blog and responding to .

My point is not specifically against this new rule. But rather that HHS/ONC seem to be continuously ripping open the scab just as we start to feel like we understand what to do. If it is not security/privacy it is some new statement on code-sets, or document types, or etc...