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 :-) 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? 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. Ian On 26 March 2012 20:47, Thomas Beale <thomas.beale at oceaninformatics.com>wrote: > On 26/03/2012 19:49, pablo pazos wrote: > > Hi Thomas, > > A while ago, we gave this issue a big thought when designing the EHRGen > framework. > > Periodic event records are needed when recording certain studies and > when monitoring a patient, but this can be recorded as single point events, > and using a query to get all the points in a series. > > > it can but that's very inefficient, and doesn't correctly represent what > is happening, when you are talking about multiple samples in a series, e.g. > coming from vital signs monitors, orthostatic BP, apgar, and many others. > > > > From the GUI perspective is very difficult to record periodic events, > because you have to login, select a patient, select a record, select the > section of that record that contains the periodic data, enter a new item to > the time series. > > > and presumably enter another, and another. That doesn't sound like a > problem - it's how normal GUI for Apgar and multi-sample manual BP > collection work. Don't forget, we are talking about time series in the > seconds to minutes domain here. Although Glucose tolerance test data would > make more sense to be entered as one time series, after the fact. > > The other option is to have the patient's record always open, and that > is not possible in all scenarios (for technical or security reasons). > > > well ifyou are talking about long period of time, like repeated nursing > observations, you should be committing those 1 sample at a time. > > > > In the other hand, in the majority of cases of clinical record through a > GUI, the data is recorded as a single point event, e.g. at a patient visit. > So we design the EHRGen just to use point events, and if you want to record > a series of events, a service should be provided to get the data from other > systems (e.g. a LAB system), but not from the GUI. > > > that and vital signs monitors are certainly a common source of time-based > data. But whether the source of the data is the GUI or somewhere else > doesn't change the semantics of the model, or the need for it. Like I said > elsewhere, I have no problem with adding a single-event Observation as > well. But having only that will completely cripple many hospital apps and > efficient data representation and querying related to this data. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com *Primary Health Info 23 ? 25th April in Warwick ? are you coming?<http://www.primaryhealthinfo.org/> * Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/8bca2576/attachment.html>
