> Perhaps I am splitting hairs, but isn't that what definitions are for? I'd
> like it relaxed a little.
>
> can you post a Problem Report here?

ok, I'll do that.

> Generally, in the NEHTA context, we've struggled with the openEHR RM here.
> Partly it's tooling (AE and CKM) - it doesn't support the things we want to
> do.
>
> is there a definitive list of shortcomings or unmet needs?

no. partly because... we're not very definitive by nature. But more because
you trade between approach and tooling and options.

> what's a 'DCM' in Nehta?

sort of take an archetype, and represent it in a neutral format
which isn't supposed to take any experience except UML to understand.
Take out all the openEHR-ness, really. It's useful, because it makes
a lot of RM stuff explicit, and we really need to be able to do that in
archetypes (comment on the meaning in a context, make limitations
on the possible values)

> I assume there are not yet any Nehta archetypes for data that are natural
> time-series, like vital signs, Apgar, OGTT etc (I would expect the main
> openEHR ones of these to work fine).

Don't think so. we don't model at that level of specificness. Partly this is
EHR vs general clinical modeling.

> well it is the case for the History/Event structure - by definition. If you
> have a situation where it is not the case - there are many! - then this is
> not the data structure to use; just use separate Observations (possibly with
> LINKs between them).

well, currently, that means that we have to break up what is a simple single
archetype otherwise into a set of archetypes, and we have poor binding between
them. This should be one archetype, but as far as I can tell, neither AE nor
CKM allow this to be the case. In ADL 1.4, we'd have to depend on Regex
linking the parts together... not good. And now I've got another
problem - I want
one observation which is a cluster of observations... I've run into issues with
the RM now.

Grahame

Reply via email to