Tim Benson wrote:
> There is a difference between a structure which is designed to handle all
> sorts of record structures, like 13606, and what you design to do a specific
> job. The best system is one which meets the user requirements in the
> simplest possible way. In any real system it would be an unacceptable
> overhead to provide functionality that no user of that system will ever
> need.
>
> To give just one made-up example. You need to identify physicians. Most
> countries (certainly the UK) allocate a national identifier. There is no
> need, and it makes little sense, to build in a whole lot of further
> information about that identifier, such as the name of the registration
> body, the date of original registration, when it expires, the countries
> where it is recognised, the name of the registration clerk who allocated the
> number, and the type of check digit used.
GEHR at least provides as much or as little extra information as you want, i.e.
as you specify in the "hcp-demographic-snapshot" archetype (hcp = health cre
professional). The reason why any extra information is needed is if the record
is transported, copied, etc to another computing context where the demographic
identifiers are useless. This is easy to do. Even if it shifts to a mobile
computer being used out in the bush, where no telecomms are available (or are
down).
AFAIK, CEN specifies the extra details for the same reason, but since no
archetypes are used, it has to try and predefine a demographic snapshot that
will be useful everywhere (I would argue that this is nearly always impossible
to do).
> General purpose schemes like 13606 and GEHR tend to provide ways of
> recording this sort of data, because someone somewhere may need it. Any
> real system will only use a small profile. The purpose of these schemes is
> to facilitate interoperability.
Correct; the profile for most demographic snapshot archetypes in GEHR is about 6
or seven details; if some other defining body wanted to change this, they can
simply invent better archetypes.
> In my view, the real value of 13606 for the system designer is that it
> provides workable solutions to lots of real life problems, such as:
>
> 1. Names, addresses, contact numbers and identifiers.
Be careful; hard-coding this kind of model can also be restrictive. But (as you
know, Tim!) HL7's newer Entity & Role & Role-relationship additions to the RIM
are a step in the right direction - this general kind of model is perfect for
archetyping or templating.
> 2. Relationships between patients, physicians and hospitals (which are not
> hierarchical).
Which is the reason why teh above-mentioned RIM additions are useful. We will
probably re-instate these into GEHR soon, and I think CEN should probably use
something similar (Although, "Entity" is a bit useless; "Party" is better;
"Patient" is a kind of Role-relationship).
> 3. Time periods and relative dates.
And approximate dates. These are the hardest to model.
> 4. Test results, normal ranges, comments on results etc.
> 5. Context and attestation.
Probably the most important CEN & GEHR contributions to EHR models in one sense.
> This systems analysis work (the information model) is of the highest calibre.
> It is also important to recognise what 13606 does not do. Consider the NHS
> Requirements for Accreditation (RFA). 13606 provides an information model,
> but RFA requires a lot of detailed functionality not mentioned in 13606.
> For example any real system needs to handle information life cycles. 13606
> provides a snap-shot. To use business analogy. 13606 is analogous to a
> balance sheet, which is very useful for some things, but is pretty useless
> as a tool for order flow. In fact, 13606 part 4 does cover the order flow
> of moving a record from one system to another, but that is not what goes on
> within a system.
I don't quite see it this way: if the EHR is an aggregation of additions (GEHR:
Transactions, CEN: Contributions?), then the raw data is there for determining
life-cycle activity of some things. I GEHR we have used versioned transactions
from day one to facilitate this further. Now we know to use the versions of a
transaction to allow single state variables to change, e.g. the status of a
medication order (ordered, administered, cancelled, completed, etc) or any
process in fact.
- thomas beale
