Clinical Safety: Mandatory Fields

Sep 20, 2013

This post is actually prompted by the FHIR ballot, where there’s a whole swag of ballots saying that the minimum cardinality of a field should be 1, not 0. But it’s a generally tough issue - when is it right to set a minimum cardinality of 1? When you set an element/field/attribute/property/whatever to a minimum cardinality of one, you are saying that this item MUST have content. If, for some reason, a sender of content doesn’t have a value for this item, then they can’t communicate.

Note about v3: Actually, in v3  / CDA it’s more complicated than that, because even if the element has a minimum cardinality of 1, it may still allow a nullFlavor, so it’s not actually required. For the purposes of this discussion, then, we assume that for v3/CDA contents, not only are we setting minimum cardinality to 1, we’re also making the element mandatory.

It’s really tempting, when doing a design, to say, “of course there’ll be a value - how could there not?” Only, it turns out in real life (or at least, in clinical practice, since that may not be the same thing), things you thought would be always true turn out not to be sometimes for some weird edge case. And if you haven’t though of the weird edge case, what it supposed to happen when it comes up? I know what happens in the real world: people make things up. Yes, they lie. Either the programmers or the users, they figure out some acceptable un-risky lie, and go ahead and make it.

Perhaps calling it a “lie” is a little strong, but if the system makes people fill out a field to get through their workflow, they’ll put something there, even if it’s an outright mis-truth. (I recall one system where the doctors had to fill out a diagnosis for their patients, even when they didn’t have one. After a few weeks, one doctor was entering “generally unwell” for every patient - even the ICU ones.

So the lesson is, you have to be real sure that there’s just no possible way for an value to be unknown before you go and make it required. Obviously, the narrower your use case or implementation scope, the more confident you can be. So in an international standard, many fields that are logically always present are actually allowed to be missing to cater for edge cases (and in the case of FHIR, where the usual logic is that the resources support core/80% behaviour, minimum cardinality is an exception to this rule for exactly the reasons quoted here). Where as in a profile, for a particular project, quite a lot of items are going to be minimum cardinality of 1.

Another aspect of the problem is that people think about the which elements should be present in the primary use case - the natural workflow. But interoperability models are used in all sorts of secondary use contexts. A simple example here is that of course you would always have a patient name… unless the data has been de-identified.

An entirely better way to think about it is that you only make it mandatory if there’s no way to sensibly do anything with the contents of the resource if it’s missing - then you make it required. That’s how it is with FHIR.

Trading Partners that disagree

A different manifestation of this problem is when you have two systems exchanging data with each other. System A says that an element is mandatory - because the work flow it manages can’t proceed without it. Let’s say, the patient account status/type. The other system, it doesn’t use patient accounts at all, so it doesn’t make it mandatory, and the users don’t bother filling it out.

Fundamentally, this is a workflow problem - but the fact that this is a workflow problem is often lost beneath several layers of analyst and programmer, and it often emerges as a surprise late in testing the interface. My rule thumb here is that operational clerical staff are far better at testing the edges of your system than a tester ever will be, particularly in terms of creative ways to hack the data to support a perceived workflow (not documented, of course…)