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

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.