Grahame Grieve wrote: > hi Tom > > Much to say (sadly) > > > The only thing I'd say to this is that this seems like a use-case thing rather > than a definitive information model thing. I should not be assuming a > particular > work process when designing an archetype - that's a template thing. Isn't it? > correct....but the possibility of the patient not answering may not be (that) context specific. For example clinical archetype designers might all agree that 'patient unconscious' needs to be designed into an archetype for 'ED admission by ambulance' - it's specialised, but the same all over the world. > > > even for the simple case where a value may be measured or derived, I > think this > is significant. I used to do Lipid analysis. If other lipids were normal, we'd > calculate LDL-Cholesterol, otherwise we'd actually measure it. Around the > cut-off > we used our discretion, but we were required to report whether we calculated > or > measured the value - but since the value was usually interchangable, we used > the > same code to report it. > ok - that's a good use case. Know of any other lab cases like this? > > >> make use of such an indicator? Is another way of seeing this to mark data as >> 'coding required', as would happen today where coding is often done as a >> post-data capture activity? >> > > I think this is a valid use case - how would I represent this in openEHR? > in the main architecutre - nowhere. You would probably write your app so that it kept track of a path/coding status table or somesuch. > >> I will leave it there for now. As I say, the point here is to show that >> openEHR >> deals with use cases in a sensible and clear way. >> > > I think that some of the implications for how OpenEHR chooses to handle > this are under-appreciated by archetype designers. > I would agree with that - the reference model gives a lot of power; not everyone realises what is there and what does or does not need to be done in archetypes. Part of this is a weakness in our education; there may be some genuine weaknesses in the model / framework as well. Need to leave something for tomorrow ;-)
- thomas beale
