Applications and web tools to engage patients and healthy people are potentially the most exciting facet of health IT. This type of software, when designed and used well, can be a source of tremendous patient empowerment. And the patient experience needs a radical transformation, because—in case you have never dealt with an extensive illness—being a patient can be demoralizing, frustrating, and humiliating. The unsettling burden of serious illness is often augmented by the task of coordinating care between various institutions, a task forced on many patients and caregivers.
The more complex a patient’s condition, and the more experts that a patient has consulted, the more difficult the coordination of care becomes. Any person who frequents hospitals has seen the poor souls for whom this has become a Herculean task. They are easy to spot. They usually carry a travel briefcase, complete with rollers. The briefcase contains copies of all the patient records they have accumulated as they meander through the healthcare system. The healthcare system in the United States is easily one of the best in the world, until you need more than one doctor. A single doctor in the United States has met one of the highest standards for medical education in the world, but the system as a whole has been operating in a disconnected fashion for decades. Patients have been forced to coordinate their own care, and when a medical record is paper-based, this can be a daunting task indeed.
Two technologies together should make the process of coordinating care much simpler. One of them is the Nation Wide Health Information Network, which will become the Health Internet (discussed later in Chapter 11), and the other is patient-facing health records. Both of these approaches are required by meaningful use. Moreover, many meaningful use requirements will become much easier to accomplish using personal health records (PHRs) or PHR-like extensions to hospital and clinic technology.
Remember when we were trying to decide how to parse the names for EHRs? PHR terminology has dilemmas of its own. It is difficult to know just what should qualify as a PHR.
The names for patient-facing software solutions are varied and controversial. Most people refer to patient-facing healthcare software as PHRs. Some people insist that they should be called PCHRs, or personally controlled health records. This distinction was particularly important in the early days of PHR development. Many PHR systems were simply viewers for patients into their own record inside an EHR system maintained by the institution they were visiting. The patients could see and copy the data, but they could not modify, create, or even comment on the data inside the system. The term PCHR was emphasized as a way to distinguish this “window PHR model” from systems that were under the control and direction of the patient.
It is not clear how, or even if, PHR software is different from EHR software. The Tolven project is an open source health record that has two interfaces, one for patients and one for healthcare providers (doctors, nurses, etc.). The Tolven project holds that the healthcare record should be stored in one software system, and that the difference between a PHR and EHR is merely a question of what users have what privileges.
But most people assume that PHR software should be separate from EHR software, and as a result, it usually is.
There are two popular PHR configurations. In the “tethered” model, a body that controls a repository of patient data opens up that data to the patients in question. Patients’ queries or changes to the PHR get passed through to the data source and display the data found there, allowing patients to modify and generate data to different degrees. The tethered PHR has often been guilty of the window PHR design. Even when tethered PHRs allowed patients to enter and change data, they created yet another silo of disconnected patient data.
Usually tethered PHR systems are offered by hospitals or clinics, but insurance companies, pharmacies, lab test companies, and countless other organizations have patient data and release that information directly to the patient through PHR systems. Most common tethered PHRs are web applications. As an experiment, you might take a moment to discover just how many PHR systems already provide you with access to your own healthcare data. You can expect one from each insurance company, one from each large hospital you have visited, and still another if you are a veteran covered by the VA.
The other historical model for PHR systems has been the stand-alone PHR. This allows consumers to enter their own clinical data, and organize and manage that data online. During the dot-com boom, many stand-alone PHR vendors received funding from venture capitalists. Most of the dot-com PHR companies went out of business once the venture capital ran out. Business plans based on assumptions that patients would pay for the privilege of performing data entry of their own health data failed. Most commercial PHR systems now assume that patients should not need to pay for the PHR service, and that data entry be kept to a minimum. When manual data is required from the users, modern PHR services ensure that something of substantial value to the patient is delivered as a result of that data entry. Mere classification and structure is not enough to motivate most patients to enter health data manually into a PHR system.
Although the difference between tethered and untethered or stand-alone has become entrenched in modern parlance, both are based on assumptions that are no longer true. Most important, it is no longer a reasonable assumption that movement of data from EHR to PHR should be one-way. Both the siloed PHR with no integration with anything and the tethered PHR with only the capacity to import data from an EHR are largely dead concepts. Modern thinking about PHRs presumes that useful data should flow bidirectionally between PHR and EHR systems. In the last decade it was a good assumption that data in an EHR either was generated by local clinical users of that EHR or imported from some other EHR, but over the next decade this will become a bad assumption. EHR users and technicians should carefully consider this chapter, because soon the data sent to PHRs will automatically appear in your EHR systems. Even if you are not directly working with a PHR, you will probably need to deal with PHR-sourced data.
Meaningful use will be interpreted as a mandate for tethered PHR systems at a minimum, but both the tethered and stand-alone models will soon be left behind by more advanced PHR deployment models that defy easy categorization. The first such model is the PHR platform.
The two dominant PHR platforms are Microsoft HealthVault and Indivo X. Google Health had been a dominant platform, but as of June 2011, Google retired the Google Health project and will no longer offer a PHR.
When Google and Microsoft decided to enter the PHR market, it spelled the end of the already struggling dot-com startups that had focused on developing stand-alone PHR systems. Microsoft HealthVault was released in 2007 and Google announced Google Health in 2008. Both Microsoft and Google announced that they would not only be developing a costless consumer-facing PHR product, but would also be releasing an integration layer for the PHR systems. They invited third-party developers to offer new and interesting functionality on top of their basic functionality and invited healthcare data sources such as hospitals and clinics to upload data on particular patients using the same interfaces.
Philosophically the technical approaches could not have been more different, or more indicative of the different technical styles of the two companies.
Microsoft designed HealthVault to support almost any reasonable health data operation, including the storage of digital data and arbitrary data types. You can upload medical images studies to HealthVault, for instance. Most important, HealthVault includes extensive libraries for embedded applications. Microsoft knows how to develop the software that runs devices and created a Software Development Kit that allows its software to be easily embedded directly into computers and devices that gather healthcare data, as long as those devices are running either a Microsoft operating system or are near a Microsoft computer. HealthVault extends the Microsoft Windows Portable Device architecture to support health and wellness data. The notion is that if a device manufacturer interfaces at a low level with the Microsoft operating system, they can leverage that interface for simple HealthVault PHR connectivity.
HealthVault has had an interesting relationship with the Open Source health IT community. Microsoft promised to release the specification for the HealthVault application programming interface (API) under Open Source friendly licenses. Originally, they had intended to release the HealthVault API specification under the Microsoft Open Specification Promise (OSP). This is a strong promise that was created, as part of the European antitrust compromises, for the open source Samba project to have access to protocol specifications. Ultimately, Microsoft did release the specification, but under a much less generous specification license. So far, no Open Source implementation of the HealthVault API exists. Microsoft has been criticized for its protocol licensing, but Google Health, its main competitor, has no mention of protocol licensing at all. This issue has been critical now that Google is abandoning all of the companies who invested in their API. Given how badly these organizations have fared with the retirement of Google Health, both of these interface standards are likely to be mildly interesting historical footnotes, as we move toward well-adopted open standards for healthcare interoperability. The Direct Project (see The Direct Project/Protocol), now that it has support as Google’s mechanism for allowing users to migrate, will likely become the default PHR integration API.
The notion of presenting a proprietary API for PHR platform integration made perfect sense in the age before meaningful use. Now it is apparent that standard and open protocols will be at the heart of future health IT integration. This progression would never have been possible without the interchange requirements of meaningful use, and the strong position that Office of the National Coordinator (ONC), the shepherd of the meaningful use standard, has taken with respect to health data exchange protocols. Because of this, standards like the Integrating the Healthcare Enterprise (IHE) and Direct, which are discussed fully in Chapter 11, will likely serve to connect EHR systems with PHR systems like Google Health or Microsoft HealthVault.
Surprisingly, one of the most significant contributions that Microsoft, or anyone for that matter, has made to health IT has been toward an open source project. The Direct Project is a critical piece of what will become the Health Internet. Contrary to Microsoft’s typical stance on open source, the HealthVault team was active in the project from the beginning, strongly advocated for open source values (i.e., simplicity and equality) during critical decision points on the Direct Project, and created an open source .NET implementation of Direct that, alongside the Java implementation, enabled the first proof of concept of the Direct networks. Microsoft has bet far more heavily on the Direct Project than Google Health, and is the first PHR system to offer Direct addresses to the public at large.
The Direct protocol, and its companion protocol IHE, together make the question of integration somewhat moot, but rich APIs are still going to be important in the PHR platform space. The Direct protocol is focused on super-simple point-to-point health data interchange, whereas IHE is primarily focused on the complexities of health data exchange between healthcare institutions. There remains an unmet need for a set of interfaces for applications to provide cutting-edge functionality between third-party patient systems and PHR platforms. Given the unclear nature of API licensing available from both Google and Microsoft, a third platform, Indivo X, will probably prove to be the dominant API platform for interfacing between patient facing health information systems.
Google Health released an API that centered on a subset of the Continuity of Care Record (CCR), which is a clean, relatively simple XML-based standard for healthcare records that we discuss further in Chapter 11. Google embedded the CCR content inside an ATOM feed. ATOM is an XML standard for changing the content of a target document that receives the feed. ATOM is an upgrade to the more familiar RSS, an XML standard that allows for the easy parsing of the contents of blogs. ATOM is used more generally for tracking any kind of constantly updating data. It is unclear at this stage what will become of the Google Health API. Although this might change soon, at the time of the writing there are no plans to release Google Health as open source or to release the Google Health API as an open API standard.
Google Health will probably have more influence on the PHR market in the way that it ended than with anything else it has ever done. In the blog post that announced the retirement of Google Health, Google endorsed both Microsoft HealthVault and, more important, the Direct Project as a transfer to migrate data out of Google Health:
Over the coming weeks we’ll also be adding the ability to directly transfer your health data to other services that support the Direct Project protocol, an emerging open standard for efficient health data exchange. And while we’ll discontinue the Google Health service at the beginning of 2012, we’ll keep these download options available for one more year, through the start of 2013. This approach to download and transfer capability is part of Google’s strong commitment to data liberation principles: providing free and easy ways for users to maintain control of their data and move it out of Google’s services at any time.
Ironically, this was the first formal announcement from Google Health that they would be supporting the Direct Project protocol. By the time that Google Health supports Direct-based export, there will probably be several PHR systems that support Direct-based import. However, Microsoft HealthVault was the first provider to launch publicly available Direct addresses (Direct is essentially a secure email protocol focused on delivering clinical data) and was the only PHR service specifically mentioned in the Google Health retirement announcement as a viable alternative.
Indivo X is the latest iteration of one of the longest standing PHR development efforts in the world. Work on predecessors of Indivo date back to 1994. Both Google Health and HealthVault had the benefit of developing while the lessons and source code from early versions of Indivo were available. The industry regards the Indivo project as the grandfather of PHR systems.
In 2006 a group of employers decided that their employees might benefit from access to a PHR system. They concluded, correctly, that most people would not be comfortable with the notion that their employers had easy access to their complete health record. As a result, several large employers, including such giants as AT&T, BP, Intel, and Walmart, created a foundation called Dossia. Dossia decided to use the Java version of the Indivo system as the basis for their PHR platform. This was a tremendous vote of confidence for the Indivo team, which was already deep into the third generation of its PHR development.
The latest iteration of Indivo is called Indivo X, and is obviously a fourth-generation effort in the PHR arena. The genesis of the design made a tremendous splash with an perspective article in the New England Journal of Medicine in 2009.[5]
The Indivo team advocated for deeper investment in several principles for PHR platforms, specifically evoking the effective model that the iPhone app store was just pioneering. The article laid out several principles that are deeply ingrained in the architecture of Indivo X:
The platform should not introduce impediments to the open flow of data.
The platform should support subapplications that should be replaceable by the end user. So if you do not like your blood pressure module, you should be able to replace it with a better (for you) module.
Friendly to both open source and proprietary software and licenses.
Multiple instances of Indivo X are expected to be installed and effectively operate separately, cooperating to make data liquid between Indivo X instances. This principle is not specifically mentioned in the article, but can be deduced as a major goal of the project.
Indivo X offers a platform for applications. In itself, Indivo X provides a data storage facility and an API. The applications are responsible for providing everything seen by the patient or clinician who is entering or consuming the health data, whether it be a mobile app, a web interface, or data exchange with a medical device. Indivo X is built using Python, but provides the current standard for programming interfaces—a RESTful API—to allow applications to be written in almost any language.
Although both the Google Health and Microsoft HealthVault platforms support some of these principles, or to some extent even all of the principles here, only the Indivo X platform has been architected to embody these notions fully.
Recently, the Indivo team has been trying to take many of the same concepts embodied inside Indivo X and extend them to a more general health IT application. That effort is called the SMART platform and has received both funding and attention from the U.S. government and other major healthcare players. Eventually the principles behind Indivo X and SMART could lead to a radically different notion of how health IT should be architected generally. Currently, SMART is very new, but Indivo X has established itself as one of the three dominant PHR platforms, and the leading open source PHR project.
One of the most difficult challenges for any patient-facing system is whether and how to allow sharing between its users. Most people simply do not care that much about their privacy, as evidenced by their utter lack of outrage toward Facebook, which regularly flouts its ability to change its privacy policies and privacy architecture. But most people view Facebook as part of the public sphere, and make different assumptions regarding their health information. For the most part, PHR systems place greater technical controls on the exchange of health information. Users must make obvious and significant choices when they decide to share with other users.
We will discuss issues related to children having PHR records, and the laws that cover PHR systems in the discussion of health IT regulations LINK. But for now it is enough to know that most typical PHR systems, especially the platforms already mentioned, have spent considerable energy ensuring basic privacy functionality.
A new category of software for patients appeals specifically to people who would rather share generously than have specific privacy controls. Many of these sites support different forms of open discussion between patients. Often, users participate in these discussions using their real names, but using pseudonyms is also popular. A pseudonym usually takes the form of a username that cannot be mapped to any real name. If people participate in an online patient community with the names ftrotter and duhlman, they can easily be mapped to real-world identities. But usernames like ThatGuyInHouston or ItsADryHeat help protect the “real-life” identity of patient community participants.
People who embraced public or semipublic discussion of their own health care started with the same technologies that built the initial phases of communication and collaboration on the Internet, forums and mailing lists.
The grandfather of all patient hubs is ACOR, the Association of Cancer Online Resources. This mailing list has tremendously knowledgeable patients, patient advocates, patient caregivers, and even doctors who often provide more specialized information regarding available cancer therapies than most doctors are aware of. At least that was the experience of Dave deBronkart.
E-patient Dave,[6] as he is now affectionately known, was diagnosed with metastasized stage IV cancer (that’s “bad” for my geek readers). By following advice from the ACOR mailing lists, Dave was able to find a treatment that cured him. Dave’s experience was especially interesting because if he had followed the standard treatment path, his chances would have been substantially poorer and he would have disqualified himself for the experimental treatment that ultimately worked for him. Dave brings an engineering approach to being a patient that should appeal to any geek. His book is both readable and relevant for anyone who wants to engage seriously in health IT.
But e-patient Dave did not gain notoriety for his ability to effectively navigate the healthcare system. In fact it was his online review of his experience using Google Health that ultimately lead to his fame in health IT. Some people have taken to calling his experience “e-patient Dave-gate.” He wrote a detailed blog post that showed the strange errors caused by the import of his medical record from Beth Israel Deaconess Medical Center (BIDMC) into Google Health. These errors were focused on how Google and BIDMC relied on medical billing data as reliable clinical information. Several of the Google Health integrations, including pharmacy integrations, have had this issue.
Back to ACOR. ACOR is based on very old Internet technologies. It is basically a garden-variety combination of mailing lists with online archives. What was revolutionary about ACOR was how it was being used, not the technology that powered it.
Each subsequent improvement in the Internet’s capacity to allow people to connect with each other and to allow patient-to-patient support has been fully embraced by a vibrant subset of patients who, as we’ve seen, refer to themselves as “e-patients.” Modern social media outlets, especially, have generated a movement to allow patients to empower themselves by communicating and educating each other using. Patient communities have become common on Facebook. Often, more specialized social media tools, like Ning (which allows you to set up a miniature social network) have been specifically leveraged to set up targeted patient communities. A useful experiment is to search Twitter for specialized patient content like #paralysis or #multiplesclerosis.
Watch your friends’ posts to Facebook carefully. Often your connections will be using Facebook to log their health experience. Here are modified and deidentified Facebook posts from a person who is attending the Mayo Clinic for nerve damage:
I’m super sick today. Also please pray for my blood pressure & heart rate to become normal - they’re running low this morning. I’ll be glad when I am able to post something other than health stuff in my status.
Mayo diagnosed me when I was 16. The nerve damage to my organs is why I have so many health issues. My trips to the Mayo clinic are for monitoring organs and addressing new issues with them. My husband & I have beautiful goals for our life. In “sickness & health” ... We are blessed. Xoxo
So tired of the pain and nausea... :( I can either just suffer or turn my sufferings into something amazing that wouldn’t be otherwise. So I’m off to write...
Had a rough week. Stomach is bleeding. More diagnostic tests tomorrow. Praying now, because I’m physically done.
Of course, her friends responded with encouragement and offers for support. What is important here is the mix of health data with social and spiritual content. This person is using Facebook as a kind of practical catharsis; chronicling her condition, coordinating her care with her support network, and having a kind of public prayer journal. Facebook is the medium, but this is clearly health data, sometimes extremely specific. These journal entries have been anonymized and changed substantially in this book, but this person has recorded this information with little regard for her privacy. Given the size of her social network, and the way Facebook extends posts to friends of friends, she is effectively publishing her health details to a population equivalent to a small rural town.
The e-patient movement has that moniker precisely because the community recognizes that their use of “electronic” tools has an empowering effect. The e-patient movement, which is loosely organized around a blog, a whitepaper, and a nonprofit, the Society for Participatory Medicine, is focused on technologies that improve the ability of patients to engage in their own care.
There are a surprising number of resources available to patients on the Internet now regarding health information. Of course it is obligatory to mention sites like WebMD that have become standards of information that patients can leverage to gain information about health-related issues. But very often there are resources that go beyond the overview that these type of sites offer. Sometimes these resources are dangerous, as evidenced by the compelling “tale of two e-patients”, but this danger is commonly vastly overestimated. Good research shows that typical search results on health topics on the popular Internet search engines typically return solid health information (which is constantly improving). Patient communities have very low error rates, and generally self-correct when they do have bad information.[7]
E-patients typically have tastes for deeper levels of information than are available on “for public consumption” health information websites. Invariably, websites like WebMD offer an accurate summary of a health issue, but then end with something like “Be sure to ask your doctor....”. That phrase is generally evidence that the resource in question is intentionally abdicating any attempt to be an in-depth resource on a given health subject. In many cases, a patient is seeking to correct the fundamental information asymmetry in health care. Is the surgeon recommending surgery for me because it is what is best for my care, or because he gets paid $2,000 every time he conducts surgery? If an e-patient is trying to evaluate a doctor or doctors, ending with “Ask your doctor” is particularly unhelpful. What e-patients want is access to the same information that the doctor has. More and more, that information is available. In many cases, there are services that help nonclinicians parse the information on a particular procedure or condition that is aimed at doctors.
Wikipedia is surprisingly useful for this. Wikipedia has become more and more stringent in the standards for articles, and health or medicine-related articles receive constant attention. A large part of recent improvements to Wikipedia’s articles include more numerous and accurate references. A Wikipedia search on any subject will link to articles in the New England Journal of Medicine (NEJM), the Journal of the American Medical Association (JAMA), or Pubmed, precisely the type of resources that are aimed at doctors, and just the sort of thing e-patients crave.[8]
But Wikipedia is just the beginning of new and innovate ways for patients to become hyperinformed about medical issues. Up To Date is an expensive service that provides doctors with the most recent scientific consensus around a particular health issue. It now has an offering specifically designed to enable patients temporary and inexpensive access to the same information. This resource is perfect for patients who only want to know lots of information about one or two issues in any case.
Other patients are seeking to gain new information advantages in a different way. Participants in the quantified self (or quantters) movement seek to improve their health by obsessively measuring anything they can. In centuries past, there were a few cases of individuals given over to a deep desire to record and journal every aspect of their lives. Today, a much less obsessed individual can automatically record far more data about himself using digital devices.
Quantters use smartphones to track many different kinds of things, but are also willing to purchase specialized devices that record specific information. Fitbit is an accelerometer that can track almost any type of movement (an advancement over the pedometer, which only records steps). The Zeo is a device that tracks your sleep patterns. Over-the-counter glucose monitors can provide simple access to glucose data and, using USB interfaces, upload it to a computer. With a prescription it is possible to get a glucose monitor that you wear all the time, providing the kind of near-real-time data feed that quantters crave. Another device, the Withings scale, allows users to automatically broadcast their weight to Twitter and Facebook each time they step on the scale. The list of manufacturers that provide consumer-oriented healthcare data devices offering direct integration with multiple online data sources will continue to grow. In a few years each of these devices, which are now very unique, will be product categories with several competitors.
Many quantters pipe the data feeds from these devices to Twitter, which has become a data layer of choice for real time-health data. When there is no device to record data, quantters can use parser-friendly syntaxes like ohme to write data about what they ate or an analog measurement they just took, knowing that a parser can later quantify the time-stamped data. Ohme is an example of a micro-syntax, which allows very dense healthcare information to be stored in a very small space.
Soon inexpensive accelerometer technologies will enable the movement associated with any object to be tracked and quantified. It will become possible to place a sticker on your toothbrush containing an embedded accelerometer that tracks the movement of the toothbrush and automatically uploads the data to the Internet. It is not too far-fetched to imagine that soon your toothbrush will be communicating directly with your PHR record, which might automatically forward that information directly to your dentist.
For instance, the Withings scale integrates directly with HealthVault. Although the most extreme quantified self practices will probably never take hold in the general population, real-time health and fitness data will soon become a natural part of EHR and PHR systems. Some of the most avid quantters are e-patients who seek to use hyperaccurate information about their asthma attacks, migraine headaches, or just random pain to discover and eliminate the unexpected causes. The Robert Wood Johnson Foundation, one of the most important funding foundations for healthcare informatics, has specifically funded projects oriented toward recording observations of daily living (ODLs). For those who suffer chronic pain of any kind, information about what “sets off” the pain is crucial for a normal lifestyle.
The types of devices and data sources continue to expand, blending entertainment, social media, and healthcare IT. EA Sports, a video game company, has released a heart monitor that integrates with video game consoles like the Microsoft Xbox and the Nintendo Wii. This, in combination with the ability of the game consoles to accurately capture movements using devices like the Microsoft Kinect, will provide hyperaccurate fitness data that has never been available before. Is the EA Sports application a video game that requires movement, or a special-purpose PHR system? The answer is probably “yes.”
Perhaps the most relevant information that such devices will soon generate is compliance data. Generally, the word compliance is shortened from compliant with doctors instructions. It should be obvious how systems already in use by the quantified self community could be used to measure compliance with diet and exercise instructions. But even more concerning to clinicians is medicine compliance. Patients suffer when they fail to take medications properly, but often they are not the only ones hurt. The ongoing battle to prevent the spread of resistant bacteria is hampered by patients who stop taking antibiotics after they “feel better.” Failure to comply with medicinal treatment plan is an expensive problem. Currently, the best source of compliance data is medicine refill data. If a person refills a prescription regularly, it is a reasonable assumption that he or she is taking the medication properly.
In the future, there will be no reason to make this assumption. There are two approaches that are already in limited use that will track medication adherence far more accurately. The first is a device that replaces a medicine bottle cap with a sensor that can tell when the medicine bottle is being opened. Of course this device cannot tell how much was taken at a given time, but it can tell the schedule when the medicine bottle was opened. In the future, tiny radio devices will be embedded inside pills that will allow each pill to be accurately tracked through a patient’s digestive system. These types of personal data quantification will allow healthcare providers to have hyperaccurate measurements of patient compliance.
Social media, advanced gaming, and the capacity for devices to automatically gather a huge depth of data truly is a paradigm shift in health IT.
Perhaps the most interesting use of social media in healthcare are the new generations of applications that blend the definitions of PHR and social network. This new generation of consumer-facing applications, often under the flag of Health 2.0, is giving patients condition-specific tools to track their healthcare data and then share it in a social context.
Patients Like Me is emblematic of this new type of application. Patients Like Me provides health data tools in a social media context that are targeted toward patients with a particular condition. For instance, in the HIV positive patient community at Patients Like Me, you can review a person’s history of CD4 cell/mm, CD4 percent, and viral load. Patients with severe life-altering conditions usually have more than one, especially depression, which almost all patients with serious conditions must battle at one time or another. Patients Like Me allows patients to connect with other patients who are going through the same things they are. If an ALS patient is considering intensive outpatient group therapy for treatment of depression, he or she can find out what another ALS patient thought of that option after having taken the therapy.
Patients Like Me is a leader in the field, but it is hardly without competition. There are several other websites that are offering similar services.
You will find that health IT “experts” like to make definitive statements about PHR systems (and health IT systems generally) , but when you consider a system like Patients Like Me, Xbox Kinect, or even Facebook as a PHR system, it becomes obvious that patient-facing health IT is moving faster than our convenient categorizations for them can keep up. As with other subjects in health IT, the most important thing to learn from this section is that there is more than one way to reasonably approach the same set of problems.
For some people, a full discussion of the types of data that will and are being gathered on individuals is always uncomfortable. It is really not possible to discuss these technological improvements without considering privacy, but we consider it last because it is difficult to consider privacy without understanding just how much data is going to be generated.
Practitioners tend to disagree on what patient privacy means, or what the implications are. As we have seen in this chapter, a new generation of patients think nothing of publishing everything about themselves online for the whole world to watch. They have learned something that many in older generations do not yet understand. For the most part, publishing health information online is perfectly safe because no one is paying attention. Or rather, the attention that publicly posted health data gets is general use for data mining purposes. It is used to make conclusions about populations rather than conclusions about individuals.
For the most part, the public is excellent at ignoring health data of any kind. If you are unlucky enough to have a serious medical condition, and you decided to publish this information on the Internet, you would have a very difficult time getting people to even notice that the information was there. Many people choose to blog or tweet about their healthcare and only the very best and frequent writers are able to maintain even a small audience. Publishing your health information on the Internet does not typically matter because the Internet audience does not care about you or your health information. Your health insurance company has so much data about you that it cannot fully process it. Currently, insurance companies are probably not going to go to your Facebook page and look at your posts.
This will change, and perhaps soon. Insurance companies make more money when they correctly identify an individual as a high risk. In any insurance market, if insurance companies can develop a substantial evaluation advantage over their competitors, they have the temptation to “cherry pick,” providing insurance only to those who are very unlikely to ever need it. Hopefully, insurance regulations will make such cherry picking impossible before patients’ social media postings and full purchasing history are used to exclude them from insurance coverage.
The best way to solve the problem of health insurance company privacy violations is to negate the financial benefit of gathering the information. This was one of the goals of the health insurance reforms put in place under President Obama. Hopefully these changes will help ensure that health insurance companies do not have a financial incentive to use social media or PHR data against insurers. If it is not prevented at a policy level, it is reasonable to assume that data that you post about yourself on Facebook or Twitter, or even what you buy using your credit cards, could someday be used to determine your health insurance rates.
The real difficult issues of privacy have nothing to do with the Internet and everything to do with your personal relationships. Many people want to keep specific details about their health from their spouse, their parents, or their employers. PHR systems are designed to share information only with those whom you authorize. Most PHR architectures, including all three of the major platforms that are mentioned here, spend a tremendous amount of time making sure that the information does not “leak” onto the public Internet.
But personal privacy, especially among family members, is very difficult with PHR systems. It is a little easier to exclude employers, who are already excluded from most health care data by default.
Let’s imagine a spouse who has contracted a minor sexually transmitted disease (STD). The law (HIPAA) says that the patient can expect that fact to be entirely private information between the patient and the medical staff. Previously the couple had used a tethered PHR system offered by the hospital to get lab results back. Both wife and husband had access to each other’s accounts using the sharing function. When one member of the couple discovers an STD as the result on an infidelity, that person would want to be able to either exclude that data from his or her PHR, or find a way to disable the access that the spouse previously had to his or her PHR record. Either or both should be enabled by smart filters at the interface between the PHR and the EHR, and by careful filtering between data elements on a PHR chart. This is a fragile situation. It is easy for an “unrelated” data point to slip through and compromise the secret. For instance, imagine the “in-the-dark” spouse reading on the PHR record about a mysterious “appointment” at the clinic, or perhaps an automated appointment reminder phone call that the “in-the-dark” spouse intercepts. The simplest way to avoid these types of problems is to detect when this type of problem might occur, and move to human-to-human voice-only communication regarding the issue. But even this can be problematic. Imagine a dialogue beginning, “Honey, why does Jane call us for every appointment reminder now, and why can’t I log in to the PHR anymore...” Tricky stuff indeed.
PHR/EHR systems with adequate privacy and security controls can mitigate these risks, but most health staff are not trained well enough on the software to understand how to filter data carefully. Over the next few years, as health data generally becomes more liquid, we’re likely to see more and more slip-ups that are attributable not to the technology itself, but rather to lack of familiarity with the technology.
The other patient data access issue that is worth mentioning explicitly is children. A favorite quote from a friend who is the CIO of my local children’s hospital is, “In health IT, children are not just short adults.”
Divorces, child abuse, teen pregnancy, and countless other child and teen-related health IT issues will be very difficult to get right over the coming years. Most PHR systems assume that sometime during the teen years (the particular trigger varies across states), patients gain the right to have health data privacy from their parents. Often this change can be the result of an event (teen pregnancy or HIV status change) rather than an age. This is a very difficult area to automate, because state laws vary dramatically on what rights children and parents have at given times.
Soon, access to child’s PHR might be an item negotiated in divorce settlements. For now, when both parents of a divorced child have access to a shared PHR record for a child, information about treatment for a broken arm can become evidence in competence hearings. Of course, if a child was being abused by a step-parent, then the parent without custody perhaps should have a right to information such as ER visits. Who gets to see the information, and what they get to do with it, are difficult decisions made on a case-by-case basis. These are just a few of the issues that will make children’s or pediatric hospitals and clinics typically late PHR adopters.
Privacy advocates sometimes give in to fear mongering over their chosen issue, but most Americans are far more concerned about too little data liquidity than too much.[9]
In fact, in the future, PHRs will become a critical means for patients to manage this data liquidity. Many if not most health records have errors. Sometimes these errors are simply the presence of discarded diagnoses that were temporarily used for billing purposes. Sometimes the errors are far more serious, such as missing or extra allergies or incorrect medications or dosing. When health data becomes more liquid, data integrity will become a far greater problem than patient privacy. In the future PHR or PCHR systems will be the central way for patients to combat health misinformation in an automated fashion.
There are several stages of meaningful use requirements related to PHRs. Rather than discuss the current revision here, which will soon be out of date, we list the fundamental areas that relate to patient-facing health IT systems.
Patient reminders and preventative care notices could include text messages, automated phone calls, emails, messages through the Direct network, or contact through the PHR. There are HIPAA concerns regarding health data sent across insecure channels, but text messages and emails that simply say “Call us” or “Log in to the PHR” should be fine. There is also a specific requirement to support secure patient messaging (i.e., Direct) and to record and respect the patient’s preferred means of digital communication.
Regarding direct patient access to data inside an EHR system, there are several meaningful use requirements for access through a system that sounds very much like a tethered PHR. The software must be able to provide a complete copy of electronic health information on request, specifically the ability to view recent data through a web portal soon after discharge. Patients will need to be able to browse and filter data, even if that data did not originate from within the clinic or hospital that is offering the web portal. Patients will need to be able to download this in human readable (e.g., a PDF) and digital (e.g., CCD/CCR) formats.
To achieve comprehensive certification, EHR vendors must be able to support all of the core and menu-set meaningful use requirements. Given that, most EHR systems will have simple tethered PHR options. These PHR components vary wildly in quality and style. A clinic or hospital could also simply support EHR-to-Direct patient record requests and allow stand-alone PHR systems like HealthVault to handle the user interface. Of course, for an arrangement like this to work, HealthVault will need to become certified as a provider of these patient-facing features. Eventually, communication with nontethered PHR systems over a health information network of some kind will likely be required as well. Others, such as psychiatric hospitals, which are especially concerned with privacy, will simply provide copies of electronic files to a patient face-to-face.
Some aspects of meaningful use are focused on providing patient education using automated systems. For instance, patients should be automatically referred to online patient education in the language of their choice. As a result, PHR systems will likely become lightweight content management systems, automating the delivery of targeted health content.
Eventually, meaningful use will begin to require EHR systems to accept uploads. Patient-generated data will likely first be manually or automatically uploaded into a PHR system, and then accepted into the EHR system. Of course, this is a further mandate for communication infrastructures like Direct and IHE. Indivo-style PHR platforms are already working on accepting and managing patient-generated data, but the PHRs that come tethered with EHR systems will likely have minimal capacity to accept it. Patient-generated data is at best vaguely defined. Communities like the quantters and e-patients will very likely prove the crucial value of very new and different forms of patient-generated data at a far faster pace than standards bodies will sort out how EHR systems should treat such data. Still, even with a lag, accepting patient-generated data even for simple record correction or commentary will be a huge technical step forward.
[6] The e stands for “empowered” as well as “electronic.”
[7] Accuracy and Self Correction of Information Received from an Internet Breast Cancer List: Content Analysis
[8] Wikipedia’s health information has also been found to be high quality.
[9] “Privacy concerns may take back seat” by David Burda, March 21, 2011.