Comment

Comment by Peter Jones on November 24, 2010 at 8:44pm

Thanks for digging into this further Gabriel. I agree completely, from an information design and a cognitive psychology perspective. Information must be displayed and registered in context or it becomes a meaningless set of values that the information seeker pieces together inductively. But this will never add up to the simple meaning a physician can bring to the patient when co-creating that narrative. When you say "All we need to do is to design the interface to capture this," well, that's not as simple as designing a product. The contextualization of that data from a poorly-designed EHR and API to help patient sensemaking is a daunting, wicked design issue.

I'm working with a small outfit to bring some new visual interface concepts to the point of EHR use (whether inpatient or out) and hoping to get some of those designs in the book.

If not, we'll have to continue the book with this site and to keep these discussions alive with new examples as they show up in practice.

Comment by Gabriel Chan on November 23, 2010 at 4:25am

Hi Peter,

Sorry I missed your main point - poor uptake by the general population of the Health 2.0 resources. I see there is an interesting issue here. "If you build it, they may not come!".

I might take the opportunity to expand on my line of thought to see if it makes sense or not. In my opinion discrete health data is largely meaningless. This is why I feel that a truly good EHR program is essential to underpin the personal health information sphere. On a daily basis, patients come to doctors nowadays with selected pieces of health information cross-collated with their personal scattered selections of other personal health data (lab results, scan reports and so forth), and present the doctor with their questions around their largely logical conclusions.

I would agree, as the original post points out, this does not and cannot derive real value for the patient. The poor uptake reflects this, I suspect. Health data only becomes meaningful in an exact, and narrative-driven context. It is hard to ascertain context in the cloud.

This is why I think a truly good primary healthcare EHR application is essential for Health 2.0 to really work. It is your family doctor who contextualises this information. The training it takes to know how to ignore spurious information, and seek out the requisite and necessary facts is what defines medical education. All we need to do is to design the interface to capture this, and store the wrappers with the raw data, which is then uploaded in an accessible state. At that point, we have meaningful data, and can start to derive value from it for ourselves.

What do you think ?

Comment by Peter Jones on November 22, 2010 at 9:06am

Gabriel - I must have missed your post, since I'm just now finding it a week or so later. Its interesting to hear that the Australia HIT situation is roughly similar to that of the US, even with very different health systems and providers. The original piece I wrote was with the intent of comparing the sketchy adoption of "Health 2.0" services by real patients with real needs. This post was odd in that there are at least 4 opinions squeezed into one brief piece, all somewhat in agreement. As I think yours is as well.

In comparing patient-oriented Health 2.0 with EHR services, I just wanted to point out how information does not lead use, the human need and process flow leads information. Merely giving a patient access to health records does little to empower them. Who thinks that PHRs as they are designed today will drive a patient-led health revolution? We have to start somewhere, but where? With the hundreds of start-up entrepreneurs in the Health 2.0 space?

Closed, proprietary, anti-standard EHRs are a systemic design problem, since every future integration will be forced to work with the installed plant of the records database, on its terms. Today, these systems are administrative management with some bad clinical interfaces thrown on top. For the patient, the best they can hope for is a mixed collection of documents, where formats are mixed between providers and labs, and in language of codes and values incomprehensible to consumers. The contents of records are not semantically linked to patient/condition, but presented in date and billing relationships. And policy (US HITECH act) and practice (which differs by service) determine the initial constraints that lead to the adoption of these systems and outputs.

While "garbage in" is also a problem, information output requirements determine how the system is used institutionally. The opportunity to design better quality clinical and staff interfaces is restricted in advance by these architectures. People I know designing EHR applications are always creating workarounds and one-off apps. Its hard to see how these systems will evolve into something that patients can use and benefit from in the near future.

Comment by Gabriel Chan on November 9, 2010 at 3:40am

Hello Everyone,
I am a family physician working in Australia, and am interested in developing new software/interface for EMR/EHR's. The opinion above in an interesting one, but I'm unsure if it is correct.

From my (limited) exposure to the kind of health records and clinical software out there, I believe that at the moment, EHR design is part of the problem of fractured, disinterested health care provision. By this, I mean that historically poor design is hampering the potential of health providers to give coordinated, thorough care to their patients.

Poor information gathering, and poor organisation of the information has deep impacts on the kind of care a patient can receive. This is true both immediately - in the patient-doctor consultation, and further beyond the moment of service, when planning, reflecting on and reviewing of aggregate services provided.

Australian health somewhat mirrors the health challenges which face Americans. An ageing population with greater prevalence of chronic diseases means that the coordination of care, and diligence in monitoring and scheduling of important health activities takes greater precedence than ever before. In addition, there is a broad range of quality of doctors - from excellent to the not-so-excellent - owing to immigration, fluctuating quality in Medical training, and individual differences... Really good software design can be a subtle guide for the uncertain practitioner (e.g. building in normalised ranges for some results, flagging contraindicated drug relationships, visual prompts to do screening tests), and can help the average doctor improve their delivery ( building in advanced options for treatment as a prompt ) and make the excellent doctors more efficient (more throughput).

A capping of health spending also means that budgeting resources (whether at the practice, town, regional, state or federal level) should be carefully tied to real, and actual disease and health needs. Hence, an accurate health information system is crucial, even though it is not immediately apparent how this helps in the first instance.

Messy large-scale EHR are the way they are, I believe because they do not address the core issue at hand. At the very start, the EHR was a paper and pen clinical tool to help a doctor(or nurse, or paramedical person) deliver their thoughts and decisions to give the best treatment for a patient. Anything else is a secondary benefit. I think that developers gave far more thought to the secondary benefits than to the original function, and thus, the plethora of service-interrupting, flow-disrupting, time-wasting, messy, programs out there which take away from the first intent of the user.

This is the reality I perceive. Grass-roots public health really needs clever tools. All the more so, because it is always hampered by being un-sexy, and has to do ever more good, with less resources. To be more efficient at any given task is the original driving impetus for the creation of tools. Let's get on with making a true "tool" for medical/clinical work !