FYI: NIST: Revision of SP 800-53 Addresses Current Cybersecurity Threats, Adds Privacy Controls

I often reference NIST 800-53. Not because I am USA centric, but because this is the most readable and comprehensive catalog of security and now privacy controls. There are plenty of standards that try to address security and privacy functionality, and they are all good. I just like this one because it is both comprehensive and readable.  This is not just a catalog, but also a process for determining what should be done, and for analysis of if you are complete. It really is a total package.

I would like to see more references made to core functional specifications like this one, with just the healthcare specifics added. This is my approach in my efforts with ISO 14441 and EHR Functional Model.

Revision of SP 800-53 Addresses Current Cybersecurity Threats, Adds Privacy Controls
A major revision of a Federal Information Security Management Act (FISMA) publication released today by the National Institute of Standards and Technology (NIST) adds guidance for combating new information security threats and incorporates new privacy controls to the framework that federal agencies use to protect their information and information systems.  

.... 

The public draft of Security and Privacy Controls for Federal Information Systems and Organizations, Special Publication (SP) 800-53, Revision 4 may be found at http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-53-Rev.%204. Comments on SP 800-53, Revision 4 are requested by April 6, 2012. 

The way they handle Privacy Controls is very good. They have created a new Appendix "J".

PRIVACY CONTROLS 

PROVIDING PRIVACY PROTECTION FOR FEDERAL INFORMATION 

Appendix J, Privacy Control Catalog , is a new addition to NIST Special Publication 800-53. It is intended to address the privacy needs of federal agencies. The objective of  the Privacy Appendix is fourfold:
•   Provide a structured set of privacy controls, based on international standards and best practices,  that help organizations enforce requirements deriving from federal privacy legislation, policies, regulations, directives, standards, and guidance;
•   Establish a linkage and relationship between privacy and security controls for purposes of
enforcing respective privacy and security requirements which may overlap in concept and in
implementation within federal information systems, programs, and organizations;
•   Demonstrate the applicability of the NIST Risk  Management Framework in the selection,
implementation, assessment, and monitoring of privacy controls deployed in federal
information systems, programs, and organizations; and
•   Promote closer cooperation between privacy an d security officials within the federal
government to help achieve the objectives of  senior leaders/executiv es in enforcing the
requirements in federal privacy legislation, po licies, regulations, directives, standards, and
guidance.  

There is a strong similarity in the structure of the privacy controls in Appendix J and the security
controls in Appendices F and G. Moreover, the us e of privacy plans in conjunction with security plans provides an opportunity for organizations to select the appropriate set of security and privacy controls in accordance with organizational mission/business requirements and the environments in which the organizations operate. Incorporating the same concepts used in managing information security risk, helps organizations implement privacy controls in a more cost-effective, risked-based manner while simultaneously protecting individual privacy and meeting compliance requirements. Standardized privacy controls provide a more disciplined and structured approach for satisfying federal privacy requirements and demonstrating compliance to those requirements. 

Meaningful Use Stage 2 FINALLY means Secure and Privacy Protecting

Updated August 2014 -- Seems people are still finding and reading this post from almost 3 years ago. Please refer to the MU topic for more up-to-date information. 

What is the benefit of an HIE

I got this question and it kind of hit me as a surprise. I forget that not everyone understands what it is that I am trying to enable through all of the work on Health Information Exchanges (HIE). I am far more focused on developing the standards to enable Privacy and Security on Health Information Exchanges than I am at fully understanding the use-cases that it enables. However during the development of HIE standards we do use some general purpose use-cases that I think are indicative of the kinds of things that they enable.

There are discussions of the advantages from a much higher level. On the economic benefit, I think this is not going to turn out to be as big as many think it will be. I suspect that there will be a small number of tests that won't be re-ordered. Fresh lab results are too important. On the quality benefit, I think this is also not going to turn out to be as big as many think it will be. Quality will be driven through more transparency, which will come from HIE but also many other things.

I am very excited by any advance in HIE deployment, for example the NwHIN Exchange is a fantastic effort. The fact that the big Healthcare Providers are using the same standards yet pushing operational success faster is clear there is something important. I think this kind of a nationwide exchange has advantages that others don't have, but other exchanges are also fantastic efforts. I also think that it is great that there are smaller Regional exchanges like those represented by the REC effort of ONC, and point-to-point exchanges like those enabled by the Direct Project. I am even for patient initiated exchanges such as a PHR like HealthVault, or even simply using removable media like USB-Memory sticks and CD-ROM.

Putting the Patient at the Center:
Why do I like all of these? It is because they are putting the Patient at the CENTER of Healthcare. It is enabling historic information to be available to make current or future treatments to be better. This is the core answer that I have to the question. My goal is to get information flowing. Yes, as a Security and Privacy advocate I want it only going where it should go. There are so many ways that historic information can be used to enable better care. Even knowing the specific details of your current treatment enables you to be a better patient. So I am excited at any effort to get information flowing.

That said, I would prefer that the best quality, fullest details, and most authoritative information flow. I have worked hard to be a part of open and transparent standards development that has resulted in the XD* family of Health Information Exchange profiles from IHE. I call this a family of profiles because there are both multiple profiles needed beyond one of the core XD* profiles to make a fully functional HIE; but also because there is a consistency across the XD* family that allows for the most re-use. For example there is profiles in XDS for building a regional HIE (Like the REC), profiles in XCA for building a nationwide exchange that is a federation of regional exchanges, profiles in XDR and XDM for building point-to-point or peer-to-peer exchanges such as the Direct Project, and profiles in XDM for exchanging electronic copies of health information on CD-ROM or USB-Memory. By using these profiles one can easily convert from one HIE architecture to another, which was shown in the Direct project. This comes from a common patient centered metadata model for describing documents, and the relationships between documents. This is the message in the IHE white paper on the topic Building HIE using IHE Profiles

What is enabled by HIE that a doctor can't do today:

First, anything is possible today. An HIE simply makes it more effective and efficient. Which for some means that they are enabled to do something they can't do today as it is prevented or made too hard. Putting the Patient at the center enables:

• Doctor has access to historic information that was not created by that doctor 
• Patient is referred to a specialist, delivering electronic versions of the documents enables better care by the specialist 
• Onset of a new condition, where some prior conditions may be relevant 
• Open Referral, where the patient is allowed to choose the specialist that they go to. 
• Highly mobile patient. Either winter-summer migration, work related travel, migrant worker, etc. 
• Urgent care, I am not going to say emergency as that typically is handled through direct observation and measurement to stabilize the patient. But once the patient is stabilized there is going to need to be a record made of the treatment that the patients GP would be interested in, and there might need to be a treatment plan put in place or a referral. 
• Patient with many medical conditions. helping to keep track of the overlap between the different conditions. 
• Patient with complex condition that take many years and many treatments and many specialists 

An article I wrote, Directed Exchange vs Publish Discover, a while back is written more as a defense of the Exchange over the Direct model; but really the point I was making is that they both enable very useful use-cases, just not to the same degree. You can see from the article that there are multiple things that are enabled that directly affect the patient. 

Privacy and Security are core
Getting back to Privacy and Security. I know that we can secure these exchanges, I know that we can give patients some controls TODAY, Simple and Effective HIE Consent. The way to do this is to start with simple yet broadly applicable controls. These controls can then be refined over time to enable more fine-grained controls. If specific individuals want or need these fine-grained controls, then they might need to wait to take advantage of the benefits of HIE. I want to enable those that can benefit with high-level controls. I want to get going now, not just to help those patients that can benefit today, but to also work out the concept of HIE, to encourage creative uses of the information to make the patient experience better.

Stepping stone off of FAX to Secure-Email

The original goal of the Direct Project was to find something better to replace the FAX machine in small doctor offices. The short answer is to use secure email. This is a great replacement for a FAX.

The Direct Project really is as simple as that. There are deployment issues, but those are really much like deploying any software today: Inside, Outside, or outsourced. The part that makes Direct, or anything secure, hard is that in order to provide security into email one needs a trust infrastructure to base the security on. Trust is always based on either faith or proof. In security circles we try to use proof more than faith. So we need to build a way to prove that someone is who they say they are. Fortunately this is a well established concept in security, but the build for healthcare still needs to be done.

------------The longer answer---------

Secure e-Mail
Under the “Direct Project”, which is just using secure e-mail (S/MIME). The following is not special, it is just restating every-day secure e-mail. This is implemented by many off-the-shelf e-mail clients. To make secure e-mail work, both the sender and receiver must have a digital certificate. It is used to:

1. Content is integrity protected using a hash method
2. Sender digital certificate signs the hash values of each document. This is used as proof the sender was the only one that could have sent these documents.
3. Sender digital certificate is included in the message
4. Each Document (attachment)  is encrypted using a symmetric encryption method.
5. The encryption key for symmetric encryption is randomly invented new for each document.
6. For every intended Receiver, their digital certificate used to encrypt each symmetric encryption key used for each document -- allowing the content to be sent to multiple receivers with the same encryption across the documents. The one message simply contains one copy of the encrypted document, and multiple small sections with each 

This is all just normal secure e-mail. It is included in almost every off-the-shelf e-mail client such as Thunderbird or Microsoft Outlook. For those wanting to integrate workflow more tightly, this is also implemented in many programming APIs (e.g. MAPI) and toolkits. It is also fully available in general purpose secure email services (e.g. Astaro). So, even the Full-Service-HISP is not a new thing.

Trust

The Secure e-mail is the easy part. The hard part is

A) How does the sender ‘find’ the certificate of the receiver?
B) How do the two parties know they should trust each other?

The solutions for both (A) and (B) can be different based on scalability and automatability needs. 

Small Scale - ad hoc trust

In the case where a small number of individuals need to communicate securely, this can be done very one-by-one. Meaning I find your certificate from previous conversations that you have signed. This is indeed why one tends to simply sign every message as it enables anyone you have ever communicated with to send you secret (encrypted) messages. This is the typical method used in normal secure e-mail use.

There are two problems with this model:

• Not easily automated
• Can be subverted

The trust model is mostly ad hoc, given that you are primarily trusting that the prior signed conversation was actually from the individual you think it is. Generally this is how we do many personal relationships, building trust because of prior conversations. It is possible that a malicious individual has sent their own message and their faked certificate making it look like the good individual. In a one-by-one scale, it is likely you would notice this and get suspicious.

Automation - Directories
You can see that the previous trust model is very dependent on personal relationships. This also leads to problems with automation. The Direct Project knows that although personal relationships are very important in Healthcare, probably more important than one might want to admit. There is a need to have some implementations able to fully automate the sending of secure e-mail. One of these, not the only one, is the Full Service HISP, as it must add security to the e-mail while the message is flying through the internet and it has no ability to interact with the user.

Fully automated computers can’t have a one-by-one relationship, so to fully automate one needs a way to discover the certificate of the recipient. This is where directories come in. So for fully automated approaches one needs to have an infrastructure to lookup the certificate. In the Direct Project they are endorsing two different methods: both DNS-CERT and LDAP.

DNS-CERT is the method originally promoted by the Direct Project. It is a creative use of the DNS system, the system that helps us with the Internet name to address translation. It is based on IETF published specifications that were implemented originally mostly as an experiment, not taken seriously by most. Thus this solution is NOT supported by off-the-shelf secure e-mail.

The LDAP method is the additional one added by the S&I Framework -- Healthcare Provider Discovery. It is a more classic solution using Directory (LDAP). This is supported by off-the-shelf secure e-mail, but isn't typically used on a nationwide basis. So there are some questions on how well this will scale.

Larger Scale - Trusted 3rd Parties
As the scale of a Trust infrastructure gets big, one needs common trusted-third-parties. This is a system where you trust some third-party to attest that the individual is who they say they are.  This is seen in real life when we go to a party, the host of the party will introduce us to all the other people the host knows but for which we don't know them. The host of the party is the 'trusted third party'. The more well connected the host of the party is, the more people we will be introduced to. This is seen as well when we speak to someone and they explain that we met at the party, or they explain that they are a friend of a friend of ours. In social terms this is an inexact system, but it has worked for millenia. 

So in security we do similar with Digital Certificates. We have a trusted third party that issues Digital Certificates. Digital Certificates can be proven that they could only have been issued by that third party that you trust. In this case the trusted third party is called a "Certificate Authority" (CA). One model for a CA is to use  the company that the Healthcare Provider is employed by. This presumes that I have a reason to trust your company. The model of trusting the Healthcare Provider Organizations does change the trust relationship from Millions of Individual Healthcare Providers, to 6000 healthcare providing organizations. But that is still way too hard to manage. 

Ultimately this is where very large scale Certificate Authorities would fill in. There are even mechanisms where there could be a trust relationship of trusted third parties, called a Cross-Certification. 

Conclusion

The technology behind the Direct Project is really just secure e-mail. Being just secure e-mail is a good thing as it is proven technology that is readily available. This solution is a great solution for replacing the FAX machine, but is not quite a mature and robust exchange. The Direct Project technology still does need Policies and a Trust infrastructure. The good news here is that there is a small scale and moderate scale solution that is readily available. Growing this to Large is much harder. I hope that we keep the Direct Project at the original purpose, of replacing the FAX; and rather use robust Exchanges for longer term healthcare.

Meaningful Use Stage 2 -- 170.202 Transport

Updated August 2014 - Seems people are still reading this post. To find useful articles on the topic also reference to the Secure Communications, HIE, and Direct topics.

Meaningful Use Stage 2 seems to support Security, Privacy, and HIE Transport

In looking closely at the Meaningful Use Stage 2 criteria for both Certification and Incentives. I looked at the areas of my focus: Security, Privacy, and HIE transport. I mostly ignored everything else, so you will need to go to Keith’s blog for those details or any of the other really good resources.

My overall conclusion is that CMS and ONC have done a fantastic job of addressing Security, Privacy, and HIE transport. Yes I did say ‘fantastic’. There are some issues, but they can be fixed. There are improvements, but in many cases we need to take stepping stones today that are on the trajectory of the future. There are clear things that can and will happen in the future.

Security:They have made mostly minor changes to the security criteria. They are leveraging well known best practices and applying them only to Healthcare when there is something specific. They are leveraging the existing HIPAA Security rule and HITECH. The main changes this time around are added detail for Audit Logging, references to cryptography experts at NIST/FIPS, synchronization of clocks, and recommendations around encryption on end-user devices.

Privacy:They have included Privacy! They should be given kudos for this. Nothing earth shocking for any well done EHR or operational environment, but welcome guidance and encouragement for those that had not yet addressed Privacy. Their changes are directly to support HIPAA Privacy and HITECH. They have identified that security audit logging is an input to an Accounting of Disclosures, and a Access Log. They have defined what these reports would include. They have given stronger guidance on Amendments.

HIE Transport:They have given us one or two Push style transports, and recognized that they interoperate by way of a proxy service that can convert forward and backward. There is no real surprises here as ONC has spent much time developing the Direct Project. Healthcare Providers and EHR developers should really be focusing beyond Direct, but supporting minimal Direct is a good thing to do. It allows us as an industry to move away from the FAX, and start universally communicating and manipulating Documents. I will note that these more Exchange like HIE models would still be considered compliant under the optional third transport.

Conclusion:I will have more detailed blogs on all these topics. I will also be explaining why some want an Exchange style HIE vs using a Push style HIE. I will be discussing what should be done regarding Consent for nationwide exchanges. And I will be discussing other suggestions for Stage 3, with explanation of why I think it is ok for CMS/HHS/ONC to wait. I do still encourage vendors and providers to go above and beyond the minimum required by Meaningful Use.

Updated with links to further discussion:

• Meaningful Use Stage 2 -- 170.202 Transport
• Stepping stone off of FAX to Secure-Email
• What is the benefit of an HIE
• Meaningful Use Stage 2 FINALLY means Secure and Privacy Protecting

Huge HIE -- the Care Continuity Consortium

The acceptance of IHE profiles for building federation of Health Information Exchanges has reached another milestone. The IHE XCA/XCPD profiles are at the core of the exchange. I worked with this group as an adviser on the standards and their use within the NwHIN-Exchange. I so wanted to blog about it, but needed to keep quiet until HIMSS 2012.

In April 2011 five leading US health systems joined forces to create the Care Continuity Consortium, and promised to achieve a clinically operational secured sharing of health information between them by early 2012, this seems an aggressive challenge. But it also drew some respect to see pioneers in the use of electronic medical records systems such as Geisinger Health System, Kaiser Permanente, Mayo Clinic, Intermountain Healthcare and Group Health Cooperative, engage into national level of information exchange. 

They committed to leverage existing standards and IHE profiles already selected by the Nation-wide Health Information Network (NwHIN-Exchange) to enable a national-scale health information query service. At HIMSS last month they showed how this group supports their clinicians in their practice to access patient summaries information from different health systems.

They are sending the message that the current available standards and profile, do work and can be successfully implemented. This interoperability serves well the clinicians, and patient consent can be managed effectively with large scale interoperability being a matter of political will.

Further development will continue to be done to dial in more and more functionality, efficiency, and privacy. An important message is that the system can fill a need, does support more use-cases than Direct, and is more automateible due to a mature metadata model.  

Add the CCC network to the likes of NwHIN-Exchange and the European wide epSOS. There are more to come, but of course I must keep them a secret.

Reference:

Kaiser: Care Connectivity Consortium Celebrates Milestone at 2012 Annual HIMSS Conference

PR News Wire: Care Connectivity Consortium Celebrates Milestone at 2012 Annual HIMSS Conference 

Health Data Management: Five Provider Heavyweights to Share Data 

Health IT News: Pioneers in EHR use to create data exchange model