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.

Healthcare Privacy - Why are patients afraid

There have been a few articles lately that point out that surveys of patients indicates that patients are worried about the privacy of their data as doctors start to use EHR technology more often.

What Type of Impact Do U.S. Adults Believe EHRs Will Have on the Privacy of Health Data?
	Forty percent of surveyed U.S. adults think that electronic health records will have a "somewhat negative" effect on the privacy of personal information and health data, while 20% believe EHRs will have a "somewhat positive" impact on the privacy of personal data, according to a new survey from CDW Healthcare.

My view is that the reason why they get this answer is because of the way they ask the question, but more specifically because everyone fears the unknown. There is very little evidence that the move to EHR will result in more privacy violations. YES, there is some evidence, and when it happens it is usually large amounts of patients that have been violated or very specific high value patients. But these kinds of things happen, and is it really made worse by EHR or even HIE? I think it is, but don't think that is the problem.

Here is a good skeptic post on HISTalk

From Tobias: “Re: privacy and security. Local and state legislatures are afraid of HIEs and other electronic data because they perceive that because data is electronic, it will be easier to hack. I’m curious if you have any data or can use your network to find any that speaks to this.”

There is good reason for patients to worry. With financial breaches, the bank is compelled to limit the damages. This is offset by the banks through technology that makes revocation of credentials fast and effective, but also through managing the likelihood of the risk through the use of insurance. These same factors simply are useless in the case of health data. First, there is not equivalent regulations on those that do the breaching to make the breached individual whole; yes there is some weak regulations and I am happy that HHS is posting the big offenders.  Second, there is no way to revoke the health information. Health information is facts (or observations) made about the patient. These facts can't be revoked. So, there is not really any way to fix the problem after the fact.

There are actually some really important Privacy factors that only can happen with EHR use. This is the Privacy factors of Access to their health data and the factors of providing their preferences. These could be done in the paper world, but they are so expensive there that I will assert that these will only happen as we move to an EHR.

There is also simply too much FUD (Fear Uncertainty and Doubt). Much of this FUD is based on true and realistic concerns. I am just worried that we are being overly concerned, without a track record of true harm. I am not saying that we should let things happen so that we can observe privacy violations in the wild. I am simply saying that naturally those patients participate with EHR, PHR, and HIE; that can see a benefit that THEY see is more helpful than the RISK. Those that are not convinced should be allowed to not participate, or be flagged as being very concerned.

For example Army Mental Health Providers Not Entering Data Into EHR System

Authentication and Level of Assurance

Level of Assurance (LoA) is a key component of authentication, but what does it mean? The phrase ‘level of assurance’ is identifying that with identity and authentication come in many shades of sureness. There are times when a low level of assurance is the right thing, such as an anonymous posting of comments on a blog. There are other times when a high level of assurance is needed, typically because the resource being accessed is very high value or very high sensitivity. There is excellent work from the USA Whitehouse in "The National Strategy for Trusted Identities in Cyberspace", that continues to be developed.

To more fully appreciate ‘Level of Assurance’ as it relates to Identity and Authentication I provide a breakdown of the different layers where identity and authentication are used.
 

How strongly was the individual verified before they were given a specific identity. This is classically called ‘identity proofing’ or ‘provisioning’. All identities are assigned based on some level of assurance. There are some identities that are assigned based on no prior identity, where other identities are not assigned without strong methods.

• a common email address on the internet has no identity proofing,
• a passport one must provide two prior government issued identities, a picture, and a criminal check
• Certificate Authority using multiple credentials to identity proof prior to issuing a Digital Certificate
• A military clearance requires a far more invasive background check. These more invasive identity proofing are going beyond proving that the individual is who they say they are, but also including verification that their past actions support that they are willing to abide by the rules.
• System or Organizational evaluation against policy – This is the critical part behind ATNA, that the identity issuer will verify that the system or organization is indeed the system or organization, but also that there are appropriate assurances that the policies will be enforced including user-level access control and user-level audit controls.
• Patient Identity – When organizations match up the identity that each has for a patient they need to have some level of assurance that they are making a proper match. This functionality is sometimes automated in a Patient Identity Cross-Reference system that is using algorithms that are tuned to the local needs (such as how often SSN is available). These identity cross-references do have a measure of confidence.

How strongly was the individually verified before the current session was started. Classically what we call authentication. This authentication is to an already established Identity. This is what most people recognize as the user login. This is the step where the concept of ‘multi-factor’ authentication comes in. Authentication is based on one or more factors: Something you know, something you are (biometrics), or something you have.

• Username and Password – Most common single factor authentication
• Two factor authentication is commonly done through a hardware token and a password/pin.
• Smartcards are also a common two factor authentication.

Relying Party – an application or service that uses the authenticated identity to authorize access to a protected resource.

• an EHR application provides a doctor access to a patient chart.
• A Web server provides access to a document drop box
• An e-mail program provides access to the local mail storage
• A nice Microsoft presentation on their offering, but clearly also leveraging SAML and WS-Trust standards

2nd or more Party – a service behind the application. This is typically something like a database or service. In healthcare good examples would be a Health Information Exchange or Nationwide Health Information Network.

• An e-mail application using an e-mail service provider – POP3 or IMAP
• Web Applications, such as Twitter or Facebook, using light weight federated Identity technology – Oauth
• A Health Information Network, using strong and flexible federated identity technology – SAML assertions

End-to-End Security – The data can be proven as being authentic from the original creator of the data all the way to the one using the data.

• NHIN Direct – Using S/MIME specifically targeted to an individual from the individual sender.
• Document Digital Signatures – These can be validated by anyone that uses the document to prove that the document is exactly the document that was signed.

 

In each of these cases there are options on Level Of Assurance. This means that for each of these cases there are different levels of confidence. An excellent discussion of the politics involved in the issues around Healthcare choosing a Level Of Assurance and Authentication Provider is covered by Steve Gantz in his Blog

Overall, we should NOT force a specific Level of Assurance; but rather use identity authentication standards that support communicating the Level of Assurance of that authenticated identity. For this there are standards in X.509 certificates, as well as SAML identity assertions. By mandating only that the Level of Assurance is communicated we are ENABLING the Healthcare services to make informed access control decisions.

Creating and using Unique ID - UUID - OID

Standards often need to have a way to identify an object in a way that is impossible to be confused. A way to come up with a 'name' for an object that no other object has - A Unique Identifier. Standards have solved this multiple times, with two primary ways common today. One of those common ways being able to incorporate the other. I am not going to fully describe these unique identifiers, but rather point at the few references that you need to use.

When I say a Unique Identifier of an Object. I truly mean any object. This goes for things like Patient Identifiers, DICOM Study Instance (DICOM calls these a UID), and CDA Documents. To a computer a communications protocol, these are just a Unique Identifier of an Object.

When I say a Unique Identifier I also want to make it clear that it is an opaque identifier; meaning it is either the identifying the object or it is not -- True or False. Some Unique Identifiers are hierarchical and one could possibly determine something about the object by looking at the identifier; but this should NOT be relied on, it should be worried about (Risks to Privacy-Security). Meaning that the structure of the unique ID is important when creating a new one, to assure you are truly creating a new one that doesn't exist today or in the future. But also that when 'using' a unique ID one compares the whole thing to determine if it is the unique ID you  want or not. Any attempt to see if it is close to the ID you want will only result in trouble down the line.

There are generally 2 types of unique identifier that I am going to cover

1. UUID - Universally Unique IDentifier. These are not absolutely unique, but statistically unique. Not that there is ever a way to prove that any Unique ID is absolutely unique, but UUID is a fixed size and without a structure that tries to guarantee uniqueness. That said, there are different ways to create UUIDs that get so close to statistically unique that one must ask how close to tangent must one get.
2. OID - Object Identifier. We tend to want to use these more often as they are more structured and thus allow for some additional ways to create Unique Identifiers. The structure also allows for more accurate TRUE/FALSE comparisons. And when it comes to diagnosing problems, their structure can also come in handy.
3. Yes, I know there are others. but for the purposes of this blog post, these are king.

So, how does one create a Unique Identifier in a way that is globally unique? 
The easy way is to use your platform to create a UUID. I can't encourage everyone more strongly to use their platform. Not because I have total faith in the platform to have not messed things up, because we all know that mistakes happen. If we all use the platform provided functionality then we will all be watching for the mistakes in the same code. Where as if everyone writes their own algorithm, then mistakes will only be detected by a handful of people who inspected the code, thus a mistake will happen at a bad time. Yes, an open-source platform implementation would make this even better.

• JAVA http://download.oracle.com/javase/6/docs/api/java/util/UUID.html  
• Wikipedia does a good simple explanation http://en.wikipedia.org/wiki/UUID
• IHE Appendix B on Document OIDs IHE ITI TF Vol2x
• The formal definition of the algorithms is the ITU-T X.667  http://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf 
• equivalent IETF  http://www.ietf.org/rfc/rfc4122.txt 
• More background from the ITU-T http://www.itu.int/ITU-T/asn1/uuid.html 
• And David Clunie is always good to review http://www.dclunie.com/medical-image-faq/html/part2.html - UID

How do you create an OID?
The above is all about createing UUIDs, not OIDs. But, if one creates a UUID then you can encode that as an OID very simply. An OID that begins with "2.25." is an OID encoded UUID. The value after "2.25." is the streight decimal encoding of the UUID as an integer. It MUST be a direct decimal encoding of the single integer, all 128 bits. It must not be broken up into parts. E.g., the UUID "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" becomes the OID "2.25.329800735698586629295641978511506172918". (thanks David)

It must be decimal because OIDs are all decimal. This has the additional benefit of being more easy to compare for TRUE/FALSE as one doesn't need to worry about the case of the non decimal characters (typically UUIDs are encoded as hex values, so one must compare them using case-insensitive methods). Yes you must work with very large integer math.

Note: Some protocols have limits to the size of a Unique ID. For example DICOM has restricted some OIDs to 64 characters. When encoding a UUID in an OID the proper way, you will not overflow 64 characters. This is because the largest decimal value that can fit in a 128 bit integer encoded as a string is 39 characters long. (Note, another reason to do this as a single integer, as some have tried to encode the parts and ended up with strings that were too long).

How do you create an OID that is not a UUID?
The UUID encoded OID is really not adding much value, but it is very important where UUIDs are well understood. Sometimes one really needs a native OID. For example a native OID is very helpful when it is used to define something that is going to be documented as part of a standard. For example a vocabulary, Value-Set, Service-Endpoint, etc.

1. First one must get a OID prefix. There are plenty of places to get these. See David Clunie's article on how to do this. 
2. Second one must Manage their OID space. Like managing any 'directory', creating a structure that meets your needs helps you organize and control the OIDs. Some good examples are found in the IHE Vol 2x Appendix B For example when you need to build OIDs in a distributed space (like isolated medical-devices), then manage the OID space to assure that each machine gets a unique branch.
3. Third one must Manage each instance. some will use methods similar to those used for UUIDs. Such as using the MAC address and timestamp (be careful to be thread safe).

Other
Note: MAC addresses (e.g. the ethernet address of your machine) is assigned using a manufacture assigned code and a code assigned by that manufacture in a way that they are globally unique. But the MAC address can also be changed by a talented user. And some abstractions (Virtual Machines) don't use manufacture controlled MAC addresses.

There is a URI (URN) encoding for both UUID and OID. For example:

• urn:oid:2.25.329800735698586629295641978511506172918
• urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Conclusion
Don't reinvent, there are plenty of Unique ID standards and widely used implementations of those standards.

Medical Device Security and Privacy

There are some really good white papers on Security and Privacy associated with Medical Devices. I often point at these because they are well written, yet pointed papers. I also point at them because I worked hard on the content, as I am a member and past chairman of the committee. This committee is a joint committee of the NEMA (an international organization, but tends to be somewhat North America based), JIRA (a European organization), and JIRA (a Japan based organization).

There isn't anything new from the group at this time, but I am posting this because they have changed their web site and just lately recovered all of the good white papers.The following are the most important and still relevent papers. There are more white papers on the site

Joint Security and Privacy Committee.  

• Certificate Management for Machine Authentication
• This paper is still very relevant to mutual authentication used in IHE ATNA. This paper discusses a couple of methods that can be used to manage these certificates, and how each way scales.  See Designing a Secure HIE
• Defending Medical Information Systems Against Malicious Software
• This paper covers some really important concerns that Medical Device vendors have regarding the unintended consequences that AntiVirus can have. Patient Safety is priority number one in healthcare. More importantly there are more ways to address malware (virus, worms, etc) than to simply apply AntiVirus.
• Patching Off-the-Shelf Software Used in Medical Information Systems
• This paper covers patch management relative to security patches from the third party software that the medical device vendor included in their product, such as the operating system. This paper was initially published back when Medical Device vendors were wrongly placing blame on the FDA for their non-action. Patching does need to be done in a controlled way, to protect patient safety.
• Break-Glass – An Approach to Granting Emergency Access to Healthcare Systems
• This is a view of 'break-glass' that is responding to a large scale disaster where the normal IT infrastructure may not be fully functional
• Information Security Risk Management for Healthcare Systems
• This paper helps Medical Device manufacturers manage IT security risks in healthcare systems by detailing the steps in security risk assessment in the context of security risk management. IT security risks are risks to data and systems. As a best practice, patient and operator safety risk management and IT security risk management processes should be separate but linked. They differ in both the vocabulary and expertise required for proper risk management. If combined as a single assessment process, one or the other is not treated appropriately.   This concept has received renewed interest including  IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network

• Security and Privacy Auditing In Health Care_Information_Technology
• This paper discusses the aspects of Security and Privacy audit logging and log analysis in Healthcare. This paper was an important step to the creation of the IHE ATNA profile.See Accountability using ATNA Audit Controls and ATNA and Accounting of Disclosures

Data Objects and the Policies that Control them

In reading the President's Council of Advisors on Science and Technology (PCAST) report on "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward"; among the many comments that I could make on it, I want to focus this blog article on one very specific point. The point I want to discuss is the directionality of the relationship between the Data Object and the Policies that Control them. This point is not specific to PCAST, and has been discussed many times over the years.

In the PCAST report Section "V. Privacy and Security Considerations", on page 49 in the following sub-section quoted below is the part I highlight in yellow:

A Health IT Architecture for 21st-Century Privacy and Security
We believe that a universal exchange language based on tagged data elements will allow the design of much better privacy and security protection than currently exists for either paper or electronic sys­tems, for two principal reasons.  First, the ability to tag an individual piece of data with privacy ­related information, as part of its metadata, enhances privacy safeguards.  Second, because tagged data ele­ment exchange protocols are designed to be efficient for the rapid exchange of small pieces of data, it is feasible to use security protocols that involve multiple exchanges of challenge and response.  We illustrate these points in this and the next subsection.

I will note that I am reading the PCAST report as a set of principles brought together by the small group invited by the Whitehouse. So, First I will note that this is a small group; Second this was a closed group; Third it was not a very transparent process, and Fourth this was a group with some suspicious membership. But this is not what I want to focus on.

I have no problem with 'tagged data elements', I speak highly of this in Data Classification - a key vector enabling rich Security and Privacy controls. The actual value of  these tags is part of the discussion.  In the future I would like to have a discussion about the practical realities of their implied definition of an 'element', where I would like to recommend that a 'Document' is a reasonable size to manage today. 

Data Objects pointing at the Policies that control them:


What I want to focus on is the directionality of the model being propagated by the PCAST report. They indicate that the individual piece of data has a tag (metadata) with the privacy related information. I read this that the Metadata points at the privacy policies that describe how to control the individual peice of data (the 'element').


Data Object  --> Privacy Policy

Policies point at the Data Objects that they control
This seems like a logical approach, and indeed was the approach that BPPC took in the first version. In the first version of BPPC the confidentialityCode of any document could hold the OID of the BPPC policy. This seemed logical to us at the time too. But what we found out was that this doesn't scale with the age of the data-set. What I mean is that as a patient changes their mind regarding sharing (opt-in, opt-out, etc), one needs to go and change all the metadata tags on all the data, rather than just change the policies.

So BPPC now has the confidentialityCode as a sensitivity/confidentiality classification, and the BPPC policy is self-contained. If the BPPC policy needs to have special rules about a specific Document, the the BPPC policy points at the document. For example when a patient wants a specific episode summary hidden, it is identified by the unique number in the privacy policy.

Privacy Policy --> Data Object

Indeed as the patient changes their privacy policy, or the organization changes their privacy or security policies; these changes should be reflected in the privacy/security policies, not in changes to the data. The data hasn't changed, the policy has changed.

Metadata describes the Data as facts, and Policies have the specifics about how to control the data 
In fact the Data object does have metadata that is used in the Access Control decision. Metadata that does include a confidentialityCode, classCode, formatCode, Patient Identifier, Facility Identifier, Author Identifier, etc. But I don't see these as 'pointers', but rather 'security context attributes'. See the IHE white paper Access Control - Published 2009-09-28

I am optimistic that the authors were not trying to impose an architecture, but rather identifying a principle. As a principle the directionality should not matter.

PS. software engineers might find this useful, or might be confused by it -- this is like the first-year school assignment in linked-lists, stacks, and fifo... the obvious direction of the pointers is not the right direction to implement. Ok, that might not help at all...

Most popular blog entries of 2010

The blog tools make this post easy, but it is still useful to record an annual perspective on what seemed important at the time. Clearly the popularity contest is won by 'ranting'.

1. Meaningful Use Security Capabilities for Engineers This is where I describe the Meaningful Use security capabilities and provide recommendations on what they mean and how to implement them
2. Meaningful Use clearly does not mean Secure Use I am amazed at how many hits this got and continues to get. It is a rant on the MU draft, yes they did fix some of the things I rant about. See item 1.   
3. Meaningful Use Certification issue with Encryption of data-at-rest This is where I rant about how the Meaningful Use rules messed up and defined tight requirements for encryption and integrity controls but failed to say anything about key management, content packaging, or portability. 
4. Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent  Another rant...Yup, privacy is still missing... 
5. Meaningful Use - Security Plan This is where I ranted less, but gave advice to how to read the Meaningful Use draft.
6. Accountability using ATNA Audit Controls This is where I explain how to achieve the requirements of Accountability with simply an Audit Control. (Watching what people do is very important. It is sometimes the only way to detect users misbehaving, like looking at VIP patients or downloading thousands of documents)
7. Data Classification - a key vector enabling rich Security and Privacy controls This is where I demystify the confidentialityCode as a part of segmentation, and explain how this is metadata to be used by access control engines as one of the factors used to determine if a specific use of data should be allowed or not. (For those reading PCAST, read this as if it is the PCAST concept of 'tagged data element approach'. It is part of the whole picture but not completely... )
8. Meaningful Use Encryption - passing the tests This is where I explain just how bad the data-at-rest requirements are and how screwed up the testing is.   
9. IT security problems continue (Designing a Secure HIE) This is where I explain that point-to-point security doesn't scale and that a walled-garden approach using TLS may be a better starting point. (Yes, this is an old article that still is true today. We see in NHIN Direct something closer to the unconstrained point-to-point, or end-to-end. The solution being discussed is to restrict NHIN Direct endpoints to 'organizations', thus ending up with a smaller map but still quite the spider web)
10. Meaningful Use takes Security Audit Logging back a decade It is unfortunate that we work hard to advance security and privacy only to have regulation take us back to the dark ages.

I have some articles that I think are more long-term explanations of a concept. They are not so much popular at any given time, but are references:

IHE Security/Privacy primer
Meaningful Use Security Capabilities for Engineers
User Identity

• Healthcare use of Identity Federation
• Federated ID is not a universal ID 

Access Controls - Including enforcing Privacy

• ConfidentialityCode can't carry Obligations
• Data Classification - a key vector enabling rich Access Controls 

Consent Management

• Stepping stones for Privacy Consent 
• Consumer Preferences and the Consumer  
• Availability of Consent Documents and their rules 

Audit Controls

• Accountability using ATNA Audit Controls 
• ATNA and Accounting of Disclosures 

Other Controls

• Signing CDA Documents
• Redaction and Clinical Documentation  
• How to Write Secure Interoperability Standards
• Designing a Secure HIE