Comments on Life as a Healthcare CIO: My Privacy and Security lessons learned

John, your post mentions privacy but essentially f...

2009-10-08T09:46:37.275-07:00

John, your post mentions privacy but essentially focuses on security alone. This is understandable given that we know a lot more about security, both technically and functionally, then we do about privacy. No question that the two are hand in glove, but they do present different challenges and a different focus. In my eyes privacy (I'm thinking of confidentiality as the same thing) is about data consent and representation of preferences. Preferences are defined by multiple parties, governmental, organizational and consumer. A reconciled final consent is then operationalized via security systems.

What is still unclear is how we will translate what may be complicated consent preferences into enforceable security policies. I suspect this will take some time to work through because the kinds of preferences we often hear (perhaps with some regulatory expectations-think 42 CFR Part 2) will present very new challenges to current security systems.

HL7 working groups are beginning to address this but we still have a way to go.

One area of security that I see ignored or taken f...

2009-10-07T14:06:48.234-07:00

One area of security that I see ignored or taken for granted is the need to provide physical security of electronic information systems. Just as paper records are physically kept away from unauthorized access, IT and network equipment must also be secured from unwarranted human contact. In my experience though, physicians, especially those in ambulatory care or private practices, often compromise security as a result of a poorly planned IT implementation. For example, while walking through the exam area of a primary care provider, I came across a data closet with the door wide open and a box fan in the threshold. The IT equipment was running too hot and kept crashing, so the only solution was to open the door in an attempt to cool the room. A patient could have very easily taken down this doctor’s network with a single accidental button push, or worse could happen if a nefarious-type happened upon the data arrays.

While data security can be improved with processes and software, a breach in physical security can have dire consequences as well. Proper use of power, cooling and lockable enclosures should be the starting point of developing a high availability / highly secure IT network.

RE: "Patients will trust electronic health care re...

2009-10-07T09:48:44.577-07:00

RE: "Patients will trust electronic health care records only if they believe their confidentiality is protected via good security."

There is more to it than that. Patients will need access control over their own data, and auditing of access in order to trust the system. There have been too many breaches of SSN's and credit card numbers from other businesses for ordinary consumers to automatically trust their health care provider, just because of encryption technology.

Remediating a lost credit card is a hassle, but not hard, and the credit card companies usually cover any financial loss. What is the remediation if your personal health record is exposed? I realize that some people don't consider their health records highly confidential, but others do. What do you do for them when data is stolen?

LOA level 2 protections (required by CCHIT) are no...

2009-10-07T09:22:16.727-07:00

LOA level 2 protections (required by CCHIT) are not enough to stop MITM attacks, where identity can be spoofed using wildcard SSL certs as demonstrated at Blackhat.

By separating out identity as a managed service from the XML, the relevant HL7 RIM messages and ICD codes can be delivered, and bound late in the process to the identity data when it appears as a CCD/CCR.

Even better is an approach that can actually separate out the bad data that should not be in the patient's EHR when it may have originated due to valid service records for billing, but attached to the wrong person due to medical identity theft or coding mistakes.

I think that process was made clear by epatientDave, that crossing security domains requires agreed upon abstractions which can be achieved by a national level schema, which does not get lost in translation.

HITSP has demonstrated that this can be done effectively and at low cost between states, harmonized with state privacy laws using directory technology such as LDAP and X.500.

Taking a national approach has value IMHO since the entire country (330 million plus people) falls under several defined OIDs, or containers for example, c=US, 1.3.6.1 and elsewhere, and the states can run their own ID management under the standard FIPS codes, which means they apply their own governance, and can network their own identity attributes (such as patient identifiers compatible with PIX NHIN, hDATA) as they, and the organizations in that state choose to negotiate.

BTW, this is with or without Federal participation, which from a data modeling view of X.500 exists at the level of another complex bi-lateral peering and groupings of organizations, and not necessarily (but can be, none the less) as the root, such as how SAFE Bio-Pharma currently is connected to the Federal Bridge PKI.

For obvious security reasons you don't want people registering in the .mil domain for example, but the US container is open in the domain name space. A container like c=US is a way to have a national policy, and state policies at the same time, since it can be enforced in schema, and traceable in requirements. One state might have totally different gender requirements for example than another, as to what attributes where allowed. Want your social networking profile to be exposed to the health system? That really is possible with Web 2.0.

Patient identity is clearly spelled out in the architecture...
http://www.connectopensource.org/download/attachments/17629260/CONNECT+Release+2.2+Software+Architecture_100309.pdf?version=1

Now it's the practical matter of making the data and authentication and authorization portable, by letting the end user choose how they want move it, and providing transparency into the process.

To have your choice of identity providers, and what attributes you want to share, means that actors can link different technologies, and still end up with a consistent result which is based on open systems.

Since LDAP and X.500 have already been vetted into the higher levels of LOA, plus patient identifiers are already written into HIPPA, the problem space is fairly simple for many people who want a secure, proven, international standards based approach.

For others that would prefer to be on the bleeding edge of emerging web services and want to transmit their PHR/EHR/EMR via some other API, to deal with the complexity of the security domain with whom they are trying to communicate, that's just doable (especially globally), but not at the same level of scalability as a national/state solution.

If security is a process doesn't it need to be a s...

2009-10-07T06:49:13.718-07:00

If security is a process doesn't it need to be a systematic process? So where do procedures (e.g. ISO27001, NIST SP800-39) for developing, implementing and maintaining information security / risk management systems fit into the picture?

John - Your observations on Identity and Access ...

2009-10-07T06:26:02.985-07:00

John -

Your observations on Identity and Access Management (IdAM) and Privacy are spot on. The security community, and in particular the identity management community have been struggling with these issues for a while and there are emerging solutions that can address some of the concerns you raised (for example, please take a look at http://tinyurl.com/ydqlfx4).

Overall, any security system can only be as good as its weakest component, and security policies and procedures - both online and offline - are critical factors in such a system.

Going forward, we should also not loose sight of a very critical issue: scalability. Any security control will have an impact on performance and - as such - limit the system's scalability. We really need to start looking into highly scalable architecture patterns (such as REST) in order to be able to scale to internet orders of magnitude. As such, federation technologies will likely be also more important.

Regards,

Gerald Beuchelt

Thanks for sharing this on your blog. I would add...

2009-10-07T05:35:49.129-07:00

Thanks for sharing this on your blog.

I would add, as corollaries:
1) A key objective of security is to mitigate risks in accordance with clear and realistic policies. It is very important to keep security policies and risk analysis up-to-date.
2) The role of administrative controls and insurance is as important as standards and technology. They are relatively easy to use and may be the least costly choices.
3) There is no such thing as shrink-wrapped security. There are many who will try to sell it to you, however.
4) Do not pay more for risk mitigation than the value of the underlying risks.
5) The most frequent security breaches come from trusted users. Security auditing, and reading audit reports, is critical.

One point I'd like to add is that privacy and secu...

2009-10-07T05:26:11.612-07:00

One point I'd like to add is that privacy and security must be weighed against other considerations, such as patient safety. A security policy that prevents access to lifesaving information to ensure patient privacy isn't necessarily acting in the best interests of the patient. As you said, that's like a library that never loans out any books.