Medical Data in the Internet “Cloud” – Data Privacy

Robert.rowley

The concepts of “security” and “privacy” of medical information (Protected Health Information, or PHI) are closely intertwined. “Security,” as described in the second part of this series, has to do with breaking into medical data (either data at rest, or data in transit) and committing an act of theft. “Privacy,” on the other hand, has to do with permissions, and making sure that only the intended people can have access to PHI.

So, who actually “owns” the medical record? The legal status of medical records “ownership” is that they are the property of those who prepare them, rather than about whom they are concerned. These records are the medico-legal documentation of advice given. Such documentation, created by physicians about patients, is governed by doctor-patient confidentiality, and cannot be discovered by any outside party without consent. HIPAA Privacy Rules govern the steps needed to ensure that this level of confidentiality is protected against theft (security) and against unauthorized viewing (privacy). HIPAA-covered entities (medical professionals and hospitals) are held accountable for ensuring such confidentiality, and can be penalized for violation.

The question of privacy, then, revolves around sharing PHI between professionals in order to coordinate health care – after all, health care is delivered by networks (formal or informal), and data sharing is necessary to deliver best-practices levels of care. In the traditional world of paper charts, record-sharing is accomplished by obtaining consent from the patient (usually a signed document placed in the chart), and then faxing the appropriate pages from the chart to the intended recipient. Hopefully the recipient’s fax number is dialed correctly, since faxing to mistaken parties is a vulnerability for unintended privacy violation using this technology.

When medical data moves from a paper chart to a locally-installed EHR, the organization of medical data across the landscape is not really changed – each practice keeps its own database (the equivalent of its own paper chart rack), and imports/exports copies of clinical data to others according to patient permission (just like with traditional paper records). Such clinical data sharing is often done by printout-and-fax, or by export/import of Continuity of Care Documents (CCDs) if the EHR systems on each end support such functionality.

As technology evolves, new layers of medical data sharing emerge, which challenge the simple traditional “give permission and send a copy” method of ensuring privacy. Health Information Exchanges (HIEs) are emerging regionally and nationally, and are supported by the Office of the National Coordinator (ONC) for health IT. HIEs are intended to be data-exchange platforms between practitioners who might be using different EHR systems (that do not natively “talk” to each other). Only certain types of data are uploaded by an EHR into an HIE – patient demographic information, medication lists, allergies, immunization histories. HIEs, then, function as a sort of evolving “library” of protected health data, where local EHRs feed their data on a patient-permission-granted basis, and can download data (if granted the permission to do so) as needed. The potential impact on quality of care is dramatic.

In addition to being a “library” of shared data, HIEs can serve to assist in public health surveillance. This can range from CDC-based surveillance of the emergence or prevalence of specific diseases, to FDA-based post-market surveys of the use of new medications (and shortening the timeline for identifying problems should they arise). This sort of use of HIE data is de-identified, so that permissions around using PHI are not violated – patient-specific data in HIEs is only used with permission, and used for direct patient care (e.g. downloading into your own EHR your patient’s immunization history).

HIEs, however, are essentially a “bridge technology” that tries to connect a landscape where health data remains segregated into “data silos.” A newer frontier of technology can be seen arising from web-hosted, Internet “cloud”-based EHRs, such as Practice Fusion. In this setting, a single data structure serves all practices everywhere, and local user-permissions determine which subset of that data are delivered as a particular practice’s “charts.” This technology raises the potential to actually share a common chart among multiple non-affiliated practitioners – based upon one physician referring a patient to another for consultation (with the patient’s permission to make the referral), both practices are then allowed access to the shared chart, see each other’s chart notes, view the patient medications, review labs already done (reducing duplication of services), see what imaging has already been accomplished, securely message one another, and even create their own chart-note entries into the common, shared chart.

This “new frontier” of technology, where clinical chart sharing between practices (based on patient permission) occurs across all boundaries of care, makes the Practice Fusion vision an “EHR with a built-in HIE.” Extending this even further – shared EHRs and linkage with Personal Health Records (PHRs) – is beyond the scope of this particular article, and will be addressed subsequently. With good design, as pioneered here, the balance between ensuring security and privacy of PHI on the one hand, and permission-based sharing of clinical information for the betterment of overall health care delivery on the other hand, a truly remarkable technology is being built. The impact on transforming health care is profound.

Dr. Rowley is a family practice physician and Practice Fusion’s Chief Medical Officer. Dr. Rowley has a first-hand perspective on the technology needs and challenges faced by healthcare practitioners from his 30 year career in the sector, including experience as a Medical Director with Hill Physicians Medical Group and as a developer of the early EMR system Medical ChartWizard. His family practice in Hayward, CA has functioned without paper charts since 2002.  You can find more of his writing at the Practice Fusion Blog, where this post first appeared.

If you liked this post you might be interested in these related posts:

Medical Data in the Internet “Cloud” (part 1) – Data Safety
Is “Cloud Computing” Right for Health IT?
Freenomics and Healthcare IT
Practice Fusion gets investment from Salesforce.com

September 27, 2009 in EHR/EMR, Privacy | Permalink

Livongo’s Post Ad Banner 728*90
Spread the love

Categories: Uncategorized

Tagged as: , , , ,

12 replies »

  1. Health Information Exchanges (HIEs) are a very interesting concept – one that I have not heard about before today. I definitely think they have their advantages, but I would still be concerned about the privacy of the records.
    It seems like anything and everything these days can be accessed via Internet. Having studied privacy law, I’ve learned that many medical records once made electronic can get into the wrong hands very easily.
    I don’t know much about technology, but I suppose if these clouds are highly secured, then, it’s a great step toward bettering health care.

  2. Don’t be put off by Steve’s cynicism; that’s the right way to look at any question about security. His questions are actually right on the mark; the system description does seem naive from a purely security point of view. However! In the interest of offering constructive criticism, let me offer the following observations:
    1. Anything that can be displayed on the local computer screen can be intercepted locally. I don’t know what particular technology you use to implement “what is seen on your computer in your browser is ethereal, and disappears when your session ends,” but even if it’s an image-only rendering that is not cached, it’s possible to grab the data. You may want to consider what you can do to prevent the local machine from misbehaving (for example, because it’s infected) and thereby allowing the data to bypass your normal protections.
    2. 20,000 patients and 10,000 practices is an exceedingly small number. Scale-up may be difficult. In particular, you may find that as you try to scale up, it will entirely different mechanisms to store and transmit data. It’s a wise idea to examine what failure points the system would have as scale increases up to, say, ten million patients. Experience shows that you’ll be surprised how much things change as you scale significantly.
    3. A notable flaw of this type of system is how to exchange data securely between HIE’s, a problem that in the long run simply cannot be avoided. Standardization is the usual answer, but it can be a long road to haul and is not a panacea.
    4. I assume you’re encrypting data in transit and, more importantly, at rest. If so, the most important question to consider is: who has access ti the decryption keys?
    Note that I’m a practitioner of cloud computing myself, and am certainly not opposed to its use. I agree that it is the wave of the future and of huge impact. I don’t believe, though, that cloud computing per se is as much of a security/privacy improvement as it is an efficiency and error-prevention improvement — areas in which it shows great promise.

  3. Dr. Rowley,
    I appreciate your approach on HIE. This bridge is very important because it shares the information between patients and physicians. It is important that medical information and labs reports should be shared with the patients, but it is also very important that confidentiality is maintained. The healthcare providers need to be educated about the latest technology so that none of the patient information is leaked and displayed to the unauthorized party. It was kind of surprising to me that the “ownership” of the medical records belongs to the people who prepare them. I would think that it should belong to the people/patients who the information is about. I think it is safe to say that all entities should follow the HIPAA Privacy rules since they are accountable and legally responsible for the patient information.

  4. Privacy should always be of paramount importance, especially within the healthcare industry where often very personal issues can be stored. Lack of privacy in every aspect of our lives is always attributed to the welfare of society, this may be the case in some areas, and acceptances can be made, but in this circumstance, I really feel that the indivudual is completly entitled to their privacy.

  5. Dr. Rowley, I don’t happen to believe that an HIE, or any other body for that matter, has the right to obtain, share or otherwise analyze PHI, whether identified or de-identified, without explicit permission, case by case and use by use, from both patient and physician.
    People have a basic right to privacy and I don’t think the CDC or any government agency has an automatic right to ignore it.
    There is also a flurry of private web sites that seem to be actively collecting patient data, whether through free PHRs or other applications. I don’t believe these corporations are interested in tracking the progression of H1N1.
    The need for legislation on this matter is pretty urgent in my opinion.

  6. Thank you for your commentary. A few items in response:
    Andrzej – yes, the risk of re-identification of data is not something to be minimized. This is something that the ONC, as it builds the National Health Information Network, and as regional eHealth Collaborative HIE efforts move from the planning stages to actual use, need to address. They are still in the building stage, and none of these efforts have yet to have any “real life” traction and usage – so now is the time to address what kinds of data elements to make available, and to whom. The ONC intends on using NIHN data for public health purposes. Disclaimers attached to permission, such that when clinical data is to be shared between practices that communicate via an HIE, there is also the permission that their shared data is to be stored in an HIE for defined kinds of public-health uses, will need to be developed.
    Alexander – the difficulty in different systems being unable to “talk” to each other has to do with different, proprietary data structures being used by different EHR systems – there is no one data-structure representation of a clinical “chart” that holds from one system to the next. You cannot simply “export a chart” from an Allscripts to a NextGen (or even from a NextGen installation built around cardiology templates to a NextGen installation built around oncology templates, since their data structure is template-centered). So the best they can do to exchange data is through standardized CCRs or CCDs. The need to retrieve data into one’s own EHR, and the ability for someone else with data around that same patient to upload the information offered for sharing, is, of course, asynchronous. The uploading needs to be placed somewhere – an HIE – so that it can be requested by another EHR at another time.
    Margalit – shared data and permissions around it are complex. For physician-to-physician exchange of data (e.g. making Mr. Smith’s immunization history sharable from the pediatrician to the family physician or internist), the permissions are patient-centered. Just like with paper – the patient says, please share this information with this specific physician. Then the data is uploaded to the HIE “library” by the sending practice, for download (whenever) by the receiving practice (and only that specified practice) – and such data is patient-identified. As the HIEs accumulate more data (they haven’t done this yet, so it’s still pretty theoretical), then use of that store of data (as the ONC envisions) in aggregate, and in de-identified ways also opens up. Where is H1N1 influenza showing up across the country? Where are there “hot spots” for disease occurrence like cancers around the country? And so on. This requires carefully de-identified data, to overcome the concern raised by Andrzej.
    Steve – you seem to be mainly cynical, and I don’t see you offering much in the way of constructive commentary. Shared data via HIEs is in our future, and the privacy questions raised by others are legitimate, deserving of constructive solutions. The article is written from the perspective of the experience of Practice Fusion, which is a cloud-based EHR currently with about 20,000 users and 10,000 practices being actively supported. As opposed to template-centered EHRs, which have a different data structure for every template-based installation, the Practice Fusion database has a unified structure such that a chart can actually be shared across multiple specialties, each one using a custom “Smart Template” set of tools and UI. Yes, it is deployed in a distributed fashion such that system responsiveness remains very fast even as utilization scales up – continual attention to this, and plans for anticipating greater demand are a focus of our development efforts. There is no “open access to PHI behind the walls” as you intimate, and I challenge your statement that one can use such a system to “copy 5 million records stored electronically” – given good security design, a cloud-based system like ours does not have that susceptibility. And we continue to do ongoing security and privacy auditing, including engaging outside consultants, around this matter. Such a risk does exist, however, with locally-installed systems – if you have PHI downloaded onto a computer in your office or home, then theft of that computer can result in theft of PHI. With the Practice Fusion cloud-based design, what is seen on your computer in your browser is ethereal, and disappears when your session ends; there is no locally-cached PHI in your computer (by design). Theft of your local machine does not result in theft of PHI. This is an important point to make concerning privacy, security and cloud-based EHR solutions. You can read more at http://www.ehrbloggers.com
    -Robert Rowley, MD

  7. To me, this post seems rather naïve and a bit pie-in-the-skyish; apparently not based upon any current and/or near-term healthcare systems development, operations and/or technical capabilities.
    I find it very hard to believe any ‘cloud-based’ approach to storing medical data can be served by a ‘single data structure.’ Do you actually mean a single, physical data store? Or multiple physical data stores somehow connected into a single logical data store?
    So even if local user-permissions and other means of logically separating and controlling data access to medical data – whether contained in a single physical database or maintained across multiple logically interwoven physical stores, there will be daunting data access control, physical data interchange, data synchronization, audit/tracking and latency/performance challenges. And what about the overhead and risk associated with administration and user/patient access management challenges? I could see companies who don’t get their arms around these very important health care data access, privacy and data distribution topics becoming sacrificial lambs for the great health care IT debate of 2009. My point is that one-size does not fit all.
    But toss all that aside and consider this aspect of Data Privacy and PHI: it’s way easier for a mildly competent, well-meaning techie or even a somewhat disgruntled power user to copy 5 million medical records stored electronically than it is for some scheduling clerk at a doctors office or some utilization management intake person at a payer site to copy a few paper records. And the electronic data can be altered, forwarded and generally be used to create a lot more misery than a couple of paper records might initiate.
    As for firewalls, data encryption, multi-factor authentication and all that other technology? Ha! That’s all feel-good stuff for those who are clueless – actually pretty much a joke because…what about all those software designers, developers and testers who essentially have carte blanche access to production clinical and administrative data? Data on the unencrypted, easy-accessed-side of the DMZ? What about all the off-shore ‘resources’ who have access to these data? Don’t tell me that “Business Associate Agreements” cover this.
    So to me it seems sorta naïve…but to be sure, I’ve only been in IT for 25 years and healthcare IT for 15 years so I’m prolly not someone who can speak to this topic. Go ask a physician. They’ll usually believe anything an IT Guy will tell them…like ‘encrypt the data with 256 bits and call me in the morning!’
    All good
    Steve S.

  8. I am not clear on the “library” concept. Does the sharing of de-identified data require patient permission? Physician permission? Or is it just a given that copies of de-identified data can be freely checked out of the library?

  9. Thank you, Dr. Rowley; I am with you as far as advantages of cloud-based EHR systems are concerned.
    “…HIEs are intended to be data-exchange platforms between practitioners who might be using different EHR systems (that do not natively “talk” to each other).”
    In my view, this statement deserves some clarification. If two EHR systems cannot talk to each other, is it because they are not connected, or speak different “languages”? If the latter, how are they going to talk to the RHIO? But if they (and the RHIO) use the same exchange protocols and formats, why don’t they just communicate directly? In most cases, RHIO provides some sort of UI that aggregates patient records from different source systems, which you use instead of your own EHR application.

  10. Thought I would pass on the following article which highlights why there is no such thing as real anonymization/de-identification any more, due to the science of re-identification.
    http://arstechnica.com/tech-policy/news/2009/09/your-secrets-live-online-in-databases-of-ruin.ars
    In light of this, the release of medical information by HIE’s should be reconsidered since re-identifying patients would not be very difficult. The fact that you can uniquely identify 87% of Americans with only zip code, date of birth and sex highlights the problems with releasing of so-called anonymized data without appropriate laws and regulations.

Leave a Reply

Your email address will not be published. Required fields are marked *