Fractal Electronic Health Records?

Clinicians record their findings and conclusions remarkably efficiently on paper, recording the contextual variations succinctly and in a way that other clinicians can understand. Getting computers to do the same thing – to enable clinicians to record simply in the normal circumstances, but be able to cope with the complex and detailed where it is critically needed – is not a trivial task. Ensuring that a user interface reflects a clinician’s work flow and captures the evolving requirements in a clinical consultation is extremely complex. Obviously computers are not as flexible as a human brain; they can only record what is pre-ordained in their programming.

We clinicians should expect our electronic health record (EHR) applications to do be able to support our recording requirements and work flow however, in reality, there are very few clinical systems that do this well.

Identifying recurring patterns in clinical practice help to ensure our EHRs can record health information effectively. When we look closely, clinical medicine is fractal in nature.

What do we have to record, display, query and exchange in our EHRs? Lots of measurements such as Pulse, Temperature, Blood gases, Apgar Score, Height, and Weight are pretty straightforward. Those screens are a breeze – type in a couple of numbers and hit ‘Save’. Evaluations, diagnoses and assessments are also pretty uncomplicated.

However it starts to get much more complicated when we start to explore history-taking and examination findings – where the bulk of the ‘art of medicine’ takes place.

Let’s think of the evolving nature of a typical clinical consultation. It would be so nice if each patient walked into my consulting room with a single, neatly packaged problem for me to solve, but this is not the norm. In fact the majority arrive with the dreaded ‘shopping list or, worse still, with multiple problems that are gradually revealed one by one throughout the consultation. So while computers will capture a linear work flow really well, the typical patient consultation is anything but linear.

But each of these problems will likely be recorded in a common pattern – reason for encounter, history of presenting complaint, systematic questioning, examination, differential diagnosis, investigations, diagnosis, management plan and follow-up.

Consider a simple skin examination. The clinician inspects the patient’s back and finds an abnormality – a dark, warty lesion. They record its location, dimensions, shape, regularity, surrounding skin etc, and – oh oh – that there is an area within it with increased pigmentation. Then they focus on the hyperpigmented area – recording location, dimensions, shape, surrounding tissue etc. Then they take a photo for future reference and pull out the dermatoscope – recording yet again the location, dimensions, shape, surrounding tissue etc. There are repeating patterns identified here at increasing levels of granularity.

Recently I’ve been modeling the examination of the hand. Easy, I thought… at first. OK, we’ll use the general clinical principles to record inspection and palpation of the hand as a whole, including specific hand-related items such as presence of Duypuytren’s contracture, wasting of lumbricals plus circulation, sensation (pinprick, temperature, vibration etc), and strength. Then we need to potentially be able to examine in detail:

  • per named finger – again inspection and palpation per digit, plus circulation, sensation, movement of each joint on that finger
  • per named nerve eg median nerve distribution
  • per named tendon
  • per named joint – inspection, palpation and movement of each joint
  • per named bone – palpation

And if we found something on inspection of the finger such as a nodule, we need to be able to inspect and palpate the nodule. And if there was a pigmented part of the nodule we’d be documenting it in a similar way to the wart on the back – inspect the pigmentation in detail, including an image of it for future reference. These are incredibly complex recording requirements.

Which way we view or prioritize these requirements will depend on the patient context and the expertise of the examiner. For example, recording needs for a hand examination by a General Practitioner will differ from that of a Rheumatologist or an Orthopaedic Surgeon. Consider also the plastic surgeon about to take a patient to surgery to repair a severed finger will absolutely need to be able to record a detailed breadth and depth of not only the hand and the finger but the digital vessels and nerves that will need their expert attention.

Do you get a sense of the fractal nature of medicine? Repeating patterns in the way we record health information:

  • revealed as we repeat the work flow of a typical history and examination process; and
  • revealed as we record our findings in more and more detail.

Content modeling for EHRs needs to reflect the fractal nature of clinical medicine accurately, both coarse and fine levels of granularity, and ensuring that the data capture is ‘fit for clinical purpose’.

Inspired by @samheard, as usual;-)

5 thoughts on “Fractal Electronic Health Records?

  1. Pingback: ICMCC News Page » Fractal Electronic Health Records?

    • Hi Nina,
      There are a number of groups trying to standardise clinical content in various ways around the world.
      My direct experience is where these clinical patterns are being identified and built into computable specifications, known as archetypes, by the open source community working with openEHR – The archetypes can be aggregated and nested to support the clinical data capture/workflow requirements (as described in the post) for EHRs.
      There is a repository for archetypes at – where clinicians and informaticians from over 50 countries are collaborating on building, reviewing and publishing the freely available archetypes. The repository is still relatively new and community momentum is building.
      Some examples:
      Blood Pressure –
      Diagnosis –
      Inspection of skin – and its specialisation, Inspection of skin wound –
      To give some perspective, only about 20 archetypes are required for a Discharge or Emergency summary; 50 archetypes will provide core content for a primary care EHR and we anticipate that only around 2000 archetypes will be required to support most of an full EHR application.
      Hope this helps,

  2. Pingback: Some you may have missed – 07 February, 2010 « IMIA News

  3. I think this is an astute and very well-explained observation. But then when you think about it, recording any information about *reality* means there’s an infinite level of complexity. So health is just an important field where we really need to record it and record it properly!

    That’s why the openEHR approach makes sense. If you have a semantic structure representing the maximal detail likely to be recorded for a given clinical observation then the main challenge is to somehow give the clinician a way to quickly and easily deal with all the “fractal” levels of possible data entry.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s