On 27/03/2012 10:42, Ian McNicoll wrote: > Hi Thomas, > > I definitely agree here. While I think there is huge merit in having > some kind of simplified single Event OBSERVATION, there is absolutely > a need to handle the increasing numbers of device mediated multiple > event observations. > > As a modeller though, I really do not want to have to commit to one > class or another. I want to be able to start with a simple model and > 'unconstrain' that when and if the individual or generic use cases > emerge. Given the complexity of multiple event handling I suspect that > is a pretty tough ask but if you don't ask you don't get :-)
I am having a hard time understanding when the modeller would not know if there was a series of events or not. Surely all vital signs should be modelled as that (even if in some instances in the data, there is only one event)? There seems no other obvious way to model Apgar or OGTT; I would expect some ECG and blood glucose to be in time-series form as well. > That is why I was interested in what Marand are doing which > is essentially flattening or hiding the complexity of the mutliple > event Observation - simple API vs. Complex API where the simple API > just hides the complexity for the 80% of use-cases. Is that feasible? that was actually the intention of the original design - to support APIs that would allow a 'nice' way to create a single event Observation (indeed, it should have been defined in the Observation class itself). But if we want a single-event Observation class as a new variant, no reason why not. > > openEHR archetypes are still easily the best way to manage the very > difficult task of identifying clinical content requirements and > gradually developing these as new use-cases and complexities appear > but I think we can do more to make that process one where we can start > simple and gradually add complexity in a backward compatible manner. personally I think a lot more work is required on the tooling... - thomas > > * > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/6d30f05a/attachment.html>
