Useability vs reusability

Jun 11, 2011

It’s an issue that runs through IT - the payoff between use and reuse. See, for instance, this paper (and also this). The problem with reusing code is that it creates multiple dependencies on a single piece of code, and changes for one functionality can break another that’s completely unrelated - and, more importantly, untested (cause tests never cover every scenario the users are going to come up with). It applies to standards too, but the problem manifests differently. I’m looking at a specification - doesn’t matter which one - that defined a common interaction model for “entities” that are involved in a particular healthcare interaction. Each entity has:

  • Identifier
  • Name
  • Address
  • Electronic Communication

It’s nice, having such a simple consistent pattern - an entity library that gets reused all through the specification. The definition for address is:

“The description of a location where an entity (person or organization) is located or can be otherwise reached or found”.

That’s not a bad definition for a general address.

The downside with reusing “entity” like this is that the definition makes sense in the general case, but gives you absolutely no idea what is intended in some case. Take, for example, a healthcare transaction carried out in a an institution by an organisation, where the person who did the data entry is a required field, and as an entity, the person has an address defined as:

“The description of a location where an entity (person or organization) is located or can be otherwise reached or found”.

Right. So, ahh, is this just because they ‘inherited’ this address as an entity, and it’s entirely useless in this case? Or is it because the person doing the data entry might be in India doing transcription? Is there a specific desire to be able to locate the person?With such a generic definition, it’s hard to say.

Reusing generic definitions is good - but they have to be contextualised.

I think one of the problems with HL7 v3 is that we model so much, and don’t take the time to contextualise the definitions. Openehr also has this problem too - see this page, which provides context specific definitions for some reference model attributes for some uses. These establish some patterns but you’ll see archetypes out there designed without that knowledge (I own one or two myself).