Thoughts on Goal III of the ONC HealthIT Strategic Plan

On Friday, March 25, ONC released the Federal Healthcare IT Strategic Plan 2011-2015. I will constrain my observations to Goal III, as I think people like Keith Boone will have the others covered well.

Goal III: Inspire Confidence and Trust in Health IT

• This section is not large (7 pages), seems to want to say all the right things, but falls flat in a few places. I like the attention to openness and transparency, as these are the prime ways to get 'Confidence and Trust'. When things happen that can't be explained, people will loose trust. When things happen and no one is held accountable, people will loose trust.
• "Transparency" is said 8 times in these 7 pages. I like that, I want to see more transparency from HHS/ONC...

III.A. Protect confidentiality, integrity, and availability of health information III.A.1 Promulgate appropriate and enforceable federal policies to protect the privacy and security of health information.

• This is a nice solid section. There are some specific items listed that are going to make the regulations better. More clarity, more specifics.
• I hope they do keep the regulations Risk based. Many people complain about the HIPAA Security rule being too vague and allowing items to be 'addressable'. This is a recognition that not all operational environments must implement the same technology, procedure, or physical controls. The HIPAA Security rule is primarily a Risk based rule, with guidance on the areas to be worried about. Risk models are always the best way to address Security. 

III.A.2 Enforce existing federal privacy and security laws and maintain consistency with federal confidentiality, policy.

• An important tool to get better security and privacy is to increase the punishment for poor security and privacy violations. This is a huge win for Privacy and Security, nothing like a little punishment of your peers to get you to think more closely about your own house. The more open and transparent this is, the better. See: USA healthcare breach notifications. 

III.A.3 Encourage the incorporation of privacy and security functionality into health IT.

• I very much agree with the title. I very much disagree with the substance behind this title. There are many frameworks for Security capability/functionality. We do NOT need to invent a new one. We simply need to apply those that exist. I know that those in Healthcare think that healthcare data is so special, but from a security perspective it is not special. Re-invention comes with unintended consequences. We should stop thinking we need to reinvent security for healthcare. I am frustrated at being involved in 6 re-inventions so far: HIPAA, NIST 800-53, CCHIT, EHR Functional Model, HITSP, and now Meaningful Use. See: Meaningful Use Security Capabilities for Engineers

III.A.4 Identify health IT system security vulnerabilities and develop strategic solutions.

• My initial reaction to this was not printable. We really don't need ONC trying to analyze security vulnerabilities and defining how to fix them. I don't think that the spirit of this section is at the same scope as I was initially thinking (SQL injections, buffer overruns, cross-site scripting). I think what they mean is high level controls, such as identifying that we need to have a consistent way (policy, guidance) to address an emergency mode that exists when a natural disaster takes out the local infrastructure (Katrina, Fukushima). 

III.A.5 Identify health IT privacy and security requirements and best practices, and communicate them through health IT programs.

• I am worried that the guidance they give will be too specific and not recognize risk based application.  For example: The guideline to encrypt everything, without a clear understanding of the scope and appropriate application in a risk assessed context has caused much unnecessary churn. Overall this vague guidance that doesn't recognize the scope and risks would be bad for Health IT.

III.B. Inform individuals of their rights and increase transparency regarding the uses of protected health information
III.B.1 Inform individuals about their privacy and security rights and how their information may be used and shared.

• I welcome this. I think that patients are uninformed, and too often the lack of information drives fear. The hard part is that this is a tough audience. I have seen the marketing power of HHS/ONC in their current marketing of the Direct Project. 

III.B.2 Increase transparency regarding the development of policies and standards related to uses and sharing of protected health information.

• I agree transparency is critical to building trust

III.B.3 Require easy to understand reporting of breach notifications.

• I agree empowering patients to monitor what is happening to their data is a critical part of trust

III.C. Improve safety and effectiveness of health IT
III.C.1 Provide implementation and best practice tools for the effective use of health IT.

The short statement given sounds really good. But the text found in section III.C.1 is frightening. It is clear that they see the Vendor community as the problem. They speak over and over about helping avoid legal issues, avoiding workflow redesign, avoid ongoing maintenance and upgrades, and legal concerns related to vendor contract clauses. If this is happening, then I agree it needs to be fixed; but as a prime strategy and veiled in 'safety and effectiveness'? I work for a vendor, and I am poring out endless hours to make this Health IT vision happen. I think I can claim to be a leader and have many peers from GE that are creating this thing called Health IT. Is this the thanks I get?

III.C.2 Evaluate safety concerns and update approach to health IT safety.

• ONC has commissioned the Institute of Medicine (IOM) to conduct a formal study. Why is the IOM looked to on the topic of "Safety"? This seems like the domain of the FDA. I know this is a scary thing to many, but Safety is not rocket science. It is handled through Risk based methods with monitoring and remediation. I would like to see some openness and transparency here too.

III.C.3 Monitor patient safety issues related to health IT and address concerns.

• Monitoring patient safety is critical to achieving patient safety. Transparency to the process is critical to a system that can be trusted. Transparency is hard, so it must be carefully used.
• A second topic covered in this single paragraph topic is that of data integrity, data provenance, and data correction. These are prime use-cases for any data management system. They should not be relegated to a tiny minor component. 

Goal III: Measure
Decrease the percentage of Americans who are very concerned about the security of electronic health records

• The most interesting part about this is that they are willing to admit that they have no idea what the current baseline is. I would suggest that they do actually have a good baseline in the current HHS published Breach Notifications. Is this sufficient, no; But it does exist.

Healthcare use of X.509 and PKI is trust worthy when managed

In todays HIT Standards meeting there is a presentation by the Privacy and Security Workgroup. The presentation includes two topics: "Digital Signature Standard" -- which is really "Digital Certificate Standard" (a typo that keeps coming back; and "Enterprise Level Provider Directories".

The discussion on Digital Certificates should look good to the readers of my blog, as it simply says that X.509 digital certificates and certificate management are the right method to build trust for healthcare. I worked hard to get the group to simply recognize that these are already strong standards, and that healthcare does not need anything special from them. They do recognize that a single strong Certificate Authority would be easy, but recognize that multiple trust-roots is likely to be needed.

The group also recognized that both Direct and NwHIN exchange can use the same technology. A point I made in S/MIME vs TLS -- Two great solutions for different architectures. 

What is very exciting is that the group did come to the conclusion that HHS/ONC should take a leadership role in managing certificate trust, specifically recommending that there be a certificate authority that is available for building a Nationwide Health Information Network (NwHIN) that is cross-certified with the Federal PKI Bridge. The good news on this is that the CA that the NwHIN Exchange uses today is cross-certified with the Federal PKI Bridge. So, I think this simply means continued funding and explicit endorsement of this model. This would make managing trust across the nation 'easy'.

As soon as anyone says that managing trust is 'easy' those in the security domain get worried. This worry is well founded as security is hard. One timely and specifically targeting of certificate management is the "Compromise of SSL Digital Certificates". This news has gotten some people to question the X.509 PKI model, and even the SSL/TLS protocols. In both of these cases the technology are in no way flawed. The technology is still the best technology available today. What is broken is the way that certificates are managed for Internet based Web-Servers. This broken part is very different between Internet based Web-Servers and the way that HIT Standards expect NwHIN to operate.

1) Default - No Trusted Certificates

• The recommendation for the Direct Project is that there are no assumed certificates, that a site explicitly trust certificate roots only when there is known and validated reason to trust.
• In the NwHIN Exchange there is ONLY one Certificate Authority that is 'trusted' by the systems
• In IHE ATNA there is a warning about the need to have a different trust pathway for healthcare than is used for internet web servers (See IHE ITI 2a:3.19.6.1)
• Essentially for Healthcare Information, there should be a totally independent analysis of 'who should you trust'

2) Reality is that multiple trust-anchors are needed

• Direct fully recognizes this, and the report out showed this. Indeed it recognizes that sometimes in e-mail communication one trusts specific certificates and not necessarily all certificates issued from a Certificate Authority.
• The participants in the NwHIN Exchange will likely need to have more than the one Certificate Authority in order to support the local connections.
• IHE specifically recognizes both of these as fact. And points to an excellent white paper from NEMA

This is a good start, but does not address the very fact that no matter how carefully one has evaluated 'who should you trust' and mistakes can happen. Thus there needs to be a strong mechanism to deal with mistakes. Certificate Revocation is a mature field for checking if a specific certificate has been revoked. This mechanism is used when a certificate is determined to have been exploited. This mechanism checks with the Certificate Authority to either get a list of certificates that have been revoked or using an online transaction check that a specific certificate has not been revoked.

3) Certificate Revocation mechanism are needed

• Direct didn't fully specify this, but did include it in the Security Model
• The NwHIN exchange includes certificate revocation
• IHE recommends that systems support both OCSP and CRL mechanisms.
• In all cases a certificate should not be 'trusted' unless it has been fully validated. Full validation does include checking the signature and how it chains to the set of trusted certificates, that the certificate has not expired, and that it is not revoked.

This mechanism is not typically used for root certificates. This is the problem that is being exercised with the current SSL Digital Certificate Compromise, in that there is a Certificate Authority 'Comodo' that had it's infrastructure compromised. Thus there is a need to tell the world that their root certificate needs to be un-trusted. As scary as this situation is, it doesn't happen very often. Given that it doesn't happen very often, there is little energy spent on trying to automate it. Given the breath of 'trust' that all of the copies of Internet Browsers have (the distribution mechanism); this un-trust is a very big problem.

The result is that X.509 and Certificate Management is the right technology for building technical trust for Healthcare. But this does not mean that we can relax and not continuously think about this trust.  We should recognize that the way that Internet Web-Servers is a different management model than we will use in Healthcare. This is the key to why a system that seems broken for Internet Web-Servers should be considered highly secure for Healthcare Information.

Which leads to the second part of the presentation. a topic I covered Healthcare Provider Discoverability and building Trust

HIMSS assembling Risk Analysis Resources

This group is just getting going. They are made up mostly of healthcare providers. There is a Survey on the site that is looking for input on what should be done. I have injected IEC 80001, but need more support to make it stick.

HIMSS Medical Devices & Patient Safety and CE-IT Community Create Systems Risk Analysis Resource Guide Web page
Recognizing the critical need for guidelines that would help healthcare organizations by identifying or providing resources and tools necessary to address the challenge of today's medical technologies, the HIMSS Medical Device & Patient Safety Task Force and the CE-IT Community have collaborated in establishing this site. Here you will find valuable resources that will help to insure that your organization has the information and tools it needs to realize the benefits of today's healthcare technologies while also being prepared to address any of the challenges and vulnerabilities associated with those technologies.

For more about the Medical Devices & Patient Safety Task Force, contact David Collins. For more about the CE-IT Community, contact Christel Anderson.

ANSI and Shared Assessments Launch Initiative to Examine Financial Impact and Harm of Breached Patient Information

This crossed my desk this week, and I jumped on it. I look forward to continue to develop the RISK models, while controlling the Theater. First up, to help the group understand that HARM is not just due to financial impact. This is not news to Medical Device manufactures, or Healthcare Providers; but it does seem to be a specific focus of this ANSI group.  This broader definition of HARM has been a big discussion in the IEC/ISO 80001 discussions, and even there it isn't fully understood.

ANSI and Shared Assessments Launch Initiative to Examine Financial Impact and Harm of Breached Patient Information

http://www.ansi.org/news_publications/news_story.aspx?menuid=7&articleid=2835

New York, NY, March 23, 2011 – Healthcare organizations are struggling with two key concerns today: how to protect patient information and how to better understand the financial harm caused when protected health information (PHI) is lost or stolen. A new project – led by the American National Standards Institute (ANSI), via its Identity Theft Prevention and Identity Management Standards Panel (IDSP), in partnership with the Shared Assessments Program and its Healthcare Working Group – has been launched to explore the financial impact of unauthorized PHI access. The goal for the “ANSI/Shared Assessments PHI Project” is to identify frameworks for determining the economic impact of any disclosure or breach of protected patient data.

The ANSI/Shared Assessments PHI Project got underway last week with a meeting of its advisory committee. The initiative brings together professionals from across the industry: data security companies, identity theft protection providers and research organizations, legal experts on privacy and security, standards developers, and others.

This effort will culminate in a report targeted at those responsible for and entrusted with protecting and handling PHI. The report will help inform the healthcare industry in making investment decisions to protect PHI, as well as improve responsiveness if and when this patient information is breached. 

Rick Kam, president and co-founder of ID Experts, is chairing the initiative. “Organizations that are custodians of healthcare data are grappling with how to calculate their risk exposure when PHI is lost or stolen,” commented Kam. “The ANSI/Shared Assessments PHI Project will inform their investment decisions to protect PHI and will provide guidance on how to respond if this data is compromised.”

The group plans to tackle the problem by identifying existing legal protections related to PHI, defining points of compromise in the healthcare ecosystem where there are risks of exposure, and assessing the financial impacts of the disclosure of PHI. A survey is also contemplated to support the fact-finding process.

Industry experts are invited to participate in the next meeting, via a two hour conference call on April 7, 2011, from 12:00 p.m.– 2:00 p.m. Eastern. Interested parties can send an email to idsp@ansi.org to join in the work effort. There is no fee to participate and most of the work will take place via conference call over the next few months.

The initiative is made possible through the generous support of the following organizations: DriveSavers Data Recovery, Inc. (premium sponsor) and Affinion Group, Center for Identity Management and Information Protection of Utica College, Direct Computer Resources, Inc., Europ Assistance USA, ID Experts, and ZOHO ManageEngine (partner sponsors). Additional sponsors are welcome; see sponsorship opportunities.

About ANSI

The American National Standards Institute (ANSI) is a private non-profit organization whose mission is to enhance U.S. global competitiveness and the American quality of life by promoting, facilitating, and safeguarding the integrity of the voluntary standardization and conformity assessment system. Its membership is comprised of businesses, professional societies and trade associations, standards developers, government agencies, and consumer and labor organizations. The Institute represents the diverse interests of more than 125,000 companies and organizations and 3.5 million professionals worldwide.

The Institute is the official U.S. representative to the International Organization for Standardization (ISO) and, via the U.S. National Committee, the International Electrotechnical Commission (IEC), and is a U.S. representative to the International Accreditation Forum (IAF).

About the Shared Assessments Program

The Shared Assessments Program was created by leading financial institutions, the Big Four accounting firms, and key service providers to inject standardization, consistency, speed, efficiency and cost savings into the service provider assessment process. Through membership and use of the Shared Assessments tools (the Agreed Upon Procedures and the Standardized Information Gathering questionnaire), Shared Assessments offers outsourcers and their service providers a faster, more efficient and less costly means of conducting rigorous assessments of controls for security, privacy and business continuity. The Shared Assessments Program is managed by The Santa Fe Group, a strategic consulting company based in Santa Fe, New Mexico.

Trust and the PCAST model

The final step of the PCAST security model overview has haunted me all week. Click on the diagram to see all the steps, but the final step is:

10. After use, system destroys the cleartext and key, possibly retaining the ciphertext.


As explained this step is very typical of a DRM, where the proprietary software is what is being referred to in "system destroys the cleartext and key". It is only with a proprietary system that the DEAS can be sure that 'the system' will destroy the cleartext and key. This is why DRM systems often come on closed systems, or software that needs to be updated very frequently. Or why some systems have installed rootkits onto the unsuspecting host. This is all done to assure the DEAS that the system that is receiving the decryption key will destroy the data after the specific use and discard the key.

I will now bring up the medical record point I made, which is also hinted at in John Halamka's Blog:

Also, it will be interesting to see if clinicians will accept the idea of saving data from healthcare information exchanges in encrypted form, since if the provider uses the information to make a clinical decision, they'll need to have that information in the health record as documentation supporting that action.

The individual making a clinical decision based on the information they have received have a requirement to maintain a copy of the data they used. Imagine a malicious patient, one seeking narcotics, they could have data available that clearly showed that they have a chronic condition that requires very strong pain killers. The doctor sees this, and prescribes the narcotics. If this doctor does not keep a readable copy of this evidence, imagine a time when that doctor is investigated for over-prescribing narcotics. Without the evidence this doctor can't justify his actions. Indeed the malicious patient could replace the data with normal data (Clearly this malicious patient is no-longer seeking drugs, but seeking damage to the doctor). These are the stuff of 'medical records retention'.

Another interesting aspect is how is this system to be used to transfer a legitimate and reusable copy from the Provider who wrote the Medical Summary to the Patient themselves? Clearly the Patient needs to be able to take control of the object. They must be allowed to republish or resend it as they need. So, somehow the system needs to allow the Patient to receive a usable plaintext copy. Or does this system presume that the original Medical Summary is wrapped in the Provider envelop and when republished by the patient also wrapped in the Patient envelop? I can see how this can be seen as useful from a control perspective, but from the perspective of failure-modes, this worries me.

So, I predict that eventually step 10 will go away. That Medical Records Retention requirements and Patient Empowerment will allow the receiving individual to keep a copy of the data.  Once we remove this step, I will ask what is left of this whole model. Once we are comfortable that the receiving individual is indeed a legitimate receiver of the data and can keep a copy, then why is all the complexity of the DEAS (aka DRM) kept? Through Policy we will determine that ultimately all transactions need to have Access Controls and Audit Controls applied. Once we apply access controls to all transactions then step 7, 8, part of 9, and 10 goes away, that is we remove the SINGLE-POINT-OF-FAILURE. See Access Controls around the PCAST use-cases

Back to the PCAST security model steps:
1. A user authenticates him/herself to the local system, within the context of an authorized role.

• Yes, the user must be authenticated to the local system. It is ultimately the local system that is used to integrate the HIE discovered information with the local information. This is true of an EHR or a PHR. So, the local system very likely has already sensitive information in it, and will eventually have more.
• See IHE EUA and PWP

2. On behalf of authenticated and authorized user and role, local server sends metadata search parameters to the Data Element Access Service (DEAS).

• Yes, this is a Record Location step
• See IHE XCPD, XCA, and XDS
• Context of transaction
• IHE XUA (SAML identity assertion)
• User Identity
• Role of user at requesting institution - normalized to HIE policies
• Method used for authentication - relating to level of assurance
• Purpose of Use - what is the requester of the transaction going to do with the data
• Consent identifier - pointer to consent/authorization that the requester believes is relevant
• etc
• IHE ATNA - Identity of the system requesting 
• This is used to keep non-trusted systems out 

3. The DEAS mediates the request and searches metadata as permitted by privacy metadata within context of authorized role sent with query. The transaction is recorded in audit trail.

• Privacy metadata - Each Document entry in XD* includes a 
• Confidentiality Data Classification
• Author - or publisher of the data (including institution identity)
• Identity of the Patient that is the subject of the document
• Unique ID of the document (which might be called out in a privacy constraint - segmentation)
• type of document - from a clinical context, but related to privacy policies
• practice setting - specialty of the clinical organization that published it
• dates of service - in case the patient wants to block access to a specific time period

4. The DEAS returns a data locator list (Uniform Resource Identifiers) resulting from metadata search.

• Typical XDS or XCA response. 

5. The Local server requests data from URIs returned from DEAS.

• Typical XDS or XCA Document Retrieve transactions - Request
• Transport secured by IHE ATNA - Mutually-Authenticated TLS
• This enables the Repository to REJECT any request from a non-trusted system
• User Identity is also provided in XDS or XCA 
• This enables the Repositories to do additional Access Control checks and 
• Audit logs to include user identity. 

6. The data storage location server mediates the request and returns encrypted records to local server.

• Typical XDS or XCA Document Retrieve transactions - Response
• Transport secured by IHE ATNA - Mutually-Authenticated TLS
• Yes, they are encrypted by TLS 
• In theory IHE ATNA - Web-Services - End-to-End security can encrypt the result specifically for the user identified in the XUA assertion. This is simply not doe due to complexity and trust.
• In theory the Document it-self could be encrypted using some key management not yet thought of. This is being profiled this year by IHE.

7. On behalf of an authenticated and authorized user and role, the server sends a DEAS request for encryption key for each data element provided.

8. The DEAS mediates the request and retrieves the key as authorized from key management service. The transaction is recorded in the audit trail.

9. The DEAS returns the key to local server, along with digitally signed privacy preferences

• Privacy preferences are encapsulated in IHE BPPC, and can be digitally signed by the IHE DSG profile (any document can be digitally signed by IHE DSG profile)
• The DEAS is not referring to the same method as IHE BPPC, but rather how the DRM content package includes the policy of the content, and any additional obligations can be conveyed by the key discovery method. 

10. After use, system destroys the cleartext and key, possibly retaining the ciphertext.

So, it is this point that I would like to start the discussion. What part of the holistic picture in the DEAS are security and privacy principles that we can compare with existing solutions? A Transparent analysis is needed.

Access Controls around the PCAST use-cases

John Halamka posted Use Cases for Health Information Exchange discussed by the PCAST Workgroup. Keith did a fantastic job of laying out the IHE profiles that support these use-cases. I could add a few tweeks to Keiths details, but I think they are good enough for now.

What I want to cover is my concern with the way people are perceiving that PCAST wants to combine the Metadata about the Patient and Clinical Content; with the Access Control information.

The Diagram that John Halamka includes in his blog shows 10 interactions. Some of these interactions are retrieving clinical information, some are retrieving security information. I am not going to repeat the details here, they can be found on John Halamka's blog.

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

My first observation is that this model is very much like the failed Digital Rights Management industry has tried to propose for Music, Video, and such. I am very clear that I think that DRM as it is implemented today is a failed solution (See: Healthcare should join OASIS Privacy Management Reference Model (PMRM). That is not to say that there might not possibly be ways to make it work in the future. I do however see some major problems with using DRM in healthcare.

The promise of DRM:

• DRM promises to provide that any object that is protected by DRM will be protected all the way to the ultimate use, and thus be protected against any uses in the middle or secondary uses beyond the intended use. 
• DRM promises to give the Patient a strong expressive policy language that allows the patient to indicate the appropriate uses and the obligations around those appropriate uses (such as must now save a copy, or can't print).
• DRM promises that if the Patient changes their mind, these changes can be retroactively applied to all copies of the object. This is because all accesses to the object must be mediated by the Rights Authority.
• I am sure there are others

These all sound very good to Patients. BUT, the reality of DRM is:

• This model requires a SINGLE Rights Management authority that 'knows all'. 
• This Single Right Management authority is a single-point-of-failure
• This Single Rights Management authority understands only ONE authority
• Where in healthcare there is arguably equal rights between the Patient who the data is about, and the Doctor who created the data and is held medically responsible for the accuracy
• This Single Rights Management authority is today - Proprietary
• Yes, there are standards for the envelop policy
• Yes, they use standards based encryption
• But the Key-Management and the method used to unlock the data is proprietary
• Where DRM has been used, it has been cracked within HOURS

I will repeat, I don't think that the promises of DRM could never work for Healthcare. I am just saying that the current state-of-the-art is proprietary and has a bad single-point-of-failure.

This is not my opinion alone (this text lifted from Wikipedia section on impossible-task):

Bruce Schneier has written about the futility of digital copy prevention and says it's an impossible task. He says "What the entertainment industry is trying to do is to use technology to contradict that natural law. They want a practical way to make copying hard enough to save their existing business. But they are doomed to fail."^[76] He has also described trying to make digital files uncopyable as being like "trying to make water not wet".^[77] The creators of StarForce also take this stance, stating that "The purpose of copy protection is not making the game uncrackable - it is impossible." ^[78]

Both the Association for Computing Machinery and the Institute of Electrical and Electronics Engineers have historically opposed DRM, even going so far as to name AACS as a technology "most likely to fail" in an issue of IEEE Spectrum.^[79]

------------------------------------------------------------
My Second observation is that any good Security Model will separate the Security Layer from the Content. Indeed this is what IHE has done in the profiling of the Web-Services "Security" layers in the IHE-ATNA + IHE-XUA; as independent from the Query and Metadata layer in XDS, XDR, XDM, XCA, XCPD, PIX, PDQ; and the Content Layers in all the various Document Content profiles such as XPHR, XDS-MS, XDS-SD, etc. 

An important part of the IHE design is that it is totally agnostic to the Document Content, it can carry IHE defined content just as well as it can carry content that you would never see IHE ever define. I can take this to an extreme to say that the IHE XD* transactions can indeed even carry content that is wrapped in a DRM wrapper.

Just as important is that the IHE design is totally agnostic to the actual policies that would be enforced. We have taken great care to assure that all transactions can be rejected because of an access control rule. There is NOTHING that MUST be allowed. This enables policies that might allow everything, but also enables all colors of policies between everything and nothing. This allows us to leverage a large body Healthcare Access Controls standards. 

The design is also very sensitive to the way that Healthcare Information is created and used today. The model for XDS has ONE Registry (that can be federated through XCA). This Registry knows ONLY the metadata about the documents that have been published. It does NOT have access to the clinical data. There are MANY Repositories, and likely very close to the document source if not the actual document source (e.g. EHR). The vision was that each healthcare providing organization would likely want to keep control of their clinical data (documents) right up till the time they are used. This means that the original publisher controls the clinical data for the life of the data, it is not given up to the Central Registry. This said, it is also recognized that once data has been copied to the Document Consumer, there is a copy at the Document Consumer. This may seem unwanted, but because of Medical Records Retention Regulations this is necessary.

And finally, there is NOTHING in the architecture that says that Document Sources, Document Repositories or Document Consumers must be a Healthcare Providing Organization. A standalone PHR could very well be a Document Source, Document Repository and Document Consumer. In this way the PHR would be a full participant in an Health Information Exchange (HIE).

All of the transactions shown can have access controls enforced on the client, server, or both. I speak of this a little bit in Access Controls on Clinical Decision Support. I know that I need to expand on this more fully in a post later. 

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

I am very concerned about interpretations of the PCAST report that are overly specific and overly prescriptive (See also previous post: Data Objects and the Policies that Control them). I caution those looking at PCAST to look at it as a set of principles. Apply these principles to the currently available solutions using a transparent and open evaluation.

Access Controls on Clinical Decision Support

CDS is a specifically difficult area of healthcare to enforcing Access Controls, inclusive of Role-Based-Access-Control and specifically concerning Patient Privacy consent and authorizations. First lets consider what Clinical Decision Support (CDS) does. This direct from Wikipedia (today :-)

Clinical decision support system (CDSS or CDS) is an interactive decision support system (DSS) Computer Software, which is designed to assist physicians and other health professionals with decision making tasks, as determining diagnosis of patient data. A working definition has been proposed by Dr. Robert Hayward of the Centre for Health Evidence; "Clinical Decision Support systems link health observations with health knowledge to influence health choices by clinicians for improved health care". This definition has the advantage of simplifying Clinical Decision Support to a functional concept.

I understand that a CDS engine includes a large set of medical decision rules (e.g. drug-to-drug adverse reaction checking), that are applied to the patients longitudinal medical record to assist with providing safe and appropriate care. The CDS might be engaged by Computerized Physician Order Entry (CPOE) to determine if a new treatment regiment would have any negative effects based on the longitudinal record of the patient. 

Clearly when there is a need for unspecified and unfettered access to the longitudinal record there is suspicion that CDS and privacy controls are going to collide.  The good news is that members of the HL7 CDS workgroup have decided that although their current timeline didn't include Security or Privacy; they should engage the Security Workgroup and use the Cookbook for Security Considerations... eventually... So, It might not be fully assessed in the next ballot, but there should be the placeholders.

Scott  Bolte is a member of the CDS workgroup, a peer in GE Healthcare, and former security geek. He writes:

"In the privacy world, once data has been divulged to another system/user, you must assume it has been disclosed and control over it lost. In the CDS world, especially to assist with a diagnosis, it will be common to request vast amounts of data to see which hypothesis best matches the observations. As a result, a CDS query may disclose a patient's entire medical record, and trigger corresponding audit trails.

Even if we assume that the CDS is a trusted system (a dubious assumption), and that audit entries will be made only for data elements that were relevant in the end, it is still easy to maliciously extract data. For example, if you want to see if the patient is on drug X, simply make a CPOE query that includes the contraindicated drug Y. Even without revealing the patient is on X, the rejection of Y will let you draw that conclusion.

The typical security model for CDS probes for all longitudinal data would include the identity of the requesting user, and thus the sources of data can restrict the data they return. This security model makes it difficult to determine if there is a potential need for 'break-glass', a form of privacy override.

I found it interesting that Scott  included both the use-case problem and covertly included hints to a solution… If the CDS can determine which parts of the record were used to create its output, that is a huge positive step.  Clearly CDS will need to pull vast amounts of information from the longitudinal record much of it not relevant. This not relevant information does not need to be considered 'disclosed' if it is only seen by the CDS automaton (yeah, some will argue). 

When the CDS determines the specific data that is going to be used in the resulting output of CDS, this can be indicated to the source so that an appropriate Accounting of Disclosures can be recorded. This might mean that the initial probes by the CDS are marked with a specific PurposeOfUse that is only authorized by the CDS identity authentication (I didn't find this PurposeOfUse in the draft I have of ISO 14265); whereas a different PurposeOfUse (more classic PurposeOfUse=1.0.14265.1.1) and identity of the requesting user is used a second time for those objects that are impactful to the CDS decision. A potential

The CDS can also back-track to determine if those who would receive the output of the CDS would have access privileges as well as privacy authorization to the data used (Access Controls). Thus there could be a CDS decision that can’t be returned even if the CDS could have said something. This is a very uncomfortable position for people to think about, but we must honor the wishes of the patient. There are regions where the patient’s privacy wishes are held higher than the wishes of the care provider (e.g. Australia where Opt-Out really means Opt-Out). Yet there might be exceptions included in the privacy policy that would allow a CDS decision of some kind, specifically the ability to indicate that information relevant was withheld due to privacy concerns thus enabling a Break-Glass (yes it is a policy decision to expose that knowledge is being withheld).

As with any healthcare information is the fact that the requester of data may not be the only consumer as the result may end up in a report that becomes part of the longitudinal record.

The idea that the CDS is an automaton that is fully trusted is an assumption that all HL7 workgroups would have to make, it is an assumption that needs to be said clearly in the Security Considerations so that others can see that it is a precondition that the implementers must work to achieve. HL7 can't do anything in their specifications to assure that the code written is perfectly secure, nor that the deployment of that is perfectly secure.


So, the first step is to follow the Cookbook for Security Considerations... , and identify the environment and threats.... Sounds like fun to me...

Healthcare Access Controls standards landscape

The following will give an overview of the landscape of Standards development for Access Controls in Healthcare. There is surely more being done in Healthcare Standards, I am sure I have missed something, and there is ongoing work that is not always included here because it is less mature and not really formally published. Given that this is my blog, I have taken license to include more than just access control at times.  I created this as a response to a question by the OASIS PMRM (see below).

OASIS -- http://www.oasis-open.org
The most technically detailed work is happening in a sub-workgroup in OASIS – XSPA. This group has profiles, and works with the SAML and XACML committees to examine the gaps they identify. Please see the XSPA home page on OASIS to understand more.

• OASIS Cross-Enterprise Security and Privacy  (XSPA)
• OASIS Cross-Enterprise Security and Privacy Authorization (XSPA): WS-Trust Healthcare Profile.
• Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare.
• Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare. 
• OASIS Privacy Management Reference Model (PMRM) TC
  
• Providing a guideline for developing operational solutions to privacy issues
• Just starting to form, so they are looking to healthcare as an area needing help

HL7 -- http://www.hl7.org The healthcare specific standards organization HL7 also has significant work available

• Security TC http://www.hl7.org/Special/committees/secure/index.cfm
• Security Domain Analysis Model – With security use-cases
• http://wiki.hl7.org/index.php?title=Security_Use_Cases
• Emergency Access use-cases
• Permissions Catalog – a vocabulary of permissions necessary for RBAC
• Ontology project – Advancement from current Domain Analysis Model and Permissions Catalog
• Etc – see the committee web site
• CBCC TC http://www.hl7.org/Special/committees/homehealth/index.cfm
• Privacy Consent Directive CDA Implementation Guide.
• a structured document specification to exchange signed Privacy Consent Directives.
• confidentialityCode – a common attribute across many healthcare standards used to carry the data sensitivity and confidentiality classification. The vocabulary and understanding of this metadata label is evolving
• SOA - PASS http://hssp-security.wikispaces.com/
• Access Control - http://hssp-security.wikispaces.com/PASS_Access_Control
• Audit Logging - http://hssp-security.wikispaces.com/PASS_Audit
• Architecture Framework - http://hssp-security.wikispaces.com/PASS+Architecture+Framework

IHE -- http://www.ihe.net IHE is only an ‘interoperability’ profiling organization. So they only define interoperability specifications. They don’t get into architecture, services, or implementation details. They have endorsed through their Profiles the use of SAML for identity assertions, and the HL7 XML document for capturing patient privacy consent. They have other more classic security profiles as well. They do have a white paper that examines Access Control space in healthcare explaining how federation and directories are used to bring together the security/privacy context necessary for access control decisions and how that relates to federated enforcement.

• ATNA - This is a comprehensive yet thin profile that indicates that Access Control, Audit Control, and Network Controls are important
• PWP - This is a very thin profile that simply says that for user directory, use LDAP
• EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users inside of an enterprise
• XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions, updated with some options
• DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'
• BPPC - A profile of a document that represents a patient agreeing to a privacy policy (e.g. Consent)
• ENC - new profile being worked on this year - Encryption of documents and removable media
• confidentialityCode - this is NOT a profile, but is a security/privacy concept built into almost all of the healthcare standards.
• De-Identification handbook - this is NOT a profile, but is a document being written this year.
• Cookbook: Preparing the IHE Profile Security Section - handbook used when IHE produces profiles to assure that the profile has examined security/privacy
• HIE Security and Privacy through IHE – white paper explaining how to use the IHE security / privacy profiles to build a health information exchange
• Access Control - White paper examining access controls in healthcare, specifically in a cross-enterprise federated use-cases.

ISO - TC 215 http://www.iso.org/iso/iso_technical_committee?commid=54960 There is also good foundational work from the Healthcare division of ISO. This work is mostly used as reference material.

• ISO/TS 13606-4:2009 Health informatics -- Electronic health record communication -- Part 4: Security
• ISO 17090-1:2008 Health informatics -- Public key infrastructure
• ISO/TS 21091:2005 Health informatics -- Directory services for security, communications and identification of professionals and patients
• ISO/TS 21298:2008 Health informatics -- Functional and structural roles
• ISO/TS 21547:2010 Health informatics -- Security requirements for archiving of electronic health records – Principles
• ISO/TS 22600-1:2006 Health informatics -- Privilege management and access control -- Part 1: Overview and policy management
• ISO 22857:2004 Health informatics -- Guidelines on data protection to facilitate trans-border flows of personal health information
• ISO/TS 25237:2008 Health informatics – Pseudonymization
• ISO 27799:2008 Health informatics -- Information security management in health using ISO/IEC 27002
• IEC 80001-1:2010 Application of risk management for IT-networks incorporating medical devices -- Part 1: Roles, responsibilities and activities
• Etc… 

ASTM E31.25 http://www.astm.org/COMMIT/SUBCOMMIT/E3125.htm
New development in this group has stopped, but some of the documents are still useful as references.

• E1762-95(2009) Standard Guide for Electronic Authentication of Health Care Information
  
• E1869-04(2010) Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health Records
  
• E1985-98(2005) Standard Guide for User Authentication and Authorization
  
• E1986-09 Standard Guide for Information Access Privileges to Health Information
  
• E2147-01(2009) Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems
• E2595-07 Standard Guide for Privilege Management Infrastructure 

Government Initiatives

One of the potential areas where there might be more mature modeling done is in specific countries such as Canada or regions like EU. I know people involved in Canada and EU, but the work is not yet fully public. This is expected to be made public soon.

• Europe -- epSOS -- http://www.epsos.eu/
• Canada -- http://www.infoway-inforoute.ca/
• USA
• Historic – http://www.hitsp.org – Work stopped in 2010
• Capability 143 - Manage Consumer Preference and Consents
• SC108 Access Control Service Collaboration
• TP20 HITSP Access Control Transaction Package
• TP30 HITSP Manage Consent Directives Transaction Package
• Uses IHE BPPC and HL7 Consent
• SC109 Security Audit Service Collaboration
• Uses IHE ATNA
• TN900 HITSP Security and Privacy Technical Note
• Etc…
• Current - http://jira.siframework.org/
• Direct Project – low technology solution to get healthcare providers started sharing healthcare documents
• http://directproject.org/
• Nothing more than an endorsement of S/MIME with a recommendation to use IHE XDM content packaging 
• All Access Controls are considered 'pre-conditions' 
• NwHIN Exchange – Comprehensive Health Information Exchange to cover whole USA
• http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_exchange/1407
• This uses the HITSP work specific to a cross-community exchange
• Many resources at http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_resources/1194
• DURSA 2009 Version for Production Pilots
• Policy for Participation Changes Suspension and Termination
• NHIN Data Use and Reciprocal Support Agreement Amendment Process
• Breach Notification
• Access Consent Policies Production Specification
• Authorization Framework Production Specification
• Consumer Preferences 
• Etc...
• New S&I Framework development
• This is the focus of the primarily web site. No security or privacy yet. 
• Meaningful Use 
• NOTHING useful here - total absence of Access Controls
•  NIST - I know I should put this under USA government initiatives, but these come out of the core of NIST
• NIST IR 7497  Security Architecture Design Process for Health Information Exchanges (HIEs) nistir-7497.pdf
• The Exchange Of Health Information: Designing A Security Architecture To Provide Information Security And Privacy november2010-bulletin.pdf

Conclusion:
So, that is quite a bit... I still think that the IHE White paper on Access Controls is the best overall introduction to the details of Federated Access Controls. I think then the NHIN-Exchange has the most mature implementation of this using the IHE BPPC, IHE XUA and OASIS XSPA.  This is good work, good-enough to get started on. There are known gaps in the area of perfection and a need to mature the space. I suspect that this will take many more years.

Of course my blog is full of discussion of all of these things. I often find myself using the search bar to find these discussions. It feels good when I find I can reuse an old blog post, which is exactly the reason I started this blog.

IHE Patient Care Device White Paper published for Public Comment

This just crossed my desk

IHE Community,

Patient Care Device White Paper published for Public Comment

The IHE Patient Care Device Technical Committee has published the following white paper for Public Comment:

·         Medical Equipment Management (MEM): Cyber Security

The document is available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm#pcd.  Comments should be submitted by April 15, 2011 to the online forums at http://forums.rsna.org/forumdisplay.php?f=347.