On 27/03/2012 10:41, Grahame Grieve wrote: > hi Ian > > It meets perfectly the requirements I was aware of at the time, but now I have > a more perfect (ahh, less imperfect) knowledge. If I have a series of > observations, > I may provide some interpretation of them, that becomes the "observation". > This occurs with several diagnostic tests. But these cases > don't "summarise the entire history", in that they analyse the data. > 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 <http://www.openehr.org/issues/browse/SPECPR>? > > And tooling support, too, of course ;-) (though I suppose I could add > that myself) > > 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? > We've ended up pretending that the event series doesn't exist in the > observation RM > for the purposes of the archetype, both (partly) in how the design was done, > and (completely) in how we convert the archetype to a DCM. what's a 'DCM' in Nehta? > Partly that was a > pragmatic decision to do with tooling limitations, but it's not > obvious to me that > it would've played out differently if the tooling wasn't limited. 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). > > One issue I have is that the event series imposes the same data at each point, > which is not necessarily the case. 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). > And also, (back to protocol) > repeating observations > is protocol? (how they were each done), and this summary thing - is it > critical > to display, or just an adjunct? Better just to model the content in > data and be sure... but in that case, you can think of the protocol section as just more data. Note that in 90% of archetypes, it is used in the originally intended way, so I would not want to destroy the coherence of the 90% for the sake of 10% ambiguous cases (which I still don't understand by the way). - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/86b98fea/attachment.html>
