Meaningful Use: Family Health History Form Made Easy | Practice Fusion

One of the new proposed requirements for Stage 2 Meaningful Use is the ability to record patient family history as structured data. This is a menu item – 3 of 5 menu items need to be done, in addition to the proposed 17 core items.

As it turns out, much of the ground work for this has already been done. The Surgeon General has built a web-based tool for collecting family health history. The kinds of information collected by this tool were the result of an NIH State-of-the-Science Conference in 2009, where the literature was reviewed, new investigations were presented, and open discussion took place. A summary of the resulting findings were published here.

The web-based tool that the Surgeon General has published (“My Family Health Portrait Tool”) comes in several versions: English, other languages, and printable. In addition, it is an open source program, so that the source code is available for developers to look into and use.

This tool is geared towards consumers at-large, not just health professionals. People can use the free tool to create their own family health history portrait, and store that information as structured data in an XML file that can be downloaded and saved on one’s own local computer desktop, or can be stored in a PHR.

Inclusion of such a tool into Stage 2 Meaningful Use makes sense, particularly since much of the work has already been done. What it implies is that the standardized format for such data-gathering is already in place, and that the XML file created by the Surgeon General’s web program becomes the standard for the industry. Making inclusion of such capability be a part of Stage 2 means that every EHR developer must embed this capability into their products.

Looking under the covers at the XML file, one sees that the vocabulary used here is SNOMED, which is a much richer language than other coding systems (such as ICD9 or the upcoming ICD10). In fact, other parts of the EHR – in particular Problem Lists – are moving to using SNOMED as the standard vocabulary. Though the result of such a change will be a step forward, it represents some significant work in EHR re-design to accomplish.

A consumer-facing tool
Given that the “My Family Health Portrait Tool” is consumer-facing, the presumption is that every EHR needs to have a patient-facing web portal (a connected PHR), or at least is able to import and export data from a free-standing one if it’s not built into the product. The expectation is that most people will want to fill out their own family health histories themselves – and do so once, in a portable way that can be imported into their physician’s EHR system. The implication, then, is that the family history tool needs to be built into PHRs.

If the family health history tool is not built into the PHR, then the Surgeon General’s web interface can be used (via a link), and the saved History (the XML file) can then be sent to the physician’s EHR. In such a setting, there is an additional technical challenge: the XML file contains Protected Health Information (HIPAA protected) and needs a secure method for transport – attaching the XML file that a patient downloads in their home to an unencrypted email and sending it to their physician is not consistent with HIPAA security (though I am sure many people will do this). Although one could make the argument that the patient is not a HIPAA Covered Entity (the physician is), and if the patient voluntarily originates the sending of unsecure PHI, it is simply consumer health data, and only becomes HIPAA-governed PHI once it is received by the physician (the HIPAA CE). It is the physician who cannot send the PHI elsewhere via unsecured methods.

Clarification on this question – how to get the XML file from a patient who uses the Surgeon General’s web site independently to the physician – will need some attention. Physicians, using their EHRs, may have secure methods of transmitting files to each other (e.g. Direct tools), but it is an invalid assumption that patients (the public at-large) do. That is why it would be better for the tool to be embedded in a PHR – protection of security in transport is better managed there.

Not all (in fact, few) patients will fill out their family health histories on line from home, even if the availability of such tools is made loud and clear. Therefore, such a tool will need to also be embedded in the doctor’s EHR, so that it can be filled out at the time of visit (either by the patient directly, or by doctor’s office staff assisting the patient).

Conclusions
Gradually, we are seeing the capture of various elements of health data move from paper to structured input. For years, patients have faced the task of filling out health questionnaires at each new doctor’s office – the same information with each new facility. The main elements of these health questionnaires are the same: insurance information, personal health history, problem lists, medication lists, allergies, and family health history.

One by one, each of these elements are being captured electronically, with the hope that they are only needed once – and that this can be used for every setting of care. The health history form needs to be portable, managed and modified by the patient directly, and used in lieu of the traditional forms in every medical practice. The family health history tool is one more step in this direction.