> 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