Archive for May, 2006

Why Your Complete Lifetime Health Record Needs to be Stored in a Single Location

Monday, May 22nd, 2006

There is widespread agreement that having your complete lifetime health record (LHR) immediately available when needed could save your life, improve the quality of your medical care, and save money. Today, most people receive their care from many different specialists and institutions, resulting in records that are scattered among multiple locations. Even if all those scattered records are electronic, no one in the health care “system” has your complete lifetime health record. If you try to keep all the records yourself, as many folks with chronic diseases already do, these will likely be on paper and therefore not easy to use. Furthermore, can you be sure you will always have your records with you in an emergency?

So it’s clear that we all need a way to have our complete LHR available. Efforts are now underway across the country to address this problem. The key question is, “How exactly should we do this?”

Need for Community Focus

Everyone also agrees that these efforts should focus on communities. This is because health care is primarily local — you get the vast majority of your health care in your own community. Even if you get sick or have an accident when you are traveling, you will return home for your care as soon as you can. Therefore, the information needed for your LHR is nearly all in your home community and it will primarily be used there.

So in each community, the issue of how to best do this is being discussed and debated. One thing is very clear — there should to be a secure place where authorized personnel can access your LHR electronically when you need medical care. Where should that place be? And how should it operate?

Where Should Your Lifetime Health Record Be?

  • Alternative 1: Smart Card/USB Drive
  • To be useful, your LHR must be immediately accessible whenever you need medical care. One way of doing this that is often mentioned is for each person to carry their LHR in electronic form (either on a smart card or USB drive). There are at least two problems with this approach: first, the device with your LHR may be lost or damaged. This means that there must be a backup at some other location that is immediately available (which rules out your home PC). If there is a backup immediately available electronically from a secure place, what value is added by the smart card/USB drive? In fact, it is the device you carry that is the backup — and an added cost.

    Second, there is no way to update a smart card/USB drive without it being present. This would be fine if all medical information were generated when you were there, but this is clearly not the case. Results of your lab tests, interpretations of x-rays, and consultation summaries created by your doctors are all examples of information that is produced in your absence. So your physical device would not be up-to-date with the latest information

  • Alternative 2: Secure Internet Portal
  • The other alternative is to have a secure location accessible via the Internet that allows authorized personnel to access your LHR. This is in fact the approach that most communities are pursuing. But there are two different ways to accomplish this: first, you could have a system that only keeps a record of where you’ve received care, but does not store any of your records. When needed, the system electronically requests your actual medical records from each place and puts them all together to create your LHR “on the fly.” I call this the “scattered model.” The second method is to have your complete LHR stored in a central database and ready for use when requested — the central repository.

    The Scattered Model — Gathering Your Records On-the-fly When Needed

    The scattered model has some appealing features. The system does not store your actual medical information — only a list of places where you have medical information. This means that less storage is needed, and that the information stored is not (for the most part) sensitive medical information, but the less worrisome data about which doctors and hospitals you’ve visited. On first glance, this seems to provide more information security, since the same folks that have your medical information now continue to have it. The idea is that your LHR is assembled only when needed from the existing sources.

    However, the scattered model has a number of serious flaws:

  • It does not provide for searching the data, which is needed for public health and medical research
  • It requires additional (expensive) software and hardware for every holder of health care information in the community
  • It is very expensive to operate, requiring substantial technical staff around the clock to assure that all the systems in the community can immediately provide records needed for an LHR
  • It requires real-time connections with every possible source of medical information in the nation (and ultimately the world) to be sure that your LHR will include every possible place where you may have records
  • Its response time is slow
  • 1. No searching of the data

    Although the primary purpose of making your LHR available is to improve your own health care, having electronic LHRs in the community would be invaluable for medical research and public health. Think of the possibilities — early detection of patterns of disease to spot disease outbreaks earlier, finding potential adverse effects of new medications, or pinpointing relationships between treatment alternatives. However, none of these can occur if the data cannot be easily searched — which is not feasible unless it’s stored in one place.

    With the scattered model, any search requires retrieving the “pieces” of each record and then examining the assembled whole. This must be done in sequential fashion — one record at a time — and therefore would be unbelievably slow (to the point of being impractical). The reason computer searches (like Google) are fast is primarily because the data has been “pre-searched” and the results deposited in an index (like the index of a book). When you request a search, the computer then merely goes to the index and finds the results. If you search for the presence of two terms at once, the results that appear in the index for both become the final result returned to you. Without the presence of such indexes, the data would need to be searched sequentially each time you ask a question — and it would take an unbelievably long time to get the results. It’s the computer equivalent of looking up a name in a phone book that’s in random order! Even with the speed of the computer, this is a VERY slow process.

    2. Additional (expensive) software and hardware

    The scattered model requires that every system holding medical information be able to respond immediately to queries. This would need to be done in addition to the routine tasks being addressed by each system. Both software to process the queries and additional hardware to prevent the slowdown of the primary work of the system would therefore be needed. Indeed, for large systems that would be queried often (such as those in hospitals), there would need to be a separate server with a copy of the data to handle the queries. Otherwise, the hospital would find it difficult to guarantee adequate response time for internal access to its own records. This additional hardware and software has a cost — which would be borne by every medical information system in the community. These costs would be especially burdensome to physicians, who already are struggling with the high cost of electronic health record systems for their offices — this is one of the key obstacles to widespread adoption (see Seven Keys to RHIO Success).

    3. Very expensive to operate

    The scattered model requires constant monitoring of all the medical information sources that may be queried. Naturally, those systems that do not respond properly to these periodic test queries would require troubleshooting. Since the number of medical information sources in a community would likely be in the thousands, even a small percentage of non-responding systems would be a significant number (for example, 1% of 3,000 systems would mean 30 problems). There are many possible underlying causes for such query failures which require substantial expertise to diagnose and remedy. To address the problem systems quickly, a substantial staff of senior network engineers would be needed — perhaps 10-15 people. Moreover, these folks would be needed around-the-clock since systems may fail at any time, and must be restored quickly to ensure that patient records being retrieved are always complete. The cost of this operational staff would be substantial — in the range of $10 million/year.

    4. Requires real-time connections to every possible source of medical information

    Every possible source of medical information would need to be connected to be sure that every part of each patient’s record is retrievable when needed. In addition to sources in the local community, any records of care given elsewhere (nationally and even internationally) must be connected. This means that interoperability across the nation (and the world) is a prerequisite to delivering complete records with the scattered model. Even if this were achievable, it clearly could not be done all at once, so patient records would be incomplete as the system was being implemented. Those sources of medical information that were not connected also would not be able to inform the scattered model system that they have information about the community’s patients, so not only would this data be absent from the retrieved patient records, but the fact that information was missing would not be apparent.

    5. Slow response time

    In the scattered model, the response time includes both the query-response cycle to the central index, the secondary query-response cycle to the outside systems holding the patient information, and the aggregation of the secondary responses. The effective response time for the secondary queries is determined by the slowest system that is responding.

    Also, the number of secondary queries is likely to be substantial — at least 20 and probably closer to 100. Here’s why: Assume the average person has three medical encounters/year for a 70-year lifetime (210 total — rounded to 200 for simplicity). A simple estimate of the average number of sources needed for a typical query would be half these encounters (100). Then the number of secondary queries would vary depending on what percentage of these encounters were at places that had previously been visited. A very high average for repeat encounters would be about 80%, which would result 20 secondary queries. A low average would be 0%, resulting in 100 secondary queries. This estimate also assumes that each encounter generates information at only one source — in reality, it is likely to be higher (for example, many encounters include lab results and/or prescriptions) which would further increase the average number of secondary queries.

    The expense and overhead for all these secondary queries is enormous — especially when you consider that they all must be repeated each and every time the patient needs medical care. And it’s very inefficient — once you have a care episode somewhere, their information system would need to be queried every time your records are needed for the remainder of your life!

    Overall, it will be very challenging to assure rapid response time with the scattered model, especially since it is dependent on so many outside systems.

    The Central Repository — Storing Your Records Where They are Immediately Available

    The central repository eliminates the problems created by the scattered model. The data can easily be searched since it is all available in one place. The medical information systems in the community do not need to pay for extra hardware and software to handle thousands of queries, but merely transmit copies of new information to the central repository as it is produced. No complex interfacing to other systems is needed — only a mechanism to receive new medical information reports from other systems (which need not be identified in advance). Whenever you receive care, whether inside or outside the community, all that’s needed to update your LHR is to submit it JUST ONCE to the central repository. From then on, it will always be part of your LHR.

    The central repository is inexpensive to operate and maintain (since there is no complex real-time communications to monitor as with the scattered model), and it can be easily managed since the system is controlled at a single location (with backup elsewhere, of course, for reliability). The response time is rapid — just one query-response cycle — regardless of how many places you have received care.

    Public trust is clearly an issue since there is a natural fear of having all the medical information in a community in one place. However, this can be overcome with a trustworthy architecture. For example, the clinical records can be made available on a special secure server with a “stripped down” operating system that only provides the functions of authenticating the user and retrieving a single (complete) patient record. No searching or indexing capabilities would be present, so only one record at a time could be obtained — thereby limiting potential damage from intrusion. A decoy server with dummy data could also be established and a large prize (e.g. $100,000) offered to anyone who can penetrate the security. This would both reassure the community that the system is secure, and provide an appealing target for hackers who could claim the prize in exchange for exposing a security flaw (which would then be fixed). (Note that the security issues for the clinical record server are no different for the scattered model since it too provides a portal for access to individual records)

    A separate system would be used for searching the data for public health and medical research purposes (with the consent of each patient whose data is being used). It would have no phone lines or network connections, and therefore would be immune to outside electronic access. This research system would be loaded on a daily basis with hand-carried new information written on media by the clinical server. Of course, both the clinical and research servers would need to be housed in a high-security physical environment — such as a bank vault — and guarded just like a large amount of cash.

    One final thought: If gathering personal information on-the-fly was a good idea, why do all of the credit reporting agencies have central databases? Clearly, they each have very sophisticated information technology capabilities, as do the folks like Visa and Mastercard and the banks and merchants that send them data regularly. If it were cheaper/easier/smarter to gather up your information from all the various creditors only when your credit report was needed, why don’t they do it that way? The reason is simple: it is cheaper, simpler, more reliable, and more efficient to store the information in one place so it’s there when needed — just as it is for your lifetime health record. (Note that I am NOT suggesting that your LHR should be handled the same way as the credit bureaus handle your financial information — am just pointing out how they organize the information).

    CONCLUSION

    Although the idea of electronically assembling complete patient records from existing sources only when needed is initially appealing, the approach is unnecessarily complex and expensive, and does not allow the critical function of searching for public health and medical research. This helps explain why the small number of communities that have progressed furthest in the implementation of health information exchanges all store their data in a single location. It is clear that communities wishing to provide lifetime health records at a reasonable cost for their citizens should utilize central repositories.

    Next time: Managing Change in the Context of a Community Health Information Infrastructure