NEHTA Clinical Documents: SHS Medical History

Aug 15, 2012

In previous posts (here and here) I covered the exclusion statement. Now I can move on to talking about the SHS Medical History Section, which contains a simple list of a patient’s past procedures and problems/diagnoses. ### Definitions… Note, before I go on, that there are fundamental and important challenges around the question of what are procedures, and what are problems/diagnoses:

  • Is counselling a procedure?
  • Is “pregnancy” a problem or diagnosis?
  • Is “family history of heart disease” a problem?
  • What’s the difference between a problem and an alert, and also an adverse reaction?

This post is not about exploring these questions, but they are not irrelevant. These are official definitions (from the SCS):

Procedure A clinical activity carried out for therapeutic, evaluative, investigative, screening or diagnostic purposes
Problem/Diagnosis The problems and/or diagnoses that form part of the past and current medical history of the subject of care.An account of relevant identified health related problems as reported by a healthcare provider. This can include a disease, condition, injury , poisoning, sign, symptom, abnormal finding, complaint, or other factor influencing health status as assessed by a healthcare provider.

Section Design

The general design of the Medical History is:

  • A CDA section
  • a list of Problems/Diagoses, or an exclusion statement

  • Problems/Diagnoses have a code that identifies them, a date of onset, a date of resolution/remission, and a comment

  • a list of procedures, or an exclusion statement

  • Procedures have a code that identifies them, a comment, and a date on which they started

  • A list of “Other Medical History” items
  • Other Medical History Items have text description, an interval during which they applied or occurred, and a comment

This SHS section was intended to be a simple statement of a person’s medical history - as simple as possible. But 2 things complicate it considerably: dual exclusion statements, and the presence of “Other Medical History Item” means that it is far from simple.

Dual Exclusion Statements

Although, in the simplified SHS section, Procedure and Problem/Diagnosis contain very similar content, in general, their content is different, and so they are treated differently through the entire stack (archetypes in the clinical knowledge manager, DCMs derived from them, Core Information Components, SCSs, and in CDA itself. Hence, the Medical History list is broken into the two parts.

But because of the way the underlying definitional methodology works, we end up with two exclusion statements - one for procedures, and one for problems/diagnoses. From a strictly informational perspective, this makes sense: The patient has no listed procedures, a long with a reason (if it’s “nil known”, there’s generally not a lot of uncertainty about this one), and/or they have no known problems/diagnoses (young, and lucky - for now).

It’s important, though, to understand that fundamentally this is conceived of as a single list - the patient’s medical history, just with variant parts. From a user point of view, then, this a little difficult to present. If a patient has past procedures, but no problems/diagnoses, how do you present this?

Putting aside the obvious implicit relationship between procedures and problems as demonstrated here, this is just difficult to present. Especially since the user thinks of these as a combined list, and mostly edits them accordingly in their software (though not always - clinical systems vary wildly on this).

Other Medical History Item

Would that this was the only problem. However it’s worse than that - the common GP systems (planned  to be the major source of SHS generation) not only maintain a single list “medical history”, they are unable to determine the difference between procedures and problems/diagnoses. Usually this is because the coding systems they use (ICPC 2+, Docle, home grown or user defined code lists) don’t include the structural support to resolve the code to either a problem or a procedure (also, some of them allow symptoms and medications as proxies for problems or procedures). So although the methodology calls for separation between problem and procedure, not all the systems are able to do so - but some are. Aside: If all the systems adopted Snomed-CT, and the users changed their practice when it comes to recording the medical history so that it was more rigorous, then we wouldn’t have to worry about this. But even if this magically happened instantly (as in, in the next 5 years), we’d still have decades worth of legacy data that we would want in SHSs. And it’s going to take a lot longer than 5 years to get clinicians to see the value - if it does exist - in spending a lot more time coding the medical history (that depends on how clinical decision support unfolds, which is not the subject of this post). So we have to solve this problem

The solution then is that we introduce “other medical history” - an entry in the list that is not known to be a procedure or a problem. It would be simpler to collapse both procedure and problem to a single content model, but this would lose the capability to differentiate them that some systems have, and it would either mean that you couldn’t differentiate them in other more sophisticated documents than the SHS, or these other documents would not have continuity with the SHS - which generates a whole slew of downstream problems.

Hence, we now have a list of 3 types of items: problem, procedure, or something that might be either?

What, then, is the effect of this on the exclusion statements? Well, if you have an “other” item, it might be a procedure, or a problem - you don’t know. So you can hardly make an exclusion statement about either of them in this case. This leads to the following rules:

  • If you have any entries in the “Other Medical History Item” list, then you can’t have an exclusion statement for either Procedures or Problems/Diagnoses
  • If you have neither procedures or other items, then you need a procedure exclusion statement
  • If you have neither problems/diagnoses or other items, then you need a problems/diagnoses exclusion statement

Because these rules are not clearly documented in the CDA Ig or the SCS, it has created much confusion - especially around people wanting a separate exclusion statement for Other Medical History Item. But this can’t be - it would only make the clinical problem worse.

In practice, there’s mostly only one exclusion statement - and this is actually implemented in most of the GP systems, where the user get’s to say “Nil known medical history” or something equivalent to this. This produces an exclusion statement for both procedures and problems/diagnoses.

Other Issues

There’s an additional problem here: the definitions of both Problem/Diagnosis and Procedure are loose and a bit tautological. In practice, things don’t go in them if they can go anywhere else. For instance, an adverse reaction - but a coding system that can’t differentiate between problem and procedure isn’t going to differentiate between them and an adverse reaction either. But there’s nothing we can do about that for now - adverse reactions will be found in either place. And when family history, alerts, etc are introduced in the other documents and maybe in the SHS, then that problem will become worse.

In terms of presenting this structure to the users, most of the systems have gone for a differentiated list like this:

Actually, this comes from a NEHTA sample for testing CDA rendering. From a real clinical system it would be unusual - it would imply that the system was able to differentiate two of the conditions but not a third (might happen if a coding system was upgraded, for example). So it’s not technically wrong.

But from a user point of view, separating the lists like this is sub-optimal. There should only be one list in chronological order - this is the medical history, a list of problems and procedures that have all sorts of implications between each other, and that tell a history. So one list:

Obviously the more dates you have, the more useful the list becomes. But these depends on the source system and the clinician who entered the data.