Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 2 of 2)

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.
I wrote:

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...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...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.

...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.

I replied:

It sounds like you're describing the Medical Home model with 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.

...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:

...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.

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.

[Alternative to having everything stored in a centralized NHIN include]...carrying your encrypted 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:

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. http://www.hospitalhealthcare.com/default.asp?title=Highfocusonpartnershipsandinnovativetechnologies&page=article.display&article.id=19448

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.

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.

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 was involved for three years on a comprehensive project at a cost of millions to build an eHealth 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 [be]...thinking outside the box. 

I then wrote:

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 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.

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...Any health info policies and technical infrastructures need to take these folks into account...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...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.

...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.

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 (3) NHIN.

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 big hurdle will be getting historical data on file and in the format necessary to access it....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 etc

Another 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.

...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...Again security and privacy concerns are central issues...conformance is also a major challenge in getting both clinicians and pharmacists to agree to a standard data format.

To which a commenter responded:

Your comment below is exactly what our HealthID software solutions does...We aggregate the data *using HL7 or SOAP/REST) from the HIS or EMR, 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.

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...My pain point with these new proposals is...it is way too complicated...Unless, we make Internet healthcare equally simple for both doctors and patients, it will not gain adoption...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.

...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....

To which I replied:

It seems to me that with a little creativity and adequate field testing, PHRs can accomplish all that's required...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.

Related posts:

• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 1 of 2)
• The push for ‘push’ technology for the NHIN
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 1 of 2)
• Combining Cloud Computing, Client-Server and Novel P2P Pub/Sub Mesh Node Network Architectures (Part 2 of 2)
• A Novel Way for Everyone in the Nation to Exchange Health Data Simply, Inexpensively and Securely
• Simple, Low-Cost, Secure Health Data Exchange
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 1)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 2)
• Health IT: Comparing Cloud Computing and Desktop Applications (Part 3)
• Dueling Data Formats
• Knowledge, Standards and the Healthcare Crisis: Part 6  
• Introducing our disruptive CP Split technology