one million five hundred thousand health records lost

Connecticut reports one computer hard-drive lost with 1.5m records

http://www.computerworld.com/s/article/9141172/Health_Net_says_1.5M_medical_records_lost_in_data_breach?source=CTWNLE_nlt_pm_2009-11-19

If these were paper records, probably several warehouses would have to be lost to a natural disaster to have the same effect as a missing hard-drive. Doesn’t the HITECH act require disclosure at time of loss?

Technology can have a lot to answer for at times…

Advertisements

AMIA 2009 – highlights from the booths

I had the opportunity visit the booths at AMIA2009

A few items of interest:

  • OpenMRS – platform for developing medical records.
  • Medinfo to take place in South Africa next year, following on the heels of the FIFA worldcup, the country is going to be pretty busy
  • Many educational institutions offering courses including my own, UC Davis
  • Some fascinating medical technologies, of particular interest to me were clinitalk and diagnonsis one

Security for Personal Information stored in Electronic Medical Records

Security and privacy of electronic personal health information entails the same concepts as security for other electronic data, such as personal financial data.

I believe the top three requirements for security of electronic data are:

  1. Confidentiality – keeping data hidden. Data is encrypted both at rest (in the database) and during transfer (over TLS/SSL)
  2. Integrity – Ensure data is trustworthy and has not been modified. This can be accomplished using digital signatures.
  3. Access – Access and audit controls. Implement access controls to control who can access the data. Often this is implemented as the least privilege principle: only grant a user the role or privilege to access the minimal data they are required to perform their function. Complimentary to access controls are audit logs: produce audit logs of who accessed the data, at what time etc. Another example of roles and privileges is separation of duties; in the financial world one might ensure that the person who makes out a check cannot sign it, thus preventing a dishonest user of making a check out to themselves or their friend.

In the financial world the concern is that a user who accesses and modifies data without authorized access and privilege may use that data illegally. For example, a hacker who steals credit card numbers from the database of an online merchant and then performs purchases with those credit cards. Similarly in the United States, social security numbers can be stolen to create fake personal identities.

Implications for digital patient information stored in electronic health records or similar.

US regulations require that entities disclose breaches of electronic health data, as highlighted by Lisa Gallagher.

The security policy for an Electronic Medical Record that contains Personal Health Information consists of three entities:

1. Subject – the patient. Though the subject may require an agent, for example the agents of a new born baby are its parents; a living will can stipulate that an agent make decisions on behalf of an incapacitated person.

2. PHI – Personal Health Information – the actual medical and personal data about the patient.

3. Clinician – The physician treating the patient.

Theft of personal electronic medical data can be used for nefarious financial purposes, such as billing medicare for service not rendered.  However, I believe there are greater risks as follows:

  • Integrity – are we certain that this data belongs to this patient.
  • Confidentiality – prevent data from posted to the Internet
  • Access

It is paramount that data in electronic medical records is never overwritten or deleted only appended.

Auditors should only access a copy of a patient’s record, never the original so that they do not alter or append data.

A physician should have the privilege to alter access to an electronic record. Example, a patient is referred  from a family physician to a specialist, thus the family doctor grants the specialist access to the patient’s medical record. At all times the patient should know who has access to his/her medical record.

Exceptions to these access rules:

  • In an emergency access may be granted to someone other than the subject (patient or their agent).
  • Court ordered access to a medical record.

However, a conflict of interest scenario is possible, a medical practitioner hacks into an EMR and faxes prescriptions for themselves.

In closing, HIMSS conducted a survey, sponsored by Symantec, of security policies and procedures in place at medical institutions.

Federated Identity for Electronic Medical Records

I read with great interest this posting by Adrian Gropper on The Health Care Blog, which was referenced by PracticeFusion’s blog entry on HIT interoperability.

Adrian describes the true case of a soldier injured in Afghantistan and then the hypothetical case of the soldier (or a delegate on his behalf) accessing his personal health record in government and private healthcare providers. The basic premise is that patient only needs to authenticate once to a trusted identity source, thereafter the patient is granted access to their medical record. This is  a sample use-case of Federated Identity, already in use in web applications. Adrian Gropper references OpenId. While that is an example of Federated Identity, the security protocols do not lend themselves towards the access and privacy requirements of medical records.

Firstly, to explain Federated Identity, I offer the following analogy. The European Union (EU), is a trans-national or umbrella organization with member States such as France, Spain, Belgium. Citizens of member States are issued EU passports and may thus travel freely within the other EU member States without requiring visas. The passport official at the airport or frontier, will recognize and trust the EU passport,  but will verify that the bearer of the passport matches the identity in the passport before granting entrance to the individual. Once that individual enters the country they are entitled to services or privileges granted to them, such as tourism or employment, but other privileges may be denied, as they are member State specific, such as retirement benefits.  These privileges differ depending who the user is, a visiting head of state may have higher privileges than an ordinary citizen.

Authentication: The process of matching the identity of the person to the identity claimed in the passport. In computer speak – proving who you are before you can use a computer application.

Authorization: The process of granting services to the person, based on their privileges.  In computer speak – once authenticated, your attributes or role determine what functions of an application you are entitled to use.

In Adrian’s example of an injured soldier accessing their health-record maintained by different health-care providers, the following Federated Identity infrastructure exists:

  1. A central Identity Provider (IdP)  (analogous to the EuropeanUnion) who’s role is to issue and revoke digital identities.
  2. Healthcare providers, ServiceProviders (SPs), (analogous to EU member States) who provide a service, in this case manage an Electronic Medical Record.
  3. Trust relationships between SPs and IdPs. For example, military hospitals, private hospitals, HMOs, physicians etc establish trust relationships with the  Identity Provider. These trust relationships usually entail (a) legal/paperwork agreements and (b) technical exchanges to enable identity certification.

This infrastructure enables the following scenario:

A user of any (Healthcare) ServiceProvider, who has been issued a digital identity by the trusted IdentityProvider, may seamlessly interact with the healthcare providers (SPs). The user will present the digital identity issued by the IdP, the SP will verify the Identity, and the user will be granted access to the Service Provider’s application. However, based on the user’s attributes and role, the functionality available to the user will vary.  A physician may alter a medical record but only within their specialty ( a dermatologist cannot alter a prescription for spectacles). A pharmacist may view but not alter the prescription for insulin in a healthrecord.  A patient may only view but not alter their medical record. In Adrian’s example, the soldier may view his medical record and perhaps authorize it’s transfer to another care provider.

The following provides a graphical view of Federated Identity with the European Union as an analogy and a patient as sample user.

Federated Identities for Electronic Medical Records