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.

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.