> "Summarisation" > > I think I probably have a somewhat more liberal interpretaion of > 'summarisation' , which would include analysis or interpretation of the > data, to include 'tissue/lab/x-ray diagnosis' but short of clinical > diagnosis.
well, clarification would help. (so would tooling!) > "Our model identifies five distinct stages of clinical summarization: (1) > Aggregation, (2) Organization, (3) Reduction and/or Transformation, (4) > Interpretation and (5) > Synthesis?http://www.sciencedirect.com/science/article/pii/S1532046411000591 yes, that's a nice model. > I?think?we also recognise that we need some way of simplifying OBSERVATION > for the 80% of single event uses and for integration without sacrificing the > less common but significant need for multiple event handling. (I think this > + associated tooling) would resolve most of the issues you had in the NEHTA > context. also an easy way of constraining it. The problem is that the general lab model may or may not include an event series > "One issue I have is that the event series imposes the same data at each > point," - can you give an example? umm. getting hazy now. There's one challenge (synacthen?) where you measure the hormone regularly, and keep track of the state of the patient by measuring something metabolic every so often. (glucose? so not synacthen?) My knowledge grows ever more imperfect by the day... > and by "repeating observations?is protocol" do you mean situations where the > method changes at each Event e.g. First blood pressure taken with cuff, > second with a machine? yes. or posture changes, or some such. > If so, I probably agree. In most cases the ontology and structure coincide > but there are cases where something that ontologically is protocol needs to > be in an event and vice-versa. right. We have imperfect separation. (Imperfect appears to be my word of the day) > I don't want to lose protocol. I think there is value in making the > distinction as part of the authoring process, if only as a way of making an > archetype easier to view, and as Sam suggests to underpin a generic view, > but I don't think we need to tie it to structure. I'm not sure what I want. I just think that there's a few different things bundled together here. Sometimes - even most of the time - that's useful, and sometimes it gets in the way. Would a more complicated model still be useful? I suspect not. I guess I feel as though I want a simpler model, since the more complex model is useful but not always right - a bad thing to have in a reference model Grahame
