Monday, December 31, 2012

Most Interesting Posts of 2012

Simply here are my top posts from 2012 (combination of Google Analytics and Blogger stats)

1. Meaningful Use Stage 2 -- 170.202 Transport (Note critical clarifications later)
3. Universal Health ID -- Enable Privacy
4. IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
5. Patient Identity Matching
6. The Basics of Cross-Community Patient Discovery (XCPD) - Guest blog by Karen Witting
7. How to apply Risk Assessment to get your Security and Privacy and Security requirements

It gets less clear after these, but the Topics page is next most popular.

January I explained how to build an HIE using IHE, reminded Healthcare that backup needs to be distributed, kicked off Data Segmentation for Privacy Initial Review,  Pointed out more real HIE/HIO policies, Introduced the IHE Cross-Enterprise Workflow profile, explained why although SYSLOG is a lossy protocol it is not only good enough but the best solution for Security Audit Logging, and explained how to properly Audit Log a Query transaction

February I explained ATNA auditing of CCOW context changes, asked for Simple and Effective HIE Consent while showing there is more complex ones in the future, helped some understand that Encryption is not a wonder drug and thus Encryption is like Penicillin, took pride in participation in NwHIN Exchange -- Impressive success even if my company isn't directly involved, more reminders that security is hard by explaining that A Bad Random Number Generator will produce Bad Security, and one of my strongest positions is that a Universal Health ID is necessary to Enable Privacy.

March was my most prolific by far with 20 articles: reacting to political statements of Complexity only to explain that Complexity is clearly in the eye of the beholder, Meaningful Use Stage 2 :: SHA-1 vs SHA-2, I breakdown and build up a Published White Paper from the Health IT Symposium, advertize availability of IHE ITI Educational Materials available, have Karen Witting (IBM) guest blog NwHIN-Exchange use of XCPD for Patient Discovery and also The Basics of Cross-Community Patient Discovery (XCPD). A short tutorial on How to apply Risk Assessment to get your Security and Privacy Requirements, Explain how an HIE can Enforce Security and Privacy Policy in a XDS Registry, Finally see Meaningful Use Stage 2 means Secure and Privacy Protecting, Again explain the the benefit of an HIEStepping stone off of FAX to Secure-Email,  Meaningful Use Stage 2 -- 170.202 TransportMeaningful Use Stage 2 seems to support SecurityHuge HIE -- the Care Continuity ConsortiumHealthcare is not secure - trust suffers, and announce more IHE - ITI NEW Educational Webinar Series

April clearly I was exhausted with just 4 articles. The explanation this month goes only to explaining that Patient Data should not appear in the Security Audit Log. Otherwise I was just frustrated that S&I Framework Data Segmentation for Privacy seems to want to do nothing but go Around and Around in circles, while over seas The French Health Information Systems documentation is now in english, and that Meaningful Use only wants Transmission into Oblivion which fortunately later got resolved.

May starts with another Guest blog by Karen Witting (IBM) Technology Churn as a distraction. I provide some practical viewpoints that Security is not just technical but more so Operational concern, I introduce and make standalone from XDS a description of Healthcare Metadata, Quick review of ONCs New Guide on Health Information, Privacy ans Security and Meaningful Use,  and point out that IHE Connectathon has a fantastic FREE and Internet facing tool for Testing your XDM implementation.

June finds a security problem where many would not have found it in the Leap Second, yes it has security and privacy relevance, I provide Constructive comments on Data Segmentation for Privacy although not all were eagerly received, Help people understand that User Authentication is not a one-size-fits-all, and Introduce for the first time the IHE ITI mHealth Profile - Public Comment.

July I have some constructive comments on the Implementation Guidelines for State HIE Grantees on Direct..., help people understand that yes Direct messages can and will be "delegated/forwarded", gave a presentation on IHE Document Digital Signature - Non-Repudiation, and asked for comments on the mHealth profile that is a RESTful interface to XDS.

August I introduce the concept of Identity - - Proofing, more MU2 questions about Minimal Metadata or Karen's Cross or just Minimal Metadata which turned out to be neither but rather XDM over s/mime or XDR over SOAP. Another Karen Witting guest blog on Effective Standards Evaluation. Frustrated that perceptions are taking over with The Emperor has no clothes - De-Identification and User Provisioning, and two more external events HL7 WGM - Introduction to Security and PrivacyTexas HIE Consent Management System Design

On The Meaningful Use Stage 2 RulesMeaningful Use Stage 2 : TransportsMeaningful Use Stage 2 - Audit Logging - Privacy a..., and Direct addresses- Trusted vs Trustable

October I point out more free and open Testing for your ATNA Audit Log implementation, explain that there really are differences between Identity Proofing and Authentication -- Patient vs Providers, muse complaints that  Direct has difficult requirements for no good reason, wish for MU Patient Engagement - Activity History Log, Look at the security requirements in 2014 Draft Test Methods: Wave Four, parse what MU2 - Encryption and Hashing mean, and help the reader understand Patient Portal - view, download, TRANSMIT.


December I add one more profile to the IHE - Privacy and Security Profiles - Document Encryption, finished my chapter in a Book published on Healthcare Information Technology, express some way to get security considered in even Modular EHR certification, and now IHE ITI slate for 2013-2014 development is fixed.

Big year. I wish there had been more interest in 
But that is okay, I got these concepts baked into my chapter in the Book published on Healthcare Information Technology

Sunday, December 30, 2012

IHE - Privacy and Security Profiles - Document Encryption

IHE Document Encryption supplement includes two more ways to encrypt documents. 
  • There is a method included for encrypting just a single Document that can be used to encrypt any document type, and thus be carried on any transport. This Encrypted Document can be carried using XDS/XCA/XDR/XDM, but may also be carried by any other means (e.g. HL7 MDM). 
  • The second method is applied to XDM physical media. With the XDM encrypted media the whole XDM content and structure is encapsulated in an encryption envelop thus fully enveloping all the content that would be transferred on USB-Memory, CD-ROM, or any other media type.
These new methods of encryption are complementary to IHE-ATNA, XDM e-mail, and IHE-Radiology PDI Privacy option. The additional new use-cases are
  • Media to media transfer
  • Patient carried media for medical records clerk import
  • Unanticipated work-flows where media is used without knowing where it might be needed
  • Clinical trial where transportation of the content may be by many different transport mechanisms over time
  • Multiple recipients of secure document
  • Sharing with receivers only partially known apriory, a group or a role
  • Encryption of some documents in a submission set
Encrypted Document Content
The Content Profile in the DEN supplement defines how to encrypt a Document in a way that is independent of transport. There are defined ways to handle the XDS metadata when XDS metadata is used.

There are multiple key management methods to support a wide number of use-cases. The choice of key system used is defined by the Content Creator (the creator of the encrypted content). The movement of the key from the Content Creator to the Content Consumer is not defined, there are many ways that this can be done. The movement of the key should be done with care.

The Original document is encapsulated inside the encryption envelope, thus fully subsumed by the Encrypted Document object.

The Encryption Document is made up of a CMS (Cryptographic Message Syntax) [aka PKCS#7] envelope, MIME-header to define the content, and the encrypted Original document. Note that CMS is the core protocol used in S/MIME (Secure email), the core of the USA/ONC Direct Project.

XD* Metadata ramifications of Encrypted Document

When an Encrypted Document is transported using XDS/XCA/XDR/XDM, most XDS Metadata need not be changed.

There may be other logic (De-Identification) that may choose to change these metadata values: such as blinding, obfuscating, or pseudonym; but these decisions are outside of the scope of the DEN profile. (See the forthcoming IHE ITI De-Identification Handbook)

The hash, mimeType, and size values MUST be changed to reflect the actual Encrypted Document. The hash and size must represent the encrypted document, as these are defined in XDS metadata as representing the document stored in the Repository. The mimeType also must represent the encrypted document, which is now in the format of ‘application/pkcs7-mime’.

When using a non-IHE transport one might need to have a file-extension which would be “.p7m” which is recognized by many applications

Encrypted XDM Media

The DEN supplement also adds a Media Encryption option for XDM. This is a new option on the XDM profile that produces a fully encrypted XDM media. The Media directory structure is first ZIPPED, just as if preparing for the e-mail option. The zipped file is then encrypted using the same mechanism as defined for the Document Content; that is to encapsulate using CMS encryption. The result is a file that stats with XDMME, 3 digits, and ends in ‘.pk7’



Encryption Key Management

Recipients must support all key management methods to support the widest use-cases.

  • Digital certificates and private key utilize PKI. The IHE PWP and HPD profiles support certificate distribution and may be leveraged for some use-cases.
  • Shared symmetric key should be used only where there is some secure means to distribute the symmetric key. For example through some access control service that can be used to deliver the symmetric key upon authorized request for key retrieval.
  • Password-based key derivation must use a password based key derivation algorithm (PBKDF2 – RFC3211) to be sure to generate keys of appropriate strength. Poor password choice is still susceptible to brute force attack.

The biggest risk to presented is that the encrypted objects can be copied and brute force attacks used without monitoring and alerts. Encrypted documents and media should still be handled carefully.

Standards Used

  • Key Properties
    • Encryption at Document or Media (XDM)
    • Flexible Key Management (PKI, Shared-Key, Password)
    • Complementary with other (ATNA, XDM, and Document)
  • Standards
    • Cryptographic Message Syntax (CMS) [RFC5652]
    • MIME [RFC2045]
    • bulk encryption: AES 128, 196, 256 in CBC mode
    • digest: SHA256
    • signature: RSA
    • key encryption: RSA (certificate),AES (shared key),AES + PBKDF2 (password)
References
  • Status: Trial Implementation
  • IHE ITI Technical Framework
    • Vol 1: Section 32 – Document Encryption
    • Vol 3: Section 5.3 – Encrypted Document Content
  • Options added to other transactions
    • Vol 1: Section 16.2 - Add Encrypted XDM option
    • Vol 2b: Section 3.32 – Add encrypted XDM

Friday, December 28, 2012

Help for your challenges with XDS-related Tech Framework documentation

FYI: IHE is trying hard to make their Document Sharing Metadata definitions more readable (aka XDS Metadata, or XD* Metadata, or XDS/XCA/XDR/XDM Metadata). The following is an open invite to help.
Attention XDS and Document Sharing implementers:

Many of you have identified concerns about the implementation of XDS Metadata as described in the ITI Technical Framework Volume 3, Section 4.

As a result of your feedback, the IHE IT Infrastructure Technical Committee is putting together an online focus group discussion to gain an understanding of those challenges and how they may be addressed through a revised version of ITI TF Volume 3 Section 4.

Your participation is critical to the success of any efforts to re-write or clarify volume 3, Section 4.

We ask all of those who feel they can articulate these challenges to respond with their name and their availability to attend an online focus group webinar on January 8th from 10am-11:30am CST.

Please contact Celina Roth at croth@himss.org and Gila Pyke at gila@cogna.ca as soon as possible with your availability. You will be sent a meeting invitation for the webinar.

Wednesday, December 26, 2012

Book published on Healthcare Information Technology

I wrote chapter 28 - "Unique Operational Safeguards in an Electronic Health Record and a Healthcare Information Exchange". The full title of the book is quite complex "Healthcare Information Technology Exam Guide for CompTIA Healthcare IT Technician and HIT Pro Certifications"

It isn't a full book like Keith writes; but it is my second offering toward a book. The first was a book that likely sold only 10 ceremonial copies in 1997 "Intranet Resource Kit". In neither book am I a big enough writer to make much mention on the cover.

I am very pleased with my chapter in the HIT book, 31 pages. I cover quite a bit of ground on Privacy and Security related to EHR and HIE. Much of the material comes from my blog, but even that had to be rewritten to fit the editorial style of a book. The chapter covers everything from identity, identity proofing, access control, authentication, and role based access control. I cover the various perspectives one must take in healthcare to protect data appropriately; including the patient perspective, provider perspective, and organizational perspective. I cover this topic as an exercise in a local EHR, but also how this model needs to be extended across an HIE to continue to protect the sensitive healthcare information. This requires the expansion out into Metadata and Federated Identity. 

This book has a large number of contributors, some that I know well. The set of 8 chapters that make up Part IV "Healthcare IT Security, Privacy, and Confidentiality" is coordinated by Lori Reed Fourquet.  The chapters are anchored by Dixie Baker who starts off the section with "Building Trust"; Gila Pyke with "Risk Assessment and Management"; Dennis Seymour with "Physical Safeguards, Facility Security, Secure Systems and Networks, and Securing Electronic Media"; Sean Murphy with "Healthcare Information Security: Operational Safeguards"; Lisa Gallagher with "Architectural Safeguards"; Braulio Cabral with "Healthcare Cybersecurity Technology"; and Karen Bell with "Certification of HIT Products and Systems".

Others that I know well: Don Mon coordinated Part II on "Healthcare Regulatory Requirements". Floyd Eisenberg wrote "Using Healthcare IT to Measure and Improve Outcomes"; Marc Overhage "The Role of Healthcare IT in Improving Population Health"; John Glaser "Strategic Leadership and Management of Health Information Technology in Provider Organizations"; Judy Murphy "Healthcare Information Technology and Healthcare Policy"; Joyce Sensmeier "Navigating Health Data Standards and Interoperability"; Chris Apgar "Regulatory Aspects of Healthcare IT: Legal Best Practices and Requirements"; and so many more. It is shocking how many people contributed to this book.

Friday, December 7, 2012

Enabling Security/Privacy on Modular EHR certification

ONC in the US issued a Request for Comments on potential Meaningful Use Stage 3 objectives, measures, and some certification criteria. The link to the RFC is: http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf

Specifically to my attention is the question of Security and Privacy relative to the new MU2 method of Modular Certification. This 'problem' has been identified very well by Dixie Baker on the HIT blog

The biggest problem here is that there is no definition of what a Module is. Thus there are some Modules that are nothing but reporting packages that make output look pretty for printing, these kinds of Modules should not have the security imposed upon them but rather the ‘calling’ application should have already done all necessary security and privacy tasks. However many Modules are closer to a full functional specialty or departmental systems.

The solution is to have defined Modules, not a free-for-all. With defined Modules one can define the Interface between the modules. Thus defined 'standardized interfaces', that is interoperability. With the defined modules and the interfaces between the modules; then one can identify the appropriate place for security functionality and what security is needed on the interfaces. It is through this defined modules with standardized interfaces that is a precondition for having standardized security and privacy functionality including enforcement that span beyond the core certified EHR definition.

Note that MU2 already has an equivalent of this. The defined "Transports" are a exemplar of what I am talking about. The Transports include security built right in. This security is well defined and clear.

This is easy to do with some Modules, not so easy with others. But by starting with some easy Modules, such as departmental EHRs, we can narrow the gap. There are well defined standards interfaces, interoperability, between the main EHR and the departmental EHR.
  • Patient Identity -- IHE-PIX, IHE-PDQ, and IHE-PAM
  • Orders/Results -- IHE Radiology Scheduled Workflow, IHE-Laboratory Workflow, etc
  • Care coordination documentation -- HL7 v2 MDM, CDA, CCDA, IHE
  • etc...
And all of these are being transformed into RESTful services with HL7 FHIR; and available for cross-organization exchange through IHE XDS/XCA/XDR/XDM.

Once these interfaces are defined, one looks at the interface requirements. Sometimes the security need only be machine-to-machine (IHE-ATNA). But sometimes user identity is important (IHE-EUA, IHE-XUA, or IHE-IUA). A big advantage of having these modules well defined and interfaces well defined are that one can also look at deeper requirements like Encryption, Security Audit, Privacy Enforcement, Accounting of DisclosuresAmendments, and accessibility.


The problem that MU has with this is that I don’t think HHS/ONC/CMS want to get into the internal workings of a healthcare provider operation. Inside the healthcare provider operational IT is a mess. Most of the healthcare provider organizations that have complex internal operational IT, also have plenty of knowledge and power to change it themselves. Thus I don’t think there is really a desire in HHS to mess with the problem of internal organizational affairs. I also don’t think that the large organizations want HHS messing around in their internal affairs.

I think a logical move for MU3 is to head a little bit back toward MU1 method of modularity without going all the way back. Thus I think there is a need to have some defined types of specialty EHR that are required to meet all security/privacy requirements, and have defined interfaces. These defined types should be rather identifiable and their interactions also rather clear.
More

Wednesday, December 5, 2012

IHE ITI slate for 2013-2014 development

The IHE ITI Technical Committee met this week and accepted all received work items. We spent the majority of the time doing scope narrowing and shifting schedules. This because there is strong interest from many different stake holders, and we couldn't do all the work proposed. After much ‘constructive discussion’ we think we have a plan for how to make progress on all of the work items. This decision is a very hopeful decision given that last year we all got highly distracted by outside factors (e.g. Meaningful Use) and thus hardly delivered anything more than one profile (MHD).

The following is the output of the ITI Technical committee. The first three rows are to finish up last year’s white papers, which is viewed as top priority. The rest of the items are the new work proposals and thus the biggest amount of work. The creative scoping has trimmed most profiles from their original proposal. The creative scheduling has one being prepared before we even meet at the first face-to-face.



Findings Notification – this is a white paper that explores the use-cases of clinical findings notification. This paper is close to being made public.

Document Sharing Re-documentation – this is an effort to fix the Technical Framework Volume 3 where it describes the Document Sharing metadata (XDS, XCA, XDR, and XDM). IHE is trying to present the metadata model in a more comprehensive way that also sets up the various transport types, including MHD in the future.

De-Identification – this is a handbook that will assist IHE domain committees and others to assess any De-Identification needs and help build the appropriate algorithms for an analyzed use-case. This handbook will leverage pseudonym and anonymization mechanisms. This will be inclusive and in harmony with the latest guidance from both the UK and USA

Internet User Authentication – this profile proposal looks to fill the authentication gap that exists with the MHD profile, yet will produce a general purpose HTTP authentication for typical Mobile use-cases and RESTful. It likely will leverage oAuth 2.0, but the actual choice is a technical committee decision. This effort will look at existing efforts such as the USA RHEx effort.

Extend XDW to XCA – The XDW (Cross-Enterprise Document centric Workflow) profile was originally scoped to use with XDS. This profile proposal extends that to XCA environments. This recognizes that many cross-enterprise workflows will take place across the boundaries of XDS.

Care Service Discovery – This is likely to be an augmentation of HPD to support discoverability of clinical-services and possibly network-services to support those clinical services. It will likely also have a white paper that will explore how to leverage these and other IHE profiles to satisfy social use-cases.

IntendedRecipient and Folder subscription – This profile recognizes that the current Document Subscription (DSUB) profile is too constrained. This profile will bring in additional use-cases and thus subscription types. The prime use-cases are those where a system desires to simply subscribe for any document with a specific IntendedRecipient value; and where a system desires to subscribe for updates to an identified folder.

Pull-style Notification – this profile brings the use-case where a subscriber to a Document Subscription (DSUB) can’t support the current call-back pattern. This profile suggests that there be a way to queue up the notifications and have the subscriber poll for any outstanding notifications. This is a functionality that comes from our underlying WS-Notification and thus should be a very small supplement to add this new pattern.

What is Next?
The Technical Committee meeting now is scheduling sub-committee meetings to develop the materials, full committee meetings to review the materials, and will target the Face-to-Face meeting March 18-22 in Treviso, Italy.