How to apply Risk Assessment to get your Security and Privacy and Security requirements

Often times I am asked for a set of security and privacy requirements. My response is that there is no set security and privacy requirements, that a Risk Assessment approach is the proper way. This leads to a discussion about how to do a Risk Assessment. This article is simply a short article on how to apply Risk Assessment. There are books written on the topic, there are consultants that only do risk assessments, there are many tools. This a simple concept, but is not easy to apply. However getting started is the most important part, things do really fall right out. So you need to just get it started.

The problem with a set of security or privacy requirements is that they are prescriptive, and that they are written to cover a whole range of products. Thus they tend to not be sufficient to fully address the security and privacy problem, while at the same time being too much.

Security is best done through use of a Risk Assessment that is focused on security and privacy risks. That is one looks at the problems, not at the solutions. The solutions are applied carefully to address the problems in a priority way. That priority comes from the assessment of the risk. In this way we apply just enough technology to address real-world needs. We stay away from applying technology purely because it is cool technology. We stay away from worrying about risks that are not a true priority.

Note this same system works for small organizations, large organizations, small systems, large systems. It works quite well with mobile health devices.

Risk Assessment as a flow
I have cast this same material formally for doing security and privacy risk assessments in HL7 and IHE;

• How to Write Secure Interoperability Standards 
• IHE, Cookbook for Security Considerations in IHE Profiles
• HL7, Cookbook for Security Considerations in Standards

where the risk assessment scope is the specific standard that a group is working on. With the risk mitigation to be designed into the standard, usually with emphasis on the "Security Considerations" section. This section allows the reader to see the controls recommended as well as important risks that are not addressed in the standard.

This has also been cast in IEC-80001 for doing a risk assessment when attaching a Medical Device to a network. It recognizes that the Medical Device should have clear controls applied to clear risks, and indicate risks that might flow into the operational risk assessment. Thus the operational environment can pick up from those controls and risks identified by the Medical Device product developer.

• IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network
• More Webinars on Basics of IEC 80001
• IEC 80001 - Security Technical Report presentation

The point is that risk assessment is something that flows from one level of design to another.

How to do it
The best document that I have found is a document by NIST SP 800-30 Risk Management Guide for. Information Technology. It is an old document, but the concepts have not changed much. There is a draft revision going on, so you might also find it useful "DRAFT Guide for Conducting Risk Assessments"
SP800-30-Rev1-ipd.pdf. There are many documents on risk assessment, or even risk assessment applied to security. See the References below for a long list. I like the NIST publication because it is clear and clean.

You will need some spreadsheet that you can use to identify the risks and do the analysis. If you have a spreadsheet that is used for some other risk domain, it is likely re-usable in this domain. You might have a risk assessment spreadsheet for "Patient Safety". There are suggestions in NIST 800-30, there are suggestions in the References below. Use what you are use to using.

Given the sections in NIST 800-30:

• Table 2-1 helps the group understand that risk assessments are done at many levels, not just once. This is this is indeed the concept of doing risk assessments for standards, for medical devices, and again for network integration.
• Figure 3-1 shows the process of doing the security risk assessment. YES it is a long process, but it is a simple process once you have done it once. The same process is really just a formalization of something everyone does naturally when they assess if they should cross the street 
• Table 3-1 recognize that there are many different motivations. Yes we need to worry about all of these, but don't get yourself wrapped around any one too tightly. 
• Table 3-2 security risks are made up of pairs of vulnerabilities and threats that use them. The table is often not this simple, but you should get the picture. 
• Don't spend too much time reading section 3.3… brain storm is the best approach. If the brain storming doesn't satisfy people, then bring in some of section 3.3. Most of the time a reasonably experienced group will come up with a good set of risks. 
• section 3.3.1 tries to help you gather sources of documented vulnerabilities that likely already exist. Since you are starting fresh, this may not be that useful. 
• section 3.3.2 -- Determine what are the Vulnerabilities of the system 
• table 3-3 this is where we recognize that not everything is caused by technology 
• THIS IS NOT DOCUMENTED IN NIST 800-30 because it is healthcare specific… if a risk looks, smells, tastes, or feels like a patient safety risk… do NOT continue to assess it in the security risk assessment… MOVE it to a patient safety risk assessment. ALSO patient safety mitigation must be examined to see that they have not introduced security risks that can't be mitigated. 
• Section 4  you have some options to handle these prioritized risks…This section is worth quickly looking at, it should seem familiar. 
• there needs to be a management defined threshold for which you don't worry about the risks. This is usually where everyone fails to set thresholds up-front, thus causing unnecessary analysis and resource utilization.  Often times it is simply a statement of lowering the risk to as low as 'reasonably possible'. Where 'reason' is used.
• Section 4.4.1 is useful to look at. It reminds us that there are supportive controls, preventative controls, and detection controls. 
• Don't forget to use the cost-benefit analysis. This is where we get concerned that the fix needs to be reasonable given the pain. 
• Residual Risk -- there is some risk that can't be controlled. Risk is never brought totally to zero. Usually these risks flow down, ultimately at some operational level these residual risks get covered with Insurance.
• Appendix A might help the brainstorming session… 
• Appendix C -- an option for a spreadsheet. 

Source of Risks
A good source of things to worry about can be found in documents called Protection Profiles. A protection profile is a way of documenting the requirements for a product of a specific category. The following is a good one for our medical information systems to follow. Protection Profile for Single-level Operating Systems in Environments Requiring Medium Robustness

References

• JOKE: The Security Risk Assessment formalization should NOT use a tool like http://www.crypto.com/bingo/pr
• IEC 60812 Ed. 1.0: Analysis Techniques for System Reliability - Procedure for Failure Mode and Effects Analysis (FMEA)
• NIST SP 800-30: Risk Management Guide for Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf
• NIST DRAFT Guide for Conducting Risk Assessments SP800-30-Rev1-ipd.pdf.  
• ISO 14971:2000: Application of risk management to medical devices 
• ISO 17799 (2000) Information Technology - Code of practice for information security management
• MIL-STD-1629A, Procedures for Performing a Failure Mode Effects and Criticality Analysis, November 24, 1980 Australian Standard AS4360:2004 Risk management
• Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework
• Wikipedia: Risk Management http://en.wikipedia.org/wiki/Risk_management
• OODA: Observe Orient Decide Act
• IEC 61025 Fault Tree Analysis
• IEC 61882 HAZOP Application Guide
• Carnegie Mellon Software Engineering Institute, Software Risk Evaluation Method, Version 2.0 http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf
• SAE J-1739, Potential Failure Mode and Effects Analysis in Design and Potential Failure Mode and Effects Analysis in Manufacturing and assembly Processes Reference Manual, Aug 1, 2002
• IHE, Cookbook for Security Considerations in IHE Profiles
• HL7, Cookbook for Security Considerations in Standards
• 10 Steps to Creating Your Own IT Security Audit January 2007, IT Security Magazine
• ISO TS 25238 Health informatics: Classification of safety risks from health software
• ISO TS 27809:2007 Health informatics: Measures for ensuring patient safety of health software
• ISO/NWIP/DTS 29321 Health informatics: Application of Risk Management to the Manufacture of Health Software
• ISO/NWIP/DTR 29322 Health informatics: Guidance on Risk Evaluation and Management in the Deployment and Use of Health Software
• ISO/IEC 80001 Application of risk management to IT-networks incorporating medical devices

I do NOT need more meetings

I hate to rant too much.. but I really don’t need more meetings. Here is a view of this week, a typical week. Yes my meetings start at 7am, meaning I am regularly up and preparing for my day at 6am. Yes I have days with 8 hours of meetings. Yes people expect me to make it to 3 meetings at the same time.

 

Policy Enforcing XDS Registry

In the S&I Framework - Data Segmentation for Privacy we are looking at the standards that could satisfy one of the use-cases. The usecase is one where a Health Information Organization (HIO) is told about the patient consents, and is responsible for enforcing that consent. This arrangement has been implemented in a few HIO that I have been apart of , and I know that there are others. The advantage of this arrangement is that the Edge systems (EHR, PHR, Departmental, Imaging) don't need to concern themselves with consent. It is magically done in the HIO. This nicely centers all the consent logic. The disadvantage is that the passing of the security context from these edge systems to the central core needs to be far more complex to handle the vast number of exceptions to the rules (e.g. Break-Glass). It is a nice clean way to get an HIO going.

In this case we are actually defining a new system that will leverage multiple XDS Actors/Transactions. The IHE use of Actor is context independent. So, although an XDS Registry actor from IHE may seem like the Actor that implements the core of the HIO; it just appears to look this way. The HIO is actually made up of many things. In the terms of HITSP, we are creating compositions out of Actors; but that might be ancient history.

XDS Background

XDS is equally good at managing clinical documents as it is consent documents. So Publication of a consent document is the same as publication of a clinical document (see 1 in the figure at the right).  The abstraction of XDS allows for a central document Repository, but can also handle where these are distributed; likely hosted in the publishing organization. The Central Registry just holds document entry metadata, and naively supports data segmentation based on any of the metadata entries; most often this is simply confidentialityCode. But can also be by document type (clinical vs consent), authoring organization (kaiser, va, betty-ford). 

The XDS Query is equally good at querying for clinical documents as it is for querying for consent documents (see 3 in the figure at the right). They are all simply documents to this abstract transaction. The context (clinical document vs consent document) is simply a difference in the query parameters. And retrieving the consent document it-self is done just like any clinical document (see 4 in the figure at the right). 

Lets start with the most outside view:

• A System (EHR, PHR, etc) queries the HIO for all longitudinal documents on Patient X.
• The HIO looks in the registry and compiles a response with all the documents matching the query
• The HIO returns the response to the query back to the System that made the request.

This is Classic XDS, and from the view of the "System"; this is exactly what it will do. 

Policy-Enforcing-Registry:

The Magic is that the HIO is actually a complex system: The system that actually receives this query is the new uber-Registry -- Lets call it a "Policy-Enforcing-Registry". 

1. This Policy-Enforcing-Registry will be intercepting the query and 
2. doing some initial Access Control decisions. Very much like XACML is modeled with a PEP/PDP. 
3. Of the Access Control decisions that this  Policy-Enforcing-Registry does, it needs to 
1. determine what the current state of consent is. It can do this by it-self becoming a Document Consumer actor, and formulating a very specific query for ‘consent’ documents on Patient X.
2. Depending on the response and the information in metadata, and the information cached; it 
3. might need to also be a Document Consumer actor and pull the consent documents found from the Repository that it exists in, as defined by the metadata. 
4. Ultimately it will determine what the consent rules are, along with all the other various rules in the HIO (e.g. Role-Based-Access-Control, Break-Glass, Organizational-restrictions, etc). 
5. At this point the Policy-Enforcing-Registry simply knows if it should reject the original Query, or allow it to partially happen. 
1. If the patient has not given positive consent, then an audit log should be recorded; and the original query returned with a failure of some kind (Some HIO like to say that consent is missing, other HIOs like to act like the patient doesn’t exist). 
6. If the query should be allowed, the Policy-Enforcing-Registry will allow the original query to be executed; but intercept the response. 
7. It now needs to inspect the response to determine if there is specific concerns between the access control rules and the content. 
8. It might need to remove some or all of the returned metadata entries. 
9. It can then return the legitimate results to the original clinical system; possibly attaching constraints/obligations.

Now this is a full scenario; and our scenario in S&I Framework - Data Segmentation for Privacy  is just a query for consents; so this is just the very inside set of queries; the ones I describe as the Policy-Enforcing-Registry acting as a Document Consumer. I outline the whole thing as it is important to see the overall context as we will surely get pulled down that rabbit hole. Note that I also don't talk about Patient Identity, which ultimately at the HIO level needs to be factored -- designed -- into this system.

Key notes for understanding the Diagram

• Yellow circles show sequence of transactions.
• transactions 1 and 5 are broken into two parts simply to show time passing between the time the EHR sends their request and the time they get back their response to that query. This is all just one XDS transaction – “Registry Stored Query”. As far as the EHR is concerned it has just done a simple XDS transaction. It is totally unaware of all the processing happening inside the Policy-Enforcing-Registry.
• Transaction 2 and 4 are also just XDS transaction “Registry Stored Query”.
• Transaction 2, 3, and 4 are shown as double-head arrows because there is no need to show time passing between the request and the response. So for this diagram they are considered combined for simplicity.
• the Repository could exist inside or outside the Policy-Enforcing-Registry box.

Conclusion:

Yes, the XDS profile was designed with this Policy-Enforcing-Registry in mind; but it is a systems design that puts the parts together. IHE only defines profiles to the point of assuring Interoperability, never including all possible systems that  could be designed using those profiles.

Updated Noon March 19th

During the S&I Framework discussion of this approach, the question came up if there is a strict adherence to the sequence of events and definition of the transactions. Underlying this question could be many things, but I know that one of the approaches is to leverage XACML concepts. I offer the following diagram that integrates XACML policy repository into the picture without changing the XDS transactions. Essentially what this new diagram shows is that there is some task that is responsible for adjudicating the policies as they are created or updated; thus when the EHR asks for clinical data the policies are much quicker and more simple to execute.

I left the yellow sequence numbers the same where the transaction didn't change. Clearly they no-longer represent the order of events. There are now two distinct flows:

Resolve Policy

1. Based on a new policy being registered, or some other 'event' the 'Resolve Policy' service would use the #2 "Query (consents)", and #3 "Request Consent Documents" 
2. Pull the existing policies from the XACML Policy Repository using #6
3. Resolve these new policies with the existing policies
4. Push the updates back into the XACML Policy Repository using #6

Real-time Query for Clinical Content

1. Query request for clinical content #1
2. Access Control engine looks up existing policies from XACML Policy Repository using #7
3. If access should be granted then the Query request for clinical content is reflected in #4
4. The results is inspected relative to the existing policies
5. The results appropriate is returned.

There is no lesser or greater functionality, although this model is more likely to execute fast for the Real-Time Query. To me this model is exactly consistent with the above model, it is just optimized for performance; something that I would expect good service developers would do anyway.

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

Meaningful Use Stage 2 has made mostly minor adjustments to the security and privacy capabilities, but critical and welcome ones. They have added detail to the Security/Privacy Audit Logging, references to FIPS for cryptographic algorithms, synchronization of time clocks, clarified some old criteria, and defined a patient accessible accounting report. These are all things that have been recommended in many other environments including IHE, HL7, DICOM, HITSP, and previous EHR certifications. These are also aligned with guidance and requirements from other regional and national programs. Overall a system that has been designed well to handle security should be in good shape.

Detailed DiscussionI provide more details below. Here is the text from the NPRM of interest to Privacy and Security:
 

7. In § 170.210 republish the introductory text and add paragraphs (e), (f), and (g) to read as follows:

§ 170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.

The Secretary adopts the following standards to protect electronic health information created, maintained, and exchanged:

* * * * *

(e)  Record actions related to electronic health information, audit log status, and encryption of end-user devices. 

(1) When EHR technology is used to create, change, access, or delete electronic health information, the following information must be recorded:

(i)    The electronic health information affected by the action(s);

(ii)   The date and time each action occurs in accordance with the standard specified at § 170.210(g);

(iii)  The action(s) that occurred;

(iv) Patient identification; and

(v)  User identification.

(2)  When the audit log is enabled or disabled, the following must be recorded:

(i)    The date and time each action occurs in accordance with the standard specified at § 170.210(g); and

(ii)   User identification.

(3)  As applicable, when encryption of electronic health information managed by EHR technology on end-user devices is enabled or disabled, the following must be recorded:

(i)    The date and time each action occurs in accordance with the standard specified at § 170.210(g); and

(ii)   User identification. 

(f)   Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2 (incorporated by reference in § 170.299).

(g)  Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized following Request for Comments (RFC) 1305 Network Time Protocol (NTP) v3 (incorporated by reference in §170.299) or RFC 5905 NTPv4 (incorporated by reference in §170.299).

-----------------------------------------

§ 170.314(d) Privacy and security. 

(1) Authentication, access control, and authorization. 

(i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and

(ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the EHR technology.

(2)  Auditable events and tamper-resistance.  

(i) Enabled by default. The capability specified in paragraph (d)(2)(ii) of this section must be enabled by default (i.e., turned on) and must only be permitted to be disabled (and re-enabled) by a limited set of identified users.

(ii) Record actions. Record actions related to electronic health information, audit log status and, as applicable, encryption of end-user devices in accordance with the standard specified in § 170.210(e). 

(iii) Audit log protection. Actions recorded in accordance with paragraph (d)(2)(ii) must not be capable of being changed, overwritten, or deleted.

(iv) Detection. Detect the alteration of audit logs.

(3) Audit report(s). Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the elements specified in the standard at § 170.210(e).

(4) Amendments. 

(i) Enable a user to electronically amend a patient's health record to:

(A) Replace existing information in a way that preserves the original information; and

(B) Append patient supplied information, in free text or scanned, directly to a patient's health record or by embedding an electronic link to the location of the content of the amendment.

(ii) Enable a user to electronically append a response to patient supplied information in a patient's health record.

(5) Automatic log-off. Terminate an electronic session after a predetermined time of inactivity.

(6) Emergency access. Permit an identified set of users to access electronic health information during an emergency.

(7) Encryption of data at rest. Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion.

(i) If EHR technology manages electronic health information on an end-user device and the electronic health information remains stored on the device after use of the EHR technology on that device has stopped, the electronic health information must be encrypted in accordance with the standard specified in § 170.210(a)(1). This capability must be enabled by default (i.e., turned on) and must only be permitted to be disabled (and re-enabled) by a limited set of identified users.

(ii) Electronic health information managed by EHR technology never remains stored on end-user devices after use of the EHR technology on those devices has stopped.

(8) Integrity. 

(i)  Create a message digest in accordance with the standard specified in § 170.210(c).

(ii) Verify in accordance with the standard specified in § 170.210(c) upon receipt of electronically exchanged health information that such information has not been altered.

(9) Optional—accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in § 170.210(d).

 ----------------------------------------------

§ 170.202(a)(2)(ii) Patient accessible log. 

(A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section, the following information must be recorded and made accessible to the patient:

(1) The electronic health information affected by the action(s);

(2) The date and time each action occurs in accordance with the standard specified at § 170.210(g);

(3) The action(s) that occurred; and

(4) User identification. 

(B) EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at § 170.314(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.

 ---------------------------------------------------------

§ 170.210(g) Synchronized clocks:The most referenced inside of the NPRM, and the most important of these changes is the synchronization of time clocks. This has been called for by IHE since 2002. The only addition that ONC did was to specify that NTP v4 is also acceptable. I think this is more because they feel the need to point at the latest version. The only useful new thing in NTPv4 is support for IPv6. IPv6 is going to be critical, but is likely a decade off. The US federal government has been mandating it since 2003. IPv6 will likely show up first for mobile devices on cellular networks. Having support for NTPv4 and IPv6 is a good thing, eventually, but not too urgent. 

Supporting NTP in an EHR is also the easiest thing to implement. It is already inside all modern operating system platforms in some form, and most have it turned on by default. The responsibility of the EHR technology is to simply use the system clock for recording when things happen including using it in the clinical documents.

The expectation is that the practicing organization will choose a single time source and configure all their systems to synchronize with that. This is often times transparently done in cases where Active Directory is used as the Microsoft technology automates this.

The comment to both ONC and CMS: First I very much back the use of NTP, I just don't know that it needs to show up in EHR certification criteria. The reason is that it is already in every operating system. I know that including it in the EHR certification does make sure that it is configurable and the time is used. But I suspect this is already true today. I would encourage CMS to add the use of NTP to the operational side. This is where the failure is more likely to be. If NTP stays in the certification rule, then it should be noted as not needing to be tested. Testing this is very... time consuming... Not because it is hard, but because time must pass in order to prove that it is working. This is simply not worth the amount of wasted time spent certifying, to have each EHR technology waiting idly for time to pass, while holding up test resources. 

§ 170.210(e) Record actions related to electronic health information, audit log status, and encryption of end-user devicesThis section is simply adding some more detail to a few specific auditable events and what minimally should be recorded when these events happen. A well designed security audit log system would have captured these events anyway, as there is not new events or new detail. These events have been included since 2004 in IHE-Audit Trail and Node Authentication (ATNA) and the standards that it is based on. 

The motivation for adding these events, tied to each group: (1) to enable good security surveillance and assist with an Accounting of Disclosures and an Access Report, (2) protect the audit log against administrators, and (3) catch someone disabling encryption on end-user devices. Items (1) and (2) are simply common security audit logging. A system that has implemented the audit logging profile from IHE-ATNA would be compliant with these requirements.

Item (3) is the least useful and should be removed. The most likely scenario for encryption of data-at-rest is to use a totally transparent off-the-shelf solution. The EHR would not be involved in this and couldn't possibly know that encryption of data-at-rest is being used. I have written an extensive blog article on this: Encryption is like Penicillin. 

This is just one example where ONC is reacting to a very large number of Breach Notifications that are due to end-user devices getting lost or stolen with large numbers of patient records and no encryption. This is not a case where encryption was present and turned off, these are cases where someone simply never did their HIPAA mandated risk assessment and determined that encryption really was a reasonable and appropriate thing to do. So the violation was with HIPAA security rule, not with technology. The prolog does speak to this. I think that making this an auditable event is a waste of ink.

More confusing is the way they are describing how security audit logging will be handled for EHR Modules vs EHR Complete. I simply can't quite figure it out. Seems to me that if a piece of code, modular or complete, is responsible for allowing a 'security auditable event' to happen, that it should be responsible for recording that it happened. This is the model defined in the IHE-ATNA profile, and through the SYSLOG standard that it uses for transport all of the events end up in one location, the Audit Record Repository. In this way many modules record events that are all able to be sorted, filtered, alerted on, and reported on. The result is a distributed system with a complete Accountability supporting Accounting of Disclosures.

The comments to ONC on this would be to remove (3). I get why they want it, but it is an event that will never be detected by an EHR. The underlying problem of mobile devices getting stolen is an operational problem that CMS has covered well through pointing at HIPAA Security rule. 

I would like to encourage IHE-ATNA, but I am ok with that coming in Stage 3; while I encourage everyone who will listen to do IHE-ATNA as their solution to all Security Auditing requirements.

§ 170.210(f) Encryption and hashing of electronic health informationThis item is here to clear up confusion caused by Meaningful Use Stage 1 which included specific algorithms. The goal of this new item is to indicate that Meaningful Use and Healthcare as an industry should simply look to NIST/FIPS for the algorithm endorsements. This is a good thing as it puts the decision in the hands of experts in cryptography, and opens up the number of algorithms to a more reasonable choice.

This should make it more easy to simply leverage off-the-shelf security. Typical network, object, and system encryption tools follow the recommendations of NIST/FIPS.

It is good to see that in the prolog (Page 32 in my copy) of the NPRM they explain that because the Transports defined include Security (Encryption, Integrity, and Mutual-Authentication), that it is unnecessary to further elaborate on transport security. This is good, but does put in question all the other non-specified transports. The IHE-ATNA profile handled this differently saying that once you include "Secure Node" or "Secure Application" that the system is obligated to include security for ALL network communications that carry PHI, regardless of if they are IHE compliant network communications or not. This is just the 'capability' to secure the communications, but it is a clear indication that any non-secured communication is a vector for attack.

They reinforce this with more comments on page 49 "…designing EHR technology to meet the following standards: IETF RFC 2246 (TLS 1.0) and SMTP/SMIME as well as implementation specifications such as NIST Special Publication 800-52 ("Guidelines for the Selection and Use of TLS Implementations") and specifications developed as part of nationwide health information network initiatives. ". This is also a reference to the Transport standards that I covered here.

What is still missing is guidance around Key Management. This is a major issue with Encryption and Digital Signatures, the keys must be managed very carefully. With bad key management comes bad security.

The comments to ONC are that this is a good job, please add comments that Key Management must also follow the recommendations found in FIPS 140-2.

§ 170.314(d) Privacy and security. I am not going speak to everything in here as most of it is clear.

I have a minor concerned with their § 170.314(d)(2) "Auditable events and tamper-resistance". At some point audit logs need to be purged. This is only done after they have been fully analyzed and all value (security and privacy surveillance) has been gotten out of them. But ultimately the audit log must be purged or it will become far larger than the EHR database it-self. My comment would be to recognize that there are times when authorized purging of the audit log is appropriate.

I have another minor concern with § 170.314(d)(6) "Emergency access". They define a term using the term it-self. What is an 'Emergency'? We have been developing an understanding of "Break-Glass", that is not the "Emergency Room", as the emergency room is a place where specific individuals are assigned to work and these people hold the functional role of emergency room doctor. So are they talking about a wide scale disaster like Katrina or Tōhoku. See some lessons learned from them. My comment for ONC is to remove this item. The concept of 'Emergency access' has not been clear since HIPAA, it needs some clarity before we can start requiring support for it.

I have lots to say about § 170.314(d)(7) "Encryption of data at rest", and have said it in my article Encryption is like Penicillin. What I have to say is very supportive of this item, then again I was very much engaged in the writing of this specific item.

§ 170.202(a)(1&2)(ii) Patient accessible log. This is the start of a real Privacy Access Report. It is clearly leveraging the audit logging, and is a well written description of the expectation for an Access Report. How this Report gets created is left to the creativity of the EHR designer. I could imaging it being only created upon demand, but that would require that the audit log be kept for a very long time. I could also imaging it being created on an annual basis, thus allowing the audit log to be purged.

Conclusion

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. 

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.

A EHR that has been designed with Security and Privacy should easily be able to support these and exceed them in ways that will make the healthcare provider Security Office and Privacy Office very happy. I predicted these changes in December Predicting Meaningful Use Stage 2 Security, and I think I did quite good with my predictions. The prediction does include some more useful details too.

See my other comments Meaningful Use Stage 2 seems to support Security, Privacy, and HIE Transport

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.