ONC’s Direct Project: In Defense of Simplicity

Over the past year or so, I’ve been deeply involved in various Federal gov’t health IT initiatives, including the Direct Project and Query Health. This is first time, I believe, that the public (private sector “outsiders”) has had access to the inner-workings of the Office of the National Coordinator for Health Information Technology (ONC). While I’ve been delighted with this new level of transparency, I’ve been dismayed by the way the process tends to transform simple ideas and sensible goals—aimed at improving care quality and efficiency—into overwhelmingly complex, convoluted and costly technical specifications and requirements!

One of the reasons for situation is that people often “come to the table” with preconceived notions of what is possible and how do it. These narrow/closed mindsets are either unaware or prone to reject  technologies that provide simple inexpensive solutions through the “novel combinations of existing off-the-shelf components, applied cleverly to a small, fledgling value network”) in favor of conventional technologies (commodities) that lack those positive qualities. Following is just one example.

A few months ago, Dr. John Loonsk (CMO of CGI Federal) wrote a widely cited article at this link in which he criticizes the Direct Project’s reliance on SMTP (Simple Mail Transfer Protocol)—the simple method for transporting e-mail messages that’s been widely used since the early 1980s. His criticism is based on the fact that SMTP uses a “store and forward” process in which messages are stored locally (in the user's computer) and then sent to the recipient. He claims that SMTP is insufficient and thus should be augmented by types of Web Services, such as SOAP or RESTful methods, which tend to be considerably more complex than SMTP.

In his critique, Dr. Loonsk takes a “closed inside-the-box” view of SMTP-based e-mail. Following are my responses to his key issues. In contrast to his narrow conventional point of view, my replies take an “open outside-the-box” perspective of SMTP’s capabilities that incorporates a novel publish/subscribe (pub/sub) node-to-node desktop architecture (see this link for technical details).

Issue 1: Dr. Loonsk wrote that “the store part of SMTP…introduces new security concerns even with encrypted data.”

My reply: Since when is the encryption of stored files not enough? These days, it is free and easy to encrypt not only individual files, but even entire hard drives (or partitions) can be protected with bit-locker encryption. With this kind encryption of stored files, along with encryption of e-mail in transit (e.g., using PKI), Protected Health Information (PHI) is protected end-to-end (in transit and at rest), which is about as secure as you can get!

In contrast, the Web Services approach can leave PHI exposed at the web server, e.g., when Web Services provide the in-transit encryption and when they transform the PHI format as it passes between disparate EHRs. With the SMTP pub/sub node-to-node architecture, on the other hand, all encryption and PHI transformations are done by the sender prior to transporting the e-mail.

One more thing about XML security: Encryption vulnerabilities. According to an interesting (and technical) blog post by a cryptographic engineer, encrypting XML securely requires extra steps to prevent a "ciphertext" attack that exposes the encrypted XML content. The author concludes: "If your system is online and doesn't have a solid, well-analyzed protection against them, don't pretend that you're doing anything at all to secure your data. I wish I had a funny, pithy way to sum this all up. But honestly, I'm just a little depressed."

Issue 2: Dr. Loonsk wrote that “Because SMTP store and forward infrastructure can only do the push transaction, it is a limited platform standard and a technical dead-end in trying to address other transaction needs…a true U.S. health system all seem to need more [which does] not stop with the data that one provider anticipates another provider will need…[nor] with the assumption that providers will reliably initiate a store and forward SMTP transaction to move the right data to all that need them.”

My reply: The SMTP pub/sub node-to-node architecture actually enables both “pull” transactions whereby the request for the transmission of information is initiated by the receiver, as well as “push” whereby the request for a given transaction is initiated by the sender. To perform a pull transaction, the party who wants to receive the PHI (1^st party) e-mails a request for it to the party with whom the PHI resides (2^nd party). Upon receipt of the request, the 2^nd party responds by sending the requested PHI to the 1^st party. Either or both parties can do his manually or have it done programmatically (automatically) by the software. This simple solution resolves the SMTP push-pull issue. Nevertheless, as reported by ONC in 2009, push messaging is crucial because it is "...less complex and will be far more readily available to a broader range of providers than so-called 'pull' technologies.

Issue 3: Dr. Loonsk wrote that, unlike Web Services and REST, the SMTP infrastructure does not support HIE functions such as “unanticipated needs, unanticipated providers, reliable data access from unreliable senders, accumulation of data into longitudinal and population records, accessing registries and data for decision support, accumulating quality reporting data, querying to get more data when needed, a raft of directory services, and with team care, the shared management of care plans, problem lists and other data.”

My reply: The SMTP pub/sub node-to-node architecture actually does support these functions and we’ve demonstrated such capabilities with our software tools using SMTP.

Issue 4: Dr. Loonsk wrote that “One argument for SMTP has been that it is more accessible to small providers. In practice, implementations to date have involved more complexity than predicted and…[rely] on an outside organization – a Health Information Service Provider (HISP) to carry the technical load. If a HISP is necessary, a more robust platform standard like Web services or REST would seem to be just as achievable as SMTP.”

My reply: Unlike Web services or REST, the SMTP pub/sub node-to-node architecture I’ve been describing does NOT rely on a HISP since the desktop e-mail client (MS Outlook in our case) carries the technical load, not the HISP. To comply with the Direct Project requirements, however, we use a HISP for PKI certificate management and provider registries, but the actual e-mails pass right through the HISP from senders (publisher) to their recipients (subscribers).

In conclusion, the view of Dr. Loonsk and many others fail to realize how breakthrough innovations, like our novel SMTP architecture and apps, can accomplish what seems impossible to folks focused conventional technology. Though no doubt well-intentioned arguments by intelligent people, their criticisms do not provide good reason for denigrating the simple, sensible, survivable solution SMTP provides.

The Potential of Personal Health Records (PHRs) - Part 2 of 3

In my previous post, I summarized a deep conversation I've been having with a group of knowledgeable people about PHRs. I then offered an innovative, low cost, uncomplicated solution to deal with the concerns others raised.

The solution I offered led to several questions and concerns about (a) security, privacy, access privileges; (b) getting hospitals, clinics, radiology centers, labs and physicians to send an electronic copy of patients personal health information (PHI) to a location where the patient has control over it; and (c) having the PHI be portable, accurate and complete. I answer these questions and address the concerns in this post.

First, here's a basic diagram of the architecture I proposed (a prototype of which we have demonstrated):

* Database Management Systems are software programs that manage databases. In healthcare, these databases are used by EMRs and EHRs and other health IT systems.

** In addition to providing send (publisher) & receive (subscriber), encryption & decryption, and authentication/authorization functionality, each pub/sub node connects with automated data processing templates for querying any databases, parsing any files, manually inputting data, transforming & translating the data, and presenting (rendering) the data.

*** Each data file (DF) is encrypted end-to-end (at rest and in transport) and can be in any data format (CSV, XML, XLS, HTML, etc.). They are stored locally, can be (a) composited (combined/integrated) when multiple publishing nodes send DFs to the same subscribing node, and (b) decomposited (broken apart) when a pub node is authorized to send only a subset of the DF's contents to a particular sub node.
Now to the technical concerns mentioned…

Security: End-to-end encryption of the DFs (including PKI methods). It is also possible to store the personal identifiers in a different DF (which could even be stored at a different location).

Privacy: "Granular level" data control by patient through PHR (see this link).

Access privileges (confidentiality): The human owner of a node can access and render a DF only with user name and password (or, preferably, with a biometric indicator). And the DFs contain only the PHI for which the person is authorized.

Sending an electronic copy of PHI from multiple sources/repositories to a location that the patient controls: Each publisher (provider, lab, etc.) node can do this by (a) querying a database to which it has rights, (b) storing the query results in DF with the transformations and translations required by each of its sub (i.e., patient) nodes, and (c) transmitting the DF to the sub nodes as an encrypted e-mail attachment (or other methods).

Portability: The node software and data processing templates are all modular object oriented applications, and the DFs are individual electronic files, so everything is very portable.

Accuracy and completeness (data integrity): Examples include data validation routines (assessing whether each data element is within predefined parameters), cross-checking data values from different sources, and identifying missing values.

Availability: Since the DFs and processing templates are stored locally on different computerized and storage devices, and since the DFs can be updated automatically via low-bandwidth and briefly connected means (such as e-mail), a recent version of PHI is available anywhere/anytime.

I do not claim to have all the answers, but do come to the table with 30 years of knowledge and R&D. We are seeking to expand our network of collaborators and are very open to creative ideas. Anyone interested in joining our team are welcome to join my company's LinkeIn group—Crafting the Future of Health IT with Novel Solutions—at this link (requires registration).

Other questions were also raised, including: (1) How best to share PHI among disparate systems; (2) How to increase PHR adoption; and (3) What makes a PHR truly useful to the patient and his/her providers in terms of improving care, self-maintenance, quality of life and, of course, controlling one's PHI to maximize privacy. In addition, I was asked if I ever considered Open Source and if we've tried to connect with the big online PHRs. Following were my replies.

Open Source. We have dipped a toe into the open source "waters," but got "stepped on" by the FOSS folks who claim that there is no such thing as a truly valid software patent, and that all software patent holders are greedy, manipulative frauds. After months of debate trying to seek an amicable solution, I left with a bad taste in my mouth (see this link). Nevertheless, I believe open source has a place—especially with commoditized (non-novel) programs—and we have offered an OS app at this link for converting XML to CSV.

Connectivity. MS HealthVault, Google Health and (I believe) Dossia are all public cloud PHRs. With all the security concerns over public cloud computing (see this link), we are shying away from them. We've made attempts, however, to get MS and Google interested in our novel node-to-node system (issue #1 above), but to no avail.

We have not yet written the interfaces you mentioned (also issue #1), although we have interfaces to legacy (X12) and relational databases, as well as XML and other document parsing routines. And although querying remote/external databases is the one method, we've found that having the DBMS run a query and generate an output stored in a CSV (or other delimited text file) is a simple alternative.

Adoption drivers/impediments. I agree that the lack of financial benefit to the database owners has been an impediment to PHR adoption (issue #2), and our crazy provider reimbursement model (pay for quantity, not for value) makes matters worse. It is one reason that we're currently focusing on using our technology in an application that supports information exchange of referral data between PCPs and specialists in patient-centered medical homes while (b) continuing to field test and enhance our PHR application in preparation of its commercialization through workplace wellness programs and other venues.

For the first time in my 30 years as a provider and software inventor/developer, the need to control costs and improve quality is becoming more widely recognized, in part because of the recent healthcare reform debates and the number of people suffering inadequate care. They say that true (disruptive/discontinuous) innovation—one that saves money, reduces complication, and improves overall value—is more likely to be accepted when an economy is in trouble. So, maybe the time is finally right!

PHR usefulness. As far as what makes a PHR useful (issue #3), I would say it's the ability to help the patient & providers (a) increase/improve knowledge and awareness of the patient's health risks and problems, (b) make valid decisions about how to deal with the patient's particular health risks/problems in the most cost effective ways, and (c) become increasingly competence (through education) in implementing the appropriate steps to avoid the risks from becoming problems and ameliorate the severity of existing health problems for a better quality of life. This should include a focus on biomedical & genetic, psychological/psychosocial, and environmental factors. And it should avoid information overload (see this link), while providing complete and accurate data.

[Come back later for part 3]

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

A thought-provoking conversation on LinkedIn (see this link) 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 most (though not all) commenters replied NO, the discussion covered some very interesting topics about data ownership, storage, privacy, and exchange. Following are excerpts.
I replied to the original question this way:

I contend that ONLY group of people who should be allowed to OWN a patient's (consumer's) identifiable health data is the patient him/herself. The patient may allow other people (i.e., "Trusted Partners") to have access to certain data and to store it securely in centralized databases behind a firewall and/or in distributed encrypted data files stored locally. And when it comes to de-identified data for research purposes, I suggest that those data be available to anyone (e.g., under government control).

The best model for data exchange between the Trusted Partners (TPs) and between the patient and the TPs, imo, is a P2P pub/sub mesh node network resembling telephone networks.

Several others concurred with me about patient ownership and added comments such as:

…interoperability and access to longitudinal patient health data across physicians and time is a burden on bandwidth and very costly…the ownership of data will ultimately be the patient but the help of the government in providing a non-for-profit repository where the data sits and is maintained is a must. France is a good example of how this is possible…The best architecture for a national Health Information Exchange will be technology agnostic infrastructure, where EHRs are easily aggregated from multiple data sources simultaneously upon request by an authorized healthcare organization…All seem to agree that "networks of networks" model is a bit cumbersome and that patients should own the data…While I agree that the patient is the ultimate owner of the data, I do not agree that they should be the data aggregator - which means that patients should not be held accountable or responsible for the collection, entry and management of all their health information.

Another commenter I suggest this scenario:

Patient data "lives" in an encrypted "cloud", identified using a Universal Healthcare Identifier as is being developed by Global Patient Identifier, Inc. In order to render the data useless to hackers & thieves; financial & social security data is NOT stored with it.

EHR standards similar to ASC X12 HIPAA transactions, such that an entity (i.e. Provider) can request the Patient data vie a standard internet web-part that is populated based on selected parameters such as: all data, data for a specified time period, specified type of data (Radiology only, Lab results only) - or a combination of these parameters. In this way - data is available anywhere on the globe it may be needed.

We'll still need to devise a way for the Patient to grant access. Also, we'll have to think about controlling the data which was requested and locally populated. Can it then be stored locally / should it be erased? Perhaps this is managed via the TYPE of access the Patient grants to the requesting entity.

To which I replied:

…I suggest that any database in a public cloud should only contain de-identified data from multiple sources for research (aggregate analyses); the cloud could also store back-ups of encrypted data files for each patient with the originals residing on each end user's (clinician's, patient's, organization's) computer hard drive (or network server). These data files would contain patient records made up of data fed from locally stored sources (e.g., EHRs, PHRs, CPOEs), manual inputs, medical device data streams, and so on. A P2P, pub/sub, node network cyber-infrastructure would enable authorized nodes/users to conveniently exchange of data sets from patients' data files; to minimize cost and complexity, the files can be exchanged via encrypted e-mail attachments. I'll be offering more details on this novel health data exchange model over the next couple of weeks. See this link.

Note that patient control is enabled by decompositing a locally stored data file based on rules reflecting a patient's privacy wishes, so that only the portions authorized by the patient are exchanged. See this link.

Another commenter then wrote:

Consider the information related to a patient to be an "object" in a massive data warehouse. Different data attributes associated with this object are (at least today) "owned" by different people/organizations. For example, some of the provider data is and should be "owned" by the provider and not available to other providers, payers, or patients. I see this as one of today's key perceived barriers to physician/practitioner acceptance of the NHIN model.

Conceptually this design is possible, but a challenge remains with the "physical owner" of the data warehouse, its database and application design characteristics, and its security administration. Ultimately, in any Information System, someone needs to be the "master administrator". Furthermore, the patient does have ownership over who may be authorized to "tag onto" their patient-object (i.e., who have they authorized to provide them care).

One suggestion may be to encrypt the content-data so that the "master administrator" can set the security for various attributes (between provider, patient, payer, government, or other users) without having the ability to access the content. This service can be designed so that the patient may designate these roles, but only for their own patient-object.

I propose that the HIO [health information organization] provide for physical ownership at a "relatively" local level (by metropolitan area or rural region), using cloud computing principles that are updated to incorporate HITECH and related concerns. There needs to be a common interface between these HIO's in order to achieve the NHIN.

To which I replied:

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.

And please confirm that I understand your proposal: Patient data can be considered an "object" with attribute tags defining those authorized to access data from that object. And you say the object would be stored in a massive data warehouse, but there are problems with determining who should physically own the warehouse database be the "master administrator," as well as the failure for the patient to control who is authorized to add tags to a patient-object. The suggestion is to encrypt the content while allow the master admin to set those authorization tags in accord with the patient's wishes. Using cloud computing principles to support ownership by regional centers and a common interface between them would enable a NHIN.

Assuming my understanding is correct, then what about the following data ownership and exchange model: I agree that patient data ought to be managed as an object. I content that the object ought to be a data file, preferably an encrypted delimited text file (such as comma separated value format) to minimize size and overhead. There would likely be multiple data file objects for each patient, which are stored very locally depending on who entered/collected the data (e.g., on a patient's or clinician's computer, smart phone, memory stick/card, or on a health organization's server, etc.).

For everyday transactions (e.g., when a primary care physician exchanges patient data with the specialists to whom they refer, or when a patient and clinician share data between a PHR and EHR) a desktop or network-based software program would automatically decomposite (break apart) the local data file, extract the authorized data, and ship that data set via an encrypted e-mail attachment using PKI to assure the correct recipient gets it. The recipient can then view those data in a personalized, template-based report A decentralized node-to-node, pub/sub mesh network could do this exceptionally cost-effectively and with minimal complexity, in addition to increasing security and privacy since the nodes' actions are guided by a rules base requiring no human intervention.

Continuing with my proposed model, the NHIN data warehouse would be fed by the same software program in the same manner, with each NHIN server being connected to a node in the network, and with e-mail being the "common interface." When invoking its subscriber function, the NHIN node(s) would automatically retrieve data files sent to it and import those data into its database(s). These files would contain a standardized minimal data set (MDS) based on the CCD/CCR, whereas the data exchanged between healthcare providers, and between patients and providers, would include but not be limited to the MDS. When invoking its publisher function, the NHIN node(s) would send the appropriate data to the appropriate subscriber (provider or researcher) nodes, which may include immunization and disease registry data, biosurveillance data, and de-identified data form cost & quality research. The NHIN would also enable any authorized clinician to access certain patient data residing beyond the confines of the regional data centers. By using these unmanned nodes for carrying out the data exchange processes, the issues of security and privacy are increased, as mentioned above, and the problems associated with a master administrator are eliminated.

The conversation is continued at this link.

Related posts:

• Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 2 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

Personal Health Information Privacy

Not surprisingly, during the recent National Discussion on Health Information Technology and Privacy held on the web, the issue of privacy was at the forefront. The issue of mental health information privacy was of the utmost concern. I discuss the privacy debate in this post, and offer an innovative solution.

Who Should Own One's Personal Health Information?

A knowledgeable participant at the online conference, Laura Groshong, LICSW, Director, Government Relations, Clinical Social Work Association, offered these wise words:

…I don't think patients want to be the 'owner' of all this data, responsible for sending it to the parties who need it and determining who these are. This is part of the flaw in thinking that patients should become the owner, and discloser, of all their medical information.

When it comes to mental health information, there are special problems. HIPAA has an exception about information being shared with patients if the clinician thinks it might cause harm. This is a significant concern for mental health clinicians when the patient is not ready to hear the specifics of how the clinician has diagnosed them. Patients may be aware that they feel understood by the clinician without knowing the way the clinician understands their problems for quite awhile.

Another concern I have about making the patient the owner of his/her records is how this will be implemented by people who may be homeless, incarcerated, unable to understand the disclosure process, or otherwise off the grid of being able to keep track of their own information.

I agree with her comment. It would be foolish for a consumer to dictate whether or not their primary care doctor or medical specialist should be allowed to view their lab results, imaging studies, etc. since it may be a life threatening decision for which consumers are ill-prepared to make. However, they should have control over whether their employers (or others) get to see this type of health information.

I also agree that mental health information is a special case.

For one thing, most mental health information is not life threatening, except, perhaps, suicidal and homicidal ideation/tendencies. When providers have knowledge that such dangerous behavior is likely, they are required to report to authorities (along with and sex and physical abuse). Consumer/patient consent is not needed.

In any case, I believe consumers should have full ownership/control over whom, if anyone, gets to see any other consumer-generated mental health information. This include information about their cognitions (thoughts, beliefs, perceptions), emotions, behavioral tendencies, psychosocial history, interpersonal relationships, etc. it.

And if some people do not have the capacity to make determinations about sharing their health information, a health proxy (or other "trusted partner") could assist them.

Please realize that I'm not talking about giving mental health consumers access to and control over their providers' session notes, or even giving specific individuals their mental health diagnoses or professional observations prematurely if it is clear such knowledge would cause irreparable harm to the treatment/recovery process. What I am referring to is the information contained in one's personal health record or personal health profile.

So, to me, it's not about having consumers track and control all their health information by disallowing their healthcare providers from accessing essential information needed to make life-saving and wellness decisions. Instead, it's about having control over who gets to see one's mental health information, and who, other than the physician(s) involved in one's care, is authorized to view one's biomedical and genetic information.

Next, I'm going to share some thoughts about the kinds of information that should and shouldn't be under a consumer's direct control. I'll also discuss what to do about it.

Types of Personal Health Information

As I mentioned above, there are some types of personal health information (PHI) that should not be under the direct control of the consumer, at least not without a warning. And even if consumers have some control over that information, it makes little sense to force them to approve each and every piece of data that is shared with their healthcare providers. Other types of PHI, however, should be under a consumer's complete control…every piece, piece by piece.

Determining PHI control in a logical manner requires dividing the information into different categories by classifying them according to some taxonomy. These PHI categories are comprised of "data sets," i.e., groups of related data. Rules can then be applied to these data sets, which dictate the way each particular piece of data in that category is controlled.

I will now offer a possible classification scheme, which divides all PHI into these seven categories, each of which contain one for more data sets:

1. Personal Identifiers
2. Personal Demographics
3. Emergency Medical and End-of-Life Information
4. Biomedical Health PHI and Genetic Information
5. Mental Health PHI
6. PHI regarding Physical Activity, Exercise, Nutrition, Energy Levels
7. PHI for Research Purposes.

I will also suggest who should, and should not, have access to that information.

1. Personal Identifiers

Personal identifiers include a person's:

• Name
• Address
• Insurance and patient ID numbers
• Other information that can be used to identify the person to whom the PHI refers.

It is important for professionals providing healthcare to a patient, as well as those paying for a patient's care. It should not be made available to others, however, unless the consumer consents or HIPAA rules demand it. For research purposes, a people's PHI should be de-identified to protect their privacy by removing this data set.

2. Personal Demographics

A person's demographics refer to information that places the individual in a specific group based on such data as:

• Age
• Gender
• Race
• Religion
• Family size
• Level of education
• Occupation
• Income
• Zip code.

Some of these data may be useful in making medical treatment decisions, including one's age, gender, and possibly race. And others may be useful in mental health care. Nevertheless, demographic data are essential for most clinical research.

3. Emergency Medical and End-of-Life Care Information

Emergency medical and end-of-life care information includes such data as:

• Blood type
• Allergies
• Past and current medical conditions
• Current medications and dosages
• Emergency contact information (family and physicians)
• Advanced directives (include living wills and durable powers of attorney).

Any authorized provider delivering care to a person in an emergency ought to have access to this information, even if the person is unable to consent at the time. See this HIPAA flowchart for more.

4. Biomedical Health PHI and Genetic Information

Biomedical health and genetic PHI includes health history, current health status, health risk information, as well as genetic information. This category contains biomedical and psychological data about a person's:

• Existing symptoms
• Current and past health conditions/problems
• Current and past exams and interventions/treatments
• Risks posing a threat on one's future health status
• Biometrics (e.g., weight, blood pressure, cholesterol levels, vital signs, etc.)
• Imaging studies (e.g., x-rays, CT scans, MRIs, ultrasound, etc.)
• Genetic makeup (of self and family).

Much of this information would be useful for most physicians treating a patient, as well as one's wellness coaches/counselors and others involved with a consumer's physical wellbeing. A one-time consent that authorizes the sharing of such information among one's physicians is justified, as well as allowing a person to authorize other types of practitioners to access specific data in this category.

Note that people with health problems or risks are unlikely to want their employers or health plans (insurers) to have access to this PHI as it may be used to make employment and insurance decisions that are not in their best interests. This issue is complex and includes debates over whether genetic data should be considered private or proprietary, as well as causing various ethical dilemmas.

Another issue is whether any of this PHI should be sent to public health agencies if there is reason to believe that a person has a seriously contagious illness, or if there are multiple people in a region with a health problem that indicates a possible outbreak (pandemic, epidemic, or terrorist attack). This issue is addressed by the HIPAA Privacy Rule and Public Health.

5. Mental Health PHI

Mental health PHI includes all psychological, psychiatric, and psychosocial information. This broad category encompasses information about one's perceptual, emotional, cognitive, behavioral, and social life. It includes a huge diversity of information, such as:

• Excesses of emotion, mood, affect including anger toward others/resentment, anger toward oneself, depression, anxiety, guilt, shame/embarrassment, jealousy/envy, pessimistic about the future, manic periods/emotional excitability, low frustration tolerance, easily irritated/annoyed, impatient, lack of adequate temper control
• Deficits of emotions, mood, affect including lack of pleasure/enjoyment, feelings of boredom/emptiness, flat or grossly inappropriate affect, unawareness of one's emotions, apathy, lack of empathy, remorse, tender emotions, and cool indifference
• Instability of emotions, mood, affect including bipolar symptoms
• Excesses of activity, drive, impulse, behavior including compulsions and restlessness, psychomotor agitation or tension, hyperactivity and poor impulse/urge control, reckless behavior, failure to adequately consider the consequences to one's actions, poor or lack of planning & decision-making, indecisiveness, kleptomania, pathological gambling, pyromania, trichotillomania, compulsive sexual activity, compulsive spending, workaholism
• Deficits of activity, drive, impulse, behavior including poor work effort/motivation, loss of initiative, disinterest, poor planning, failure to persist on task, procrastination, difficulty making decisions, passive-aggressive behavior, irresponsible behavior, psychomotor retardation, lethargy, lack of activities of daily living (ADL) skills
• Eating problems including excessive eating (overeating), poor appetite, excessive dieting or fasting, vomiting or use of laxatives, binging and purging, body weight
• Sleep problems
• Sexual problems and issues including sexual abuse; general information; violent sexual thoughts and fantasizes; sexual dysfunctions
• Physiological symptoms related to one's physiology including gastrointestinal problems, autonomic nervous system symptoms, motor tension and overactivity, cardiopulminary symptoms, motor lethargy, numbness, tingling sensations, paralysis, sexual problems, and more
• Psychosocial stressors and interpersonal problems including family strife, problems with work or school, problems with one's living situation or working environment, legal problems, financial problems, etc.
• Psychoactive substance use including caffeine, nicotine, alcohol, and illicit drugs
• Maladaptive cognitive styles on mental symptoms/dysfunctions including ultra-conservatism (avoids constructive risk-taking), pessimism, helplessness, hopelessness, lack of self-efficacy, perfectionism, inflexibility, dogmatic style, preoccupation with organization/order, paranoid ideation (non-delusional), lack of trust, suspiciousness
• Primary dysfunctional cognitive schemas including irrational beliefs, negative self-concept and global self-appraisals, non-delusional inflated appraisals of self such as narcissism, self-centeredness, grandiosity, attention/approval-seeking; manipulative behavior; exhibitionism; negative global appraisals of others/prejudice
• Secondary dysfunctional cognitive schemas including low self-efficacy; pessimistic future expectations; sense of wrongness, unfairness, entitlement/deservingness; causal attributions (responsibility)
• Coping styles
• Maladaptive levels of alertness, attention, concentration, vigilance, concentration (vigilance deficits and attentional excesses)
• Identity problems and confusion including multiple personality symptoms, depersonalization and derealization symptoms, gender-identity problems
• Post-traumatic stress disorder
• Disturbances of consciousness and orientation
• Memory problems and amnesia including psychogenic fugue, immediate and short-term memory impairment, recent and remote memory impairment, paramnesia, general memory impairment information
• Abstract thinking, intelligence, dementia, pseudodementia
• Problems with insight and judgment
• Executive functioning impairment and non-verbal communication learning disabilities (including dyslexia, dyscalculia, dysgraphia, directionality difficulty)
• Disorders of receptive or expressive communication
• Disturbances of thought process and form
• Hallucinations and illusions
• Perceptual agnosias
• Conversion disturbances
• Delusions
• Obsessions
• Peculiar, odd, eccentric behavior or appearance
• Overconcern with body shape or size
• Grossly defective/disorganized behavior
• Self-directed violence/aggression including suicidal and self-mutilation behavior
• Other-directed violence/aggression and anti-social behaviors including violent and non-violent conduct problems
• Interpersonal rejection, avoidance, abandonment, social withdrawal, social anxiety, under socialization, interpersonal indifference, shyness, dependency, passivity, loneliness, insecurity, passivity/unassertiveness, proneness to peer-pressure, pattern of unstable/poor relationships
• Defense mechanisms employed including mature defenses, neurotic defenses, immature defenses, and narcissistic defenses
• Early (childhood) psycho-social experiences
• Factitious disorders.

Is it worth computerizing such mental health information? I say YES it is because failure to digitize and share such PHI:

• Prevents the mental health field from developing its potential (e.g., by not allowing de-identified data "from the field" to be used to the study and improve treatment effectiveness)
• May increase risk (e.g., makes it difficult to do an assessment of medication side effects, especially if multiple medications are taken)
• Keeps a wealth of consumer-generated information from being used for treatment planning and delivery
• Prevents consumers from taking advantage of a new generation of computerized self-help tools that increase self-understanding, and offer help with coping and problem solving
• Makes it nearly impossible to deliver care through a "whole-person" (mind & body) approach.

At the same time, failure to protect a person's psychological information is destructive and simply unacceptable, whether it is in electronic or paper form.

So, who should be authorized to access a consumer's mental health PHI? Well, it depends on what the particular information is in this category.

It is no surprise that mental health practitioners would benefit from having access to the vast majority of this information since it is helpful with treatment planning and delivery. They would also benefit from combining this information with the certain biomedical and genetic information (e.g., to determine if medication side-effects or medical illnesses are presenting as or exacerbating one's physiological symptoms, to understand if psychological stress or emotional distress are adversely affecting one's physiology, etc.).

Integrating some of this mental health information with their patients' biomedical information would also benefit non-psychiatric physicians and other non-mental health providers by helping them understand their patients' health status and needs in an integrated whole-person manner that encompasses both the mind and body. This comprehensive information would, for example, help these professionals:

• Determine if there are adverse side effects of medications taken, which present as psychological symptoms
• Gain insights into their patients' motivation and ability to self-manage acute and chronic conditions
• Be aware when psychological problems are adversely affecting their patients' physical health; for example:
• There is a strong connection between optimism, coping skills, and physical health. Researchers found that depression is a precursor to heart disease, with certain depressed patients being 50 percent more likely to develop or die from heart disease than those without such symptoms, even though they had no prior history of heart disease. Depression, therefore, likely affects not only the mind but also physical health by being linked to increased blood pressure and abnormal heart rhythms, as well as chronically elevated stress hormone levels, which can increase the heart's workload.
• Disturbances of physiology that are related in some way to situational/psychological conditions, but without actual permanent end-organ damage, include migraines, functional bowel disease and types of chronic pain. And disturbances where actual physiological and psychological pathologies are evident include hypertension, peptic-ulcer disease, hyperthyroidism, asthma and chronic skin disorders.
• As many as 25 percent of all outpatient visits can be accounted for by psychological factors that cause physiological disturbance with no permanent organ damage (as in migraines, functional bowel disease, and types of chronic pain). That's the narrow definition of psychosomatic illness. The percentage rises to around 50 percent of all ambulatory care if the definition is expanded to include conditions where actual physiological changes occur (such as in hypertension, hyperthyroidism, asthma, and chronic skin disorders). The percentage rises even higher when the definition of psychosomatic is widened to include serious physiological disorders, such as autoimmune disturbances that tend to appear or flare up with significant life changes and stress.
• Knowing when psychological problems are adversely affecting a patient's physical health helps a provider determine when to make a referral to a mental health professional. This is important because:
• Psychological interventions are becoming a necessary component of treatment, or even the treatment of choice, for many psychophysiological (mind-body) disorders. When mental healthcare specialists render treatment for psychological disorders, such as depression, patients realize better outcomes for lower cost compared to treatment delivered in general medical practice.
• Research demonstrates that behavioral healthcare enhances physical health, raises the body's ability to recover from illness and surgery, and prevents biological illness by helping to alleviate stress, promote physically healthy lifestyles, and strengthen the immune system.
• There is a wealth of research demonstrating how the treatment of psychological and behavioral aspects of illness decrease medical utilization and costs, which can more than offset the cost of providing the behavioral interventions, resulting in total cost savings. An example of this "medical cost offset effect" is research that found attending to the psychological needs of patients diagnosed with somatization disorder reduces the annual cost of their medical care by almost one-third.

Now to the question: Who should control a consumer's mental health information? I assert that it should be the consumer him/herself, and the information should be controlled at a granular level of detail. That is, the consumer should determine who is authorized to view each piece of data, andeveryone else should be blocked from seeing it.

6. PHI regarding Physical Activity, Exercise, Nutrition, Energy Levels

PHI regarding one's level of physical activity, degree of exercise, nutrition, and energy drains and boosters would be useful to all healthcare providers, and at would be key information for wellness coaches/counselors.

7. PHI for Research Purposes

All the PHI data sets above would be useful for different types of clinical research. Since personal identifiers are not necessary for this type of aggregate analysis, the data should be de-identified before being sent for research. If the person's identity is guaranteed protected, I don't see an urgent need for authorization, although it will likely be required. I'd even go so far as to recommend that consumers and their healthcare providers be paid by those using their PHI for research, even when the information is de-identified. I say this because such payments may promote greater use of electronic health record systems in general, as well as support research efforts.

How Consumers can Control their PHI

There are at least two mechanisms by which consumers can control their digitized PHI: Use of limited data sets and granular authorization controls.

Limited Data Set Control

One method is to predefine "limited data sets" in which only a particular sub-sets of PHI in the categories discussed above shared with particular types of authorized persons. In some cases a consumer would have to consent only one time to authorize particular healthcare professionals to access and share their PHI. In other cases, no consumer consent may be required (e.g., for the protection of public health). And in still others, consent may be required every time.

These data sets may include information from one or multiple PHI categories. Note that there may be times to allow a consumer to override a limited data set in order to restrict access to particular pieces of data.
To make all this happen, a health information technology tool must automatically manage a variety of rules that define the data sets, authorize the appropriate recipients, and give a consumer the ability to override the rules when appropriate.

Granular Authorization Control

Granular authorization control means giving a consumer the ability to authorize access to certain types of healthcare professionals, and prevent access from others, for each and every piece of data in the various PHI categories. This may include overriding certain limited data sets, as well as having complete control of all other data sets.

For convenience sake, the consumer should be able to authorization each piece one time, and then be able to update the authorizations whenever desired. In addition, if a consumer fails to authorize certain providers of specific information they need to do their jobs effectively, or if s/he removes the prior authorization of those professionals, a warning should appear informing the consumer that this action is unwise. Likewise, if the consumer (mistakenly) authorizes certain provides to access certain sensitive data they do not need, another alert should appear letting him/her know what is being done.

Combined Control in Personal Health Records/Profiles

When it comes to personal health records (PHRs), there ought to be combined controls. That is, a consumer ought to be able to implement a one-time authorization of limited data sets for certain PHI, as well as authorizing the rest of their PHI via granular control, and be guided by the warnings and alerts as describe above. This means the consumer needs a clear-cut way to recognize the authorization status of each piece of data in every PHI category, and to be instructed along the way.

I know of no PHR that has these capabilities. However, the personal health profile we've developed already does it! See this link for more.