This post is a follow-up to a prior post at this link. It is a thought-provoking conversation that examines whether the patient data stored in the national health information network (NHIN) will, within the next five years, likely be "owned" by major firms such as Oracle, Google, and Microsoft.
While a patient ought to "own" all their health data, it doesn't mean that such ownership is the same as having actual physical possession of them all. After all, each healthcare provider (from an individual clinician to hospitals to large health system such as Kaiser and Geisinger) has physical possession of the data that they collect. It's UNREASONABLE to expect that all those data (including images) be shipped to the patient for local storage and to ask the patient to release those data each time a provider needs them. Instead, the data should be stored where it is collected.
There is one exception, however: the PHR. All PHR data should always be stored with (i.e., physically possessed by) the patient (preferably, imo, in an encrypted data file), even if collecting data through the PHR is done via a kiosk in a doctor's office or through a provider's web site. Furthermore, all EMR/EHR data (with some possible exceptions, such as a psychotherapist's notes) should be sent automatically to the patient's PHR; and the PHR should have the means to help the patient understand what those clinical data mean.
To deal with the privacy issue, the PHR should possess functionality that enables a patient to identify the particular data able to be shared with particular types of providers. In addition, patients' PHRs should give them guidance and warnings about who should have access to particular data based on their roles and responsibilities. In that way, any data are stored in a provider's database/warehouse could only be shared with third parties when explicitly authorized by the patient.Another commenter wrote then:
From a health delivery context, there are a number of stakeholders and providers who use patient information and who contribute to it. The patient should be cognizant of who has access to that information and that implies ownership. But to me ownership also means who decides where the information is to come from, what form it should take and the analysis of it etc, all questions related to the skills of the medical practitioner. The family physician is the medical practitioner who oversees and looks after the patient's overall health and as such has access to all information contained in a patient's medical record. It is the role of the GP to make diagnosis and recommend treatment, prescribe medications, monitor patient health, refer treatment to other clinical specialists and give other health related advice etc. It seems to me that the owner of the patient's medical health record is collaboration between the patient and the family physician. The patient has the right to know what is contained in that record but ultimately it is the GP who decides what goes there, and how best to use it.
[That's]…a logical view of ownership of the medical health record. From NHIN or network perspective, there is a physical ownership component. An administrative entity is needed to manage where a medical health record resides, how it will look like, and where it is to be distributed to. Different parts of the health record will be supplied by different providers. Standards need to be applied and privacy concerns need to be satisfied. Time is another element. Access to accurate medical information in a timely manner are the two overarching considerations of the NHIN. Architectural considerations aside, the integrity of the medical health record will largely depend on the degree of subjugation of provider system interfaces to NHIN and medical health record content requirements. What coding schemes are used. What message versions are applied. Are all the provider systems on the same page with regards to content standards. The time element is a factor of bandwidth, network optimization, load balances, etc.I replied:
It sounds like you're describing the Medical Home model, Lowell, in your comment about the GP controlling the flow of patient data. In that scenario, the patient would authorize a "community of referral," i.e., "trusted partner" clinicians to which the GP can refer and exchange patient data. I agree that the patient need not specify which data should be exchanged with a particular specialist every time the GP makes a referral. But the patient should indicate, at least once, which data can be shared with different types of clinicians. This can be done, for example, by having the patient approve (or modify) a recommended data set and let the GP decide the particulars within that set of data.To which he responded:
I assume, the data resides in and is managed by the NHIN but is accessed by the GP, patient and "trusted partner" clinicians in the Medical Home model. The whole idea of the NHIN is that the electronic health record can follow the patient regardless of geographical location. Decisions about the EHR are still made by the GP and patient but the care of the data is entrusted to the NHIN.And I replied:
Good question. I see the NHIN containing minimal data sets as defined by standard CCR/CCDs. This patient data subset includes provider and patient identifying data; contacts and advanced directives; patient's insurance and financial data; and patient health status, which includes codes for diagnoses, problems, and conditions; allergies; medication prescription information; immunizations; vital signs; recent laboratory results; codes/descriptions for procedures and assessments rendered; history of encounters; and care plan recommendations. By contrast, here's a link to what I consider a comprehensive data set, which includes advanced PHR data and addresses the information needs of the multidisciplinary teams comprising a medical home.
Although an NHIN could make certain important data available to clinicians at great distances, the vast majority of communications are between providers within local/regional HIEs (and other communities of referral), not between those at great distances. So, there's no need for the complexities of a monolithic centralized system for everyday data exchange. It's much simpler, convenient and less costly to use a node-to-node pub/sub architecture that relies on desktop/standalone apps and encrypted e-mail attachments. Such a mesh node network model (which resembles the telephone system) makes more sense than forcing all transactions through a central server. The NHIN would be most useful for biosurveillance and for clinical research since it is a centralized data warehouse provides an easy way to aggregate huge numbers of de-identified records from around the country. The NHIN would also be a good way to store backups of patients' encrypted data files. And since an NHIN would not contain comprehensive data sets, connecting pub/sub nodes with local data stores to one another in a decentralized manner is a more efficient and secure way to exchange extensive patient data. This is why I propose a hybrid cyber-architecture in which nodes connected to central data stores, along with nodes connected to local data stores, are the primary vehicles of data exchange.And he then wrote:
Some of the models that I have seen rely on a central backbone for communication and coordination. It follows the SOA pattern and would have nodes connecting to a central highway. It seems that connectivity is a big consideration in being able to collect patient information from a variety of sources and providing front end interfaces for people to access information. Collection might be more onerous in a decentralized model. Implementing a monolithic centralized system certainly has its challenges though. For one, there is a larger burden to get a consensus from all of the stakeholders and to determine the most efficient architecture. I suppose there are disadvantages and advantages to both centralized and decentralized approaches. For example if my home is in New York and I travel to San Francisco and get sick, presumably the hospital in SF would have ready access to my health record in the centralized NHIN. I am not sure how transparent that would be in the more decentralized or node to node implementation. There would be connection issues, knowing who to connect to and login issues etc. But I agree with you there are certainly merits to a hybrid (best of both worlds) approach.To which I replied:
Let me address each of your points of your excellent comment.
You wrote: ""Some of the models that I have seen rely on a central backbone for communication and coordination. It follows the SOA pattern and would have nodes connecting to a central highway."
Yes, this does describe many/most of the current models. I think of a central communication backbone as being the Internet with pub/sub nodes connecting to each other across the central highway by exchanging encrypted e-mail attachments asynchronously. I don't think this has much to do with the typical notion of SOA, however.
You wrote: "It seems that connectivity is a big consideration in being able to collect patient information from a variety of sources and providing front end interfaces for people to access information. Collection might be more onerous in a decentralized model. Implementing a monolithic centralized system certainly has its challenges though."
The front end interfaces I'm proposing are programmable data grid templates used by the node to produce the data files (via a node's publisher function) and consume & present the data files (via a node's subscriber functions). The software programs used by the publishing nodes automatically (a) retrieves data from any necessary data store (local and remote) by whatever means required (SQL, XML or CSV parsing, etc.); (b) performs any necessary data pre-processing (i.e., data transformations and translations, analytics, etc.); (c) packages the resulting data set in an encrypted data file; and (d) attaches the file to an e-mail, addresses the e-mail, puts it to the outbox, and ships it to the appropriate subscribing node(s). Corresponding data grid templates, residing with the subscribing node(s), then consume and render the e-mail attachment. All this using local resources and without the complexities of a big centralized system.
You wrote: "…if my home is in New York and I travel to San Francisco and get sick, presumably the hospital in SF would have ready access to my health record in the centralized NHIN. I am not sure how transparent that would be in the more decentralized or node to node implementation."
This is a valid use case for a centralized NHIN, imo, but there are alternatives. For example, you can carry your encrypted data file (i.e., your entire data file containing a lifetime of health data down to just an emergency data subset) and respective templates on a memory stick or smart card. Another is to have a centralized directory of GP e-mail addresses and patient identifiers whereby your GP's address can be located.He then responded:
Food for thought.
GE Healthcare refers to eHealth as the total healthcare IT infrastructure that connects and adds value to the healthcare delivery system across multiple hospitals or a region, including physicians, care providers, patients, and others.
Focus on partnerships and innovative technologies.
Applying the GE definition to an overall strategy not dependent on any one technology but encompassing a number of value added solutions, a best of breed approach if you will, which could be applied to the design and deployment of an efficient, cost effective and improved healthcare IT infrastructure , is close to what you are advocating, I think Steven. A strategy in which a solution is not locked into anyone particular vendor, which rules out the Oracle, Google and Microsoft monopolies, but matches vendor strengths and functionality to the task at hand.Another commenter then wrote:
MSFT, Google, and Oracle would not want to "own" or be responsible for the safekeeping of the data. I expect the NHIN will end up being a decentralized network. No one will own the NHIN. The US Government will serve an administrative role.And another one wrote:
It's the camera and film argument. Apple's business isn't selling iPods , it sells music you take with you--content. The iPod is simply a facilitator.
Apple sells iPhones, an office you take with you.
I bet dollars to donuts it comes out with a PHR/EHR with specialty apps which doctors and healthcare providers and pharmacies, and payors can access for a fee. Just my guess, but I bet I'm close.I then added:
The GE model is close to what I'm advocating. I didn't notice any mention by GE for the inclusion of decentralized, asynch, P2P, pub/sub, mesh node networks--which I claim are essential for connecting all parties--but they didn't exclude it either.
I envision all vendors of health IT apps providing APIs that connect to the nodes, i.e., PHR/PHA apps would connect to consumer-facing nodes, EHR/EMR would connect to provider-facing nodes, and CDS (clinical decision support) apps would connect to the aforementioned apps. In addition, APIs for research-related analytic apps would connect those apps to nodes accessing the centralized NHIN data warehouse for which the Feds have the administrative role. I think this is consistent with the previous comments.
One more thing, I'm open to any ideas about the best way to collaborate with people like all of you (and GE, etc.) to help realize this global model.Another commenter then wrote:
The system will need to be portable, secure, and inexpensive. While I have a dog in this fight, I feel smart cards are the way things will/should turn out. The systems needs to be architected in a manner in which the data/information follows the patient - the only way to do that is to make it portable, i.e. a smart card (like most of the rest of the world uses). It will need to be secured, using the most modern web-based technolgiiues, such as PKI.
The solution, we feel, is smart cards designed for healthcare.And I replied:
IMO, use of smart cards and memory sticks are certainly part of the solution, and numerous vendors are in this niche. Inclusion of PKI is a good idea. The primary issue, I believe, has to do with determining the best ways to get the data stored in such portable storage devices (as well as in other data stores including DBMSs, XML files and delimited data files) shipped around the country as needed and accessed by any number of diverse third parts software programs. And that issue has to do with factors such as available bandwidth and connectivity, security, privacy, convenience, simplicity, and, of course, cost. I contend that the node-to-node model I'm proposing provides the greatest overall benefits in those terms.
As such, the smart card reader would be connected to a node, in the same way PCs, servers, memory cards, smart phones, etc. have their node connections. The hybrid mesh node architecture, I further contend, would be the most flexible and useful ( see this link ).
Where I (my company) have a vested interest is in having the nodes utilize optimally efficient delimited data files, modular data grids templates, and email (SMTP) transport to minimize resource consumption, expense, hassle, etc.A previous commenter then added:
Many folks including GE, and many of us here are advocating mechanisms to provide an appropriate healthcare IT infrastructure. I am still exploring options. I was involved for three years on a comprehensive project at a cost of millions to build an eHealth system. Personally I was only involved in a small sub part of that project which was the design of a drug system. The eHealth architecture was a centralized model. Cost was a major factor in this project and as I was leaving a re-think and re-planning effort was being carried out to keep the costs down. It seems that flexibility is one of the key words. I think it is terribly important to look at many options and not just be guided by influence from a particular vendor or model . Sometimes involves thinking outside the box. The watchword these days is delivering health care for less money while still maintaining high standards. Technology will play an important role in this process. I believe that smaller incremental steps are needed to achieve success and from what I can see, the solutions being proposed in this forum are advocating that approach.Another commenter wrote:
Not in the near future and I hope never. Too much like Big Brother for me. I want my health data on my computer period.I then added:
I think we should give the patient that option, Elizabeth. I actually feel the same way you do about much of my own health info. Nevertheless, I would want my de-identified info sent to a regional HIE and the NHIN for research purposes (at least a minimal data set). And I would consider storing a backup of my entire health info over my lifetime remotely in the NHIN, but ONLY if it was in an encrypted data file for which only I had authorized access. Then--in case I could not access by local copy of the file (e.g., if it was destroyed, if I didn't have it with me on a smart card or memory stick and my PC was unavailable, or if I was unconscious or otherwise incapciated and the ER docs needed my emergency data)--data sets that I've (previously) authorized could be extracted from that remotely stored file and sent to appropriate providers. I would want this to be done in a node-to-node (n2n) network, so that no human would have direct access to my data file, and I would also want to use biometric indicators as the universal IDs.Another commenter then wrote:
All those involved in the management of a patient, including the patient (if compus mentus) should be able to have variable access to the patient's data. Ideally the patient should have a health manager (typified previously by the "Family General Practitioner) who delegates the relevant access to the necessary data in order to optimize the patients' management. The NHS is trying to achieve this through the National spine, but patients have limited access to this information. The patient needs to take responsibility for his own health care management and thus should hold all the keys in all but emergency situations, and this is where biometrics could be used to review critical data.
My thought is that while the patient should have the option to give the GP authorization to have full and complete control of one's health data without any constraints, such global authorization is not mandatory. If a compus mentus patient refuses to allow certain data to be accessed and/or shared, even though it puts the patient in jeopardy, the patient, with ample warning and education, can still prevent that data from being used; doing so, however, would release the providers from liability and may even increase the patient's liability/cost if lack of that data results in worsening health. I think this is the only adequate way to deal with the privacy issue, even though it opens up other issues.And someone added:
Agreed - once a patient understands the implications of withholding data then the clinician should be absolved of responsibility. Although this seems simple there should also be a method of assessing the "compus mentus status" just to make sure that the patient really understands.Another commenter then wrote:
The NHIN concept will need to involve a lot of technologies to make it work, including patient identification, information access, information sharing, as well as data storage. Concepts including cloud computing, smart cards and/or memory sticks, mesh node networks, and many others will all play into the NHIN in one form or another.
From an historical IT perspective, there has been a long-standing conflict between the "functionally driven" vs. the "data driven" development models. My position is that a data driven infrastructure is, in the long run, more effective, secure, and adaptable. This allows innovation occurring among vendors and regions as well as the changing trends in healthcare services, patient needs, and ultimately the quality of care to be facilitated.
In my "user/patient" perspective, I want to insure that my information from care received while in the military, as well as the information I received as a child (before I even understood the long-term ramifications involved), is available to my current primary care physician and any specialists. I also want to insure that they have information that I have forgotten or may not realize is pertinent to any pending care I am about to receive.
To support this, I believe a decentralized model can be built more affordably. However, care must be made to insure that a cumbersome set of duplicated data is not created. The worst thing that could happen in the NHIN design would be allowing multiple versions of information to exist for a single patient.
Here are a few of my proposed design requirements:
1) Each provider or stakeholder would continue to have a data repository that is built for speed to allow "current care" efficiencies and reliability (the various EHR initiatives in progress today).
2) Regionally, data warehouses would be created using a common standard for the data architecture (but remaining agnostic from a vendor point of view such that in one place it may be a Microsoft solution and in another it could be Oracle, etc.). These would form the Regional HIO's and become the backbone of the HIE. The "primary" data warehouse for each patient should be located in the region where the most frequent access would occur, such as the one associated with their primary care physician.
3) To complete the NHIN concept, various applications would then be developed that would aggregate the appropriate collections of data from multiple data warehouses for the purpose of satisfying their objectives. I would assume these applications would usually exclude any patient-identifiable data. Otherwise, there needs to be a mechanism for patient authorization of access.
4) As patients travel outside of their regions, local clinics and hospitals who need access to information from the data warehouse would use applications to pull pertinent information specifically associated to the patient for the purpose of providing quality of care (this is where a smart card or some other form of secured patient access tool would be needed). Once this link is established, the regional data warehouse would pull any new data from that facility's repository.
5) If a patient makes a permanent move from one region to another, a set of applications would also exist to move (not copy) the data warehouse information from one region to another. When this happens, some form of an alert could be provided to the local systems/data repositories to place their information in an "inactive" status, or re-link it with the new warehouse.
All of the other technologies and applications associated with the Health IT Infrastructure would then be built and designed based on this model. Some may link to a specific repository associated with a single hospital or provider, relying on the link between it and the regional data warehouse for any long-term information; while others may link directly to the appropriate regional data warehouse.And another added:
Can I throw an exception here? We have a significant number of people in the U.S. who are mentally competent legally but who either won't understand that they have control over their healthcare data or how to exercise that control, or who simply can't be bothered with it. That doesn't mean they have made the decision to relinquish control, however. They may be highly mobile, due to circumstances –e.g., unemployment or homelessness -- and may not be computer literate, let alone have a computer. And they wouldn't all be willing to carry USB sticks around. Any health info policies and technical infrastructures need to take these folks into account. For instance, it's not clear that making the patient the primary arbiter of who gets to see his medical data would always work here. Poor judgment on the part of a not-terribly-bright or enfranchised patient could lead to disastrous medical care.
A commenter then added this:
I am a firm believer that the data should follow the patient and that the patient should retain control in an entirely decentralized manner. Centralizing the data in any way in the US is fraught with failure. Even in England, in a one payer system, they cannot get it done and that project is now over budget by billions of pounds.
Security is an entirely separate subject but the reality is that a username and password (Level I in the FIPS model) is not going to work. The system will not work if people do not trust it. So trust and encryption and authentication will be paramount. All this in addition to allowing the patient to contorl access to their data.
In a smart card system, the identities of the patient (regardless of how many institutions they have been treated at) is federated on the card. The card can act as a much stronger security mechanism than anything else being proposed (offering both PKI keys, the obvious two-factor authentication model, and a photo on the card itself!), can offer portability and interoperability, is inexpensive, and is both scalable and sustainable.
Probably why most of the world uses one (but the US).
I have been working in the RHIO world most of my career and have yet to see one that is truly sustainable and scalable in a way that would work for the entire country. The only way I see is a device that can offer interoperability (storing of federated identities and data over time that can be used in disparate facilities), the highest level of affordable security (PKI), and is inexpensive. Smart cards do all of that and are easily scalable.And I chimed in with:
Although we've been having a largely technical discussion to this point, the last two comments reflect the need for sound governance concerning health data at rest and in transit. The point about determining if someone is able, willing and competent to make decisions about controlling the personal data, and if not, what should be done, are examples of areas for which policy and procedure are necessary. Whatever architectural models are used, they must be flexible enough to accommodate policies that may have yet to be established.
I'd like to add to the proposed design the three tier architectural requirements proposed, I believe, by CMS:
(1) RHIO / Regional HIE;
(2) State level HIE; and
This goes beyond the local data stores, of course, and as I understand it, the data to be managed by each of these has to do with the relevancy of the data for certain purposes. For example, level 1 would be focused on data related to the local 'community of referral,' i.e., PCP/GPs exchanging patient data with the specialists to whom they refer, as well as data shared between hospitals and outside clinicians. Level 2 focuses on data required for public health, as well as for people in state facilities (nursing homes, prisons, etc.). And the NHIN would be focused on data for people in federal facilities, as well as nationwide biosurveillance (e.g., for communicative disease) and other things affecting public safety. I believe there's more to it, but I think this is the general concept.
The issue of what particular data sets would be managed by each tier, what data can and cannot be de-identified, the process for feeding data to each tier, exchanging data between the tiers, and issues related to privacy and security, are governance-related decisions. I'm seeking an architecture that would provide the necessary data relevant to the needs of each tier, but in a way that eliminates (or at least minimizes) overlap and (a) avoids storing patient-identifiable data in centralized databases at any of the tiers while (b) transmitting and presenting the necessary data with minimal resource consumption and cost.A commenter then wrote:
Biometrics will obviate the need to carry data storage devises. The argument that unemployed, homeless etc will not have access is debatable as point of provision for medical services will have the relevant access to the database. The big hurdle will be getting historical data on file and in the format necessary to access it. Prospective data can be deposited and rules around access can be initiated immediately. It is important to remember that the Healthcare should be a personal responsibility of every person in the same way as a person should take care to not walk to close to the edge of a cliff. Education around responsible healthcare and the results of ignorance would be cheaper for governments than adopting multiple methods and levels of responsibility taking for patients. Determining a level of "legal competence" to decide if a patient retains or loses their right to determine how their data is distributed is a difficult task and requires developing a robust test which takes into account origin and education of the individual i.e special tests formulated for different races/nationalities/religions etcAnother one wrote:
The points about corpus mentus patients: I am a familiar with a term called breaking the glass. Patients would normally make decisions about their healthcare but when incapacitated there is a policy in place to allow other clinical caregivers to make those decisions.
[The]…comments about governance and security are well taken. It would require some form of legislation to be passed that would enact policies for information privacy. Nobody wants Big Brother watching. Security is probably one of the most overarching concerns affecting the implementation of an NHIN.
From what I am reading, aggregated data which would be used for historical trending analysis and could be retained in a centralized repo whereas current data would be local and accessed only by the family doctor and other clinical specialists pertinent to patient care. There are still issues of portability where a patient's medical information needs to be accessed in locales other than where he resides. Encrypted memory sticks, node to node access etc. are options.And this:
From a security and privacy perspective, the smart card suggestion has a lot of merit to it. The readers and updaters would have to be implemented on a national scale to allow the smart card to be read and updated anytime anywhere. Possibly something accessible through USB would be the most appropriate. With every medical visit the card could be updated with that visit. There could be software running in the provider's office to take information from office records for that patient, aggregate it, and reformat etc to fit with the electronic health record on the smart card. This approach would be simpler and is a medium that folks use and are familiar with. In terms of adding aggregated information to a national repo, providers could download software that would perform the aggregation function. That probably would be voluntary but the information would aid in formulating more effective healthcare policy.
All of this is contingent on medical offices converting from paper records to electronic records, a formidable task.
Also we need an electronic solution for managing drug prescriptions. There would have to be a system for the doctor to electronically transmit a prescription to a pharmacy. This process would eliminate errors in reading doctors handwriting and would enable a way to stop double dipping. It would entail an electronic means for pharmacies and physicians to connect to and transmit prescriptions. Again security and privacy concerns are central issues. From experience, conformance is also a major challenge in getting both clinicians and pharmacists to agree to a standard data format. In the jurisdiction that I reside in there is a province wide pharmacy network called Pharmanet. It is impossible for anyone to go to multiple pharmacies for the same drug.To which a commenter responded:
Your comment below is exactly what our HealthID software solutions does (again, I apologize for the shameless plug). We aggregate the data *using HL7 or SOAP/REST) from the HIS or EMR (something we know a good deal about), make it useable for rules and workflow and CCR, and then have some very capable encryption software to write those data to the cards and federate the identities among trusted orgnaizations. Soon, we will have the VeriSign PKI integration, so entities can be trusted using VeriSign PKI.
Then the prior commenter wrote:
The readers and updaters would have to be implemented on a national scale to allow the smart card to be read and updated anytime anywhere. Possibly something accessible through usb would be the most appropriate. With every medical visit the card could be updated with that visit. There could be software running in the provider's office to take information from office records for that patient, aggregate it, and reformat etc to fit with the electronic health record on the smart card. This approach would be simpler and is a medium that folks use and are familiar with.On another blog, a similar conversation was taking place. In it, someone wrote:
I think everybody can agree that patients have a right to see all their medical data and a right to decide who can see what portions of it and be notified of all disclosures of their medical records. I also think that HIPAA already mandates this. The implementation is of course spotty at best.
My pain point with these new proposals is very simple. It is way too complicated. We are trying to replace a paper system, which today accomplishes all this data sharing by fax or copier and from a patient and doctor perspective it's a very simple process.
I know that many patients have difficulty obtaining copies of their medical records, but that has very little to do with the record being paper or electronic.
Internet banking was adopted because it simplified the tasks. Instead of using calculators and writing checks and licking envelopes and stamps, you just click on a couple of check boxes. And it's optional. I don't have to do online banking if I don't want to. The system is computerized with or without my participation.
Unless, we make Internet healthcare equally simple for both doctors and patients, it will not gain adoption. As simple as that. There has to be a hard, measurable advantage to going electronic, or we will never get enough adoption to make it worthwhile.
One of the main reasons doctors are not jumping on the EHR bandwagon is the inherent complexity and the lack of proven hard ROI to the doctor. I submit that the same will happen with consumers and PHRs.
Some folks will be (are) intrigued, others prodded by the insurer and sign on initially. Most will not and many will drop out.
A small minority will use it and love it. These are the same people that are running into access problems today. The PHR is offering a solution for them, but how many folks like that are there? Enough to satisfy Google's business model? I seriously doubt that.
The PHRs that are discussed here and elsewhere require patients to take control of the data. That means setting up the PHR, coming up with provider lists and entering them in the software with proper authorizations for various levels of access. Keeping these authorization lists current. Managing one's credentials and also family members credentials. Making sure that all is up to date. Changing authorizations to various providers and care givers based on changes in health status and on and on....
This sounds like a lot more work than most people need to do, or are doing, now.
I'm certain that having PHRs is better for patients, just like I am certain that having EHRs is better for doctors. I am equally certain that products that complicate a working system by creating more work for people will not be successful, no matter how cool they are, or how hard they are pushed by well meaning interested parties.To which I replied:
It seems to me that with a little creativity and adequate field testing, PHRs can accomplish all that's required. Although I can't imagine how to deal with the complexity you noted using a purely centralized, monolithic cyber-infrastructure, I can envision how to do it via simple P2P pub/sub node networks.
Let's take the medical home model, for example. Every PCP (GP) establishes a community of referral, i.e., specialists to whom s/he refers patients as needed. The PCP and specialists would establish connections between their decentralized pub/sub nodes, which would enable them to exchange patient data with a few button clicks. The node-based software they use would automatically populate lists of these network connections. By using the e-mail based system I've been presenting, the lists would need little more than each specialist's name, e-mail address, area clinical licensure, and other possible metadata.
Prior to making a referral, the PCP would discuss with the patient why the referral is being made and explain why a particular specialist is being selected, just like things are currently done. Although no authorization by the patient is needed at this point, the patient may request a different specialist for whatever reason. The PCP would then click a button and the referral e-mail is sent.
Once the PCP receives the specialist's referral acceptance e-mail, the data for a CCR or CCD (or some similar data set) would be sent in an encrypted data file via e-mail to the specialists. But prior to sending it, the PCP's node software would determine which data appropriate for that specialist must be excluded from the data file based on the patient's privacy wishes. These data sharing authorizations would have previously come from the patient's PHR by having the patient's node send that information to the PCP's node at an earlier date. The patient would establish the authorizations by, for example, (a) viewing lists showing the types of data that are appropriate for particular types of specialists (and why they are needed) and (b) enabling the patient to modify the list at any time (with appropriate warnings when data elements are deselected). The lists could be organized hierarchically to ease the viewing and selection process. It would even be possible (although I don't know if necessary) to have the data set descriptions e-mailed to the patient for approval prior to routing the data file to the specialist.And she replied:
[I don't really know what is meant by "control". My experience in this industry has been that every time someone wants to give you "control" or "empower" you in some way, the net results are that you pay more and/or work more, usually for someone else's benefit.] I am only suggesting that whatever other considerations may come into play, simplicity and ease of access have to be at the top of the list. That goes for both patients and doctors.