Healthcare in the cloud

Michael Koploy has a really nice blog article where he uses the HHS breach notification data to see if there really is a security/privacy problem in Healthcare with using 'the cloud'. His analysis is that the data doesn't prove significant security/privacy problem with the cloud, and might actually say that the cloud is a good place for Healthcare.

In the space of, low hanging fruit, there are far more security/privacy problems with simple theft of highly portable devices. I suspect, and have said the same in past analysis of the HHS breach notification data, that these thefts are simple thefts for pawn purposes. I suspect that the theft has very little to do with the data and everything to do with a cool piece of technology that is worth money. A factor that is simply going to grow with the increase of use of these cool pieces of technology, like the iPad.

Unfortunately the latest security/privacy problems in the internet space (e.g. Sony, RSA, Honda, etc) where cloud services were hacked and the data (e.g. names, email addresses, birth date) were exposed. These cases get people very concerned about the 'cloud'. I think that they should be concerned, but then as Michael points out they should likely be more concerned about those cool pieces of technology that Doctors like to carry around with them.

Much of the concern is simply FUD (Fear, Uncertainty, and Doubt). People see what is happening elsewhere and multiplying that Fear by many factors because the EHR in the cloud would be far more detailed. However I don’t think they really assess just how poorly EHR protection would be in a small-doctor office that has no IT support. Far better to put the task of security in the hands of an expert. Still doesn't automatically make it safe, but that is where sharing best practices like NIST 800-146 Cloud Computing Synopsis and Recommendations. 

NIST 800-146 does a really good job of outlining not just the technology, but also the operational and policy issues.  They have touched on issues I had never thought of. They do a really good job of explaining responsibilities between the cloud subscriber and the cloud provider. I highly recommend that people use this guide. 

French National EHR based on IHE XDS

This just crossed my desk:

The national PHR/EHR, or DMP (Dossier Medical Personnel) based on IHE XDS and 6 other IHE profiles has been technically open since December 17^th 2010.  April 2011 was the official opening with clinical use authorized.  They have now records for about 20,000 patient  and a few hospitals and physician offices connected (20 EMR products have been certified).  They expect to reach between 1 and 2 million patient “dossier” by the end of 2011. 

It is both an “shared EHR” and a “PHR” in one system: patient/professional and professional/professionals share the same system, where the patient that opts-in controls access.
The communication and explanation to health professionals and patients is very well done, I think. 

You will not be able to open your own records, because it requires: (1) a health insurance card (2) an encounter with a health professional (trust and education).
 Even if you do not know French I recommend browsing:
http://www.dmp.gouv.fr/web/dmp/page-accueil where I suggest you select the “professional side”, and start with “Comment ça marche ? ” (how does it work ?).
Simple but clear animation.
http://www.dmp.gouv.fr/web/dmp/professionnel-de-sante/comment-ca-marche Try also the “Histoire du DMP”, stories about DMP. These are for both doctors and patients, the story of Julie, Michel and José.
http://www.dmp.gouv.fr/web/dmp/professionnel-de-sante/le-dmp-de-julie For those who want to dive deeper into “policies” hit the tab: “securité and confidentialité”.
For those who want to go into the details hit the tab “école du DMP” or “DMP School”.  Where you will have more detailed tutorial for health professionals.

The June HIT Standards Committee Meeting - concerns

I listened intently and helplessly to the HIT Standards Committee meeting on Wednesday. I was very frustrated at the first half, fortunately for me I have less knowledge about the second half discussion. John Halamka works really hard to keep the group on-track and to bring the discussion to conclusions. What I heard on the call seemed frustrating, but ultimately didn't conclude on anything too hard to live with. BUT, when I look at John Halamka's blog summary, I get re-frustrated.


I am very concerned that there is so much experience in Healthcare and Internet space that is being ignored. I certainly hope this is not intentional, but it is painful anyhow.  I even know of experience that is counter to what I think is the right solution. I am good with this information being discussed, I am confident of my knowledge and am very willing to be proven wrong. Those that were involved in the Direct Project, should remember this and I hope they recognize that once a decision is made in an open and transparent way that I will adopt that decision. I simply want OPEN and TRANSPARENT evaluation.

Here is some comments I left on John Halamka's blog. I know this not well presented. I will expand on some of these topics over time. If you don't understand an item, please ask. It is only with open discussion that misunderstandings can be made clear.

Data Classification: 

a) please don't reinvent data classification, it is a very mature part of IT Security http://healthcaresecprivacy.blogspot.com/2010/08/data-classification-key-vector-through.html

b) Data Classification is just one vector. Just like User-Role is just one vector. Access Control inclusive of Privacy considers them all. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf

c) Complex Consent does not need to be NwHIN portable. Enforce it at the Data-Source, no need to tell Data-User why they don't get access. Once Data-Source determines data can be disclosed; control of the  copy becomes Data-User responsibility.   --- I need to blog on this, I realize now that this lesson learned in NwHIN has not been explained to those not involved in that discussion, or the DURSA.

Provider Directories:

d) the HITSC should not be making the Policy decision on 'who' or 'how' one decides to trust. Certificates are self-validating, the infrastructure does not need to add this complexity (risk of failure). Organizations will make different decisions on who to trust, and for what they trust them to do.

e) I was listening closely and there was disagreement about the new microformat model. I am worried that it has some real questionable operational issues. I worry that google/bing are good, but not good enough. I worry that publication on a web page is not automatically supported. I don't see how the use of this can be automated without being overly constrained. I worry that off-the-shelf e-mail doesn't support this today. I hear that this microformat solution was presented to S&I today by Dixie as a solid mandatory solution to replace LDAP recommendation - This is NOT what I heard on the Wednesday call.

f) I really don't understand how Google/Bing/Yahoo is an authority on Healthcare, but HL7/DICOM/ISO/ASTM/IHE are not. I really don't understand how blog posts by individuals is considered more authoritative than an open and transparent ballot process by HL7/DICOM/ISO/ASTM/IHE.

Metadata

g) CDA is not an envelope, it is a document. XDS Metadata is a generic envelop that can carry MANY document types of documents including DICOM and CCR. Why was XDS/XCA not considered?

h) I understand that there are people that misunderstand XDS as being restricted.. it's only restriction is to a document that has a MIME-TYPE. the XDS Metadata is specifically designed to be content agnostic, yet derived from CDA as a mature model.

i) experience with CDA and XDS is available at http://tinyurl.com/wwxds . This experience is EXTENSIVE. It should NOT be ignored. If it there is a good reason for it to be ignored, please explain.

Patient Identity Matching

j) Matching Consumers credit reporting in the financial industry has lots of false positive/negative; but their failures don't hurt/dismember/kill. Same is true in many other industries. This does not relieve us from learning from others, but we should not blindly assume they have solved the problem to the extent that Healthcare needs it.

k) Please look at XCPD. It has included much input from many global subject matter experts, including Voluntary Patient ID. It is primarily the work of those involved in NwHIN. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_XCPD_Rev2-2_TI_2011-03_04.pdf

Also:
I agree with the comments from dining_phil and David on John Hamamka's post. LDAP must be considered; and OIDs are not healthcare specific and should not be frightening. Yes, they should never be shown to a human.

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

This just crossed my desk. Most interesting to my usual followers is the "Document Encryption (DEN)" supplement. This includes a comprehensive analysis of all the use-cases around document encryption including existing solutions from IHE regarding transport and media encryption. It then fills the gaps with a standalone document content profile for transport independent document encryption; and updates XDM with a method for encrypting XDM content on USB and CDROM media.

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment
The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for Public Comment on June 3, 2011: ·         Cross-Community Fetch (XCF)
·         Cross-Enterprise Document Workflow (XDW)
·         Document Encryption (DEN)
·         Support for Metadata-Limited Document Sources
·         XAD-PID Change Management (XPID)
 The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 3, 2011 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements.  Comments should be submitted at http://www.ihe.net/iti/iticomments.cfm 

US ONC Requests Comments - Certificate Issuing

There is a very narrow window of opportunity to provide comments to our US Government comment.  The memo went out on June 1, and the deadline is June 5. This is a 5 day window if you received the memo 3 days ago, 2 days if you waited for me to tell you. Does it bother anyone else that not only is this only 5 day window, but the deadline is SUNDAY.  Exacerbated by the very fact that those most likely to have the answers are NOT watching ONC on a daily basis. Those with the answers are those that deal with general purpose IT Security.

This commenting opportunity is regarding how to handle the problem that is, issuing Digital Certificates for securing Healthcare IT. The press release is not that helpful, but I will pull it apart for you. First drill down and you will find that there is a really good presentation by the HIT Policy Privacy and Standards Tiger Team (Not the committee I am on). They have done an exceptional job of bringing together very helpful information.

The key areas that ONC wants comments on include:

• What burdens will providers face to obtain and manage these digital certificates both at an individual and organizational level? How can these burdens be minimized? 
• Is there sufficient competition in the marketplace to ensure that providers will have access to best pricing and service? 
• What role can Health Information Exchange (HIE) and Health Information Service Providers (HISPs) have in providing and maintaining digital certificates for providers and organizations? 
• Among the options listed, what are the costs and time requirements for each? 
• What is the incremental cost to become a cross-certified certificate authority compared to the cost to become a WebTrust/ETSI-certified CA? What factors contribute to the increased cost? 

Your comments need to go to a specific place as well. 

                http://wiki.siframework.org/message/view/CI+-+Analysis+Support+Team/39763196

They need comments regarding this. I have my opinion, and it has been registered. I encourage everyone to respond. Specifically I think that we need to get comments from the International community, where there is already deployment of certificates for their healthcare use. We need to get comments from other industries where certificates are issued (not likely to happen, especially given the timeframe). We need to get comments from healthcare organizations that have certificate deployment projects underway, I am guessing here that the large provider organizations have something.

My latest opinion is that 

I recommend that we don't look to lower our standards (that is to make the solution cheep and thus not really secure) but rather raise the usefulness of the Certificate Identity. If the Government would combine many projects 'need' for an identity then we could rationalize an equitable solution. That is to say that all of these needs for identity should be Coordinated. 

a) Direct - end-to-end message security/authenticity
b) Exchange - organization participation in a regional and/or national exchange (NwHIN Exchange)
c) Medicare plus - and other insurance exchange needs
d) Prescribing (especially the new eRx on Schedule 2)
e) Medical Records - signatures attesting authorship
f) Quality Reporting - identity of the institute reporting
g) Immunization Registries -
h) Medical Credentials
i) Clinical Trials - attesting each submission is already done this way. But participants in a clinical trial could also attest to their participation
j) Medical Professional Societies - HIMSS, RSNA, AAMI, etc...
*) etc... surely there are others... 

Ultimately enough uses of an identity and the costs and inconvenience of getting it well provisioned become insignificant 

Ultimately these could then be used for daily authentication to the EHR (or more practically requested on-demand when the system wants to be sure the user is who they say they are. Meaning lesser and more convenient means are used at each touch, possibly RFID/nearField/wireless based) 

Tie this to NPI - they already have a directory (private) for NPI. 

I would however make sure that the identity is just an identity. Meaning the binding to authority is done outside the identity. That is to say that none of the above use-cases is directly inside the certificate/identity; but rather these are legitimate uses of the certificate/identity. The Authority thus can be granted and revoked while the identity remains constant.

Huge impact on the Security/Privacy Audit Log - unless you are organizationally fully ATNA compliant

There is a new Notice of Proposed Rulemaking (NPRM) out this week, formally published today. Robin Raiford (Allscripts) has inserted bookmarks into the NPRM text from the Register. It is available from google docs at:

•  NPRM - HIPAA Privacy Rule Accounting of Disclosures under the HITECH Act

I have not yet fully read it, but what I have seems to coincidence with what others are picking out as the important changes. I will be reviewing this and preparing comments. Until then, read:

• Steve Gantz
• Wes Rishel 
• Adam Greene 
• Kaiser Health news

Of concern is that this NPRM proposes to create a new report that the Patient can get that has all USES and DISCLOSURES that the EHR is involved in. First, the old rule gave the right to an ‘accounting of disclosures’ which had a huge list of exceptions, so much so that it really was rather useless. This new change removes these exceptions. It is not clear just how many exceptions will still exist, for example required government reporting, this use to be an exception under ‘normal operations’, but does beg the question of 'who' is reported for this one.

Also of concern is the use of the term ‘EHR’ which HHS/ONC expanded the definition late last year to basically include any medical record with interoperability. It is not clear what the boundaries of the new definition of EHR is. As Wes points out this could include all of the departmental IT, and possibly all the medical devices that feed those.

If the EHR, that is all systems involved in the new definition of EHR, were using the IHE ATNA profile fully; then this report would be a simple report from the Audit Record Repository. The ATNA Profile can inform an Accounting of Disclosures. This would mean that each access to data was fully described using IHE ATNA, something the standard does support. Including who, what, where, when, and WHY (purposeOfUse).  See also: Accountability using ATNA Audit Controls


The original Press Release: HHS announces proposed changes to the HIPAA Privacy Rule

IHE - Privacy and Security Profiles - Document Digital Signature

Most of the time a Document can be considered complete and authentic simply because it was stored, received or retrieved via trusted pathway. A good example of this is the secure communications built into the IHE ATNA profile which includes three different solutions: Mutually-Authenticated-TLS, WS-Security, and S/MIME.  Another good example is the XDS Metadata attributes of 'hash' and 'size' that are built into the XDS family of profiles. These metadata values are carried independent of the document it-self; and thus there is a moderate level of assurance provided.

A Document Digital Signature is needed when these infrastructural mechanisms are not sufficient. This is usually only critical cases of  high value or concern. Some example use-cases:

1. Attesting a document as true copy - to verify that the document being used is the same as the original document and has not been modified by error or intent. Also important to establish the signer and the reason for signature
2. Attesting clinical information content - a physician may choose to review a document and apply a signature to attest the report is complete and correct.
3. Attesting to a diagnostic report - a doctor may verify a diagnostic report and apply a signature across both the source data and the diagnostic report. This provides a proof that the original data has also not changed since the diagnosis was made.
4. Co-Signatures and Counter-Signatures. This functionality allows for complex workflows that might need to have signatures in a specific order.
5. Signing multiple documents. This functionality produces one signature that signs multiple documents.

The Document Digital Signature profile uses a detatched signature to allow for the clinical document (the document being signed) to be manipulated independent from the signature. The Digital Signature is not specific to transport, nor does it rely on the signed document being in a specific transport. If the clinical document is managed in XDS, then an EHR will see the clinical document just like any other document. If this EHR needs to validate the signature it can detect the signature through the Metadata, and pull the Document Digital Signature as a document.

The Digital Signature document is an XML document following the W3C XML Signature specification using a W3C profile for signatures (XadES). IHE further profiles this to add a Purpose Of Signature, and Timestamp. Thus the Digital Signature document includes the signer credentials (X.509 certificate), timestamp of signing, purpose of signature, and a manifest of all the documents that are being signed with their individual hash value.

Given that these Digital Signatures are potentially going to need to be validated 10-20 years later and thus need to be self contained and self describing. It is this reason that IHE has mandated that the Digital Signature include the  reason why the signature was done. These "Purpose of Signature" values come from a vocabulary defined in ASTM E1762 as show here. This allows for simple author signatures, but also more complex relationships to the signature such as validation signature, witness signature, addendum signature, and timestamp signature.

The result looks a little like this. The original document is mostly unmodified except that it has an association type "Signed".

The Signature Document contains the Who, When, and Why; along with the list of items that are signed with their individual hash codes. The whole thing is signed to protect it over time. In the case where these documents are managed in XDS, they both are registered as independent documents with the specific associations. This same mechanism is used for XDM, XDR, and XCA. Where the transport is some other method, the profile does not define how the two documents are managed.

References

• Status: Trial Implementation
• IHE ITI Supplement – Document Digital Signature
• August  2009
• Standards Used
• W3C XML Signature
• XadES profile
• ASTM E1762 - Purpose of Signature

Additional Comments
DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'

• Can sign any document type. Not limited to XML type documents such as CDA
• Signature document is created that is an XML-Digital Signature blob
  • Original document to be signed is signed by 'reference'.
  • Encapsulation is not a bad thing, but it does make the original document harder to get at. Especially if that original document is not XML based
  • Signature by reference allows the original document to continue to be accessed normally by applications that don't need to validate he signature. While having the signature present for those applications that do need it.
  • The digital signature includes the Date/Time of the signature. Assuming trustable date/time
  • The digital signature includes the certificate of the signer
  • Note that signatures need to be valid for decades. Which brings up interesting certificate management issues not addressed.
  • The digital signature includes the reason for the signature. Why was it signed? What does the signature mean?

• XDS Metadata shows that the signature document is in a 'signs' relationship to the original document
  • This allows for finding the signature from a document, and finding the document from the signature
• Works for XDS, XDM, XDR, XCA
  • Might work for other environments as well. The main thing that must happen is for there to be a way to dereference the document ID number found in the digital signature document to get to the document that is being signed.
• Might be future work to have an encapsulated flavor
• USA Regulation from FDA that explains Digital Signature from Electronic Signature - 21 CFR Part 11
• • (a) The regulations in this part set forth the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper.
  • (b) This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means.
• USA (DEA) Regulation update for electronic prescribing of Schedule II drugs 
• Clearly a high value use-case that should be able to justify the overhead of digital signatures infrastructure.
• See: Signing CDA Documents

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• This Page
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion