Hi, In my parlance: Messages are to update databases and are facts. eg lab results Documents are to update humans with professional opinions that are signed.
The EHR and its extract are documents. Depending on the type of archetype that what is recorded is: -anamnesis (history) -observation - plan - order Each of these four types form a family of archetypes and indicate context. Medication information inside an anamnesis archetype means that this is reported by the patient or others (eg the pharmacist when he sends a copy) Medication information inside an observation archetype means that this is observed by the healthcare provider Medication information inside a plan archetype means that this is an intention by the healthcare provider Medication information inside an order archetype means that this is a prescription on behalf of the patient for others (pharmacist) to dispense/provide What we miss in this list is the context where the extract reports that something has been executed. This means that we have to provide for an archetype type that indicates that a plan is executed, or an order is executed. We have to add the execution type of archetype. If this is the case we need attributes that allow us to indicate a cancellation, of anamnesis, an observation, a plan, an order and execution. This makes the complete list: -anamnesis (history) -observation - plan - order - execution of a procedure. And next we need the machinery to indicate the cancellation of these. I'm just providing some thoughts. In the AKF project we need to address all this. Part 1,2,3,4,5 of EN13606 are not affected. Gerard -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 6-sep-2005, at 23:04, Williamtfgoossen at cs.com wrote: > Hi All, > > Interesting concepts discussed here: An EHR for a clinician deals > with two major classes of information: > > 1. Classes that describe the situation of the patient (different > levels of detail, changes over time, enourmous sets sometimes) > 2. Classes that describe the behaviour of care professionals ( a > single medication description, giving information, asking consent, > performing a procedure,a gain many). > > Often # 2 are triggered by #1. > And #1 and # 2 can have different time formats (past, present, > future). > > However, a proper EHR should allow to include 'future' things that > could or should happen. E.g. in care planning it is important to > have a start value of the situation of the patient, compare this > with historic description of this situation when available, state a > goal of what to expect in an overseable time, and then check for > the actual outcome e.g. after care has been carried out. > > If an EHR can only store what has already happened, so the past, it > becomes useless for supporting clinical practice. > > It is interesting that the concepts of trigger is fundamental to > HL7 dynamics, and the 'mood' of the action / obs (so #1 and # 2) > are already available in the RIM classes: INT, RQO, GOL, EVN are > very powerful to support the dynamics of monitoring and workflow. > Key components of EHR. > See also the ISO TS on the EHR in which both data / structures and > dynamics are the first 2 chapters. > > Sams distinction between action required versus for your > information only is interesting and probably would need further > development on message and on EHR level. > > And again: from the perspective of clinical documentation and care > planning the disctinction between message and EHR is arbitrary: we > have systems that are integrated or that are coupled, that have > similar functionalities. Key is that we analyse #1 and # 2 > appropriately, model it for ICT and only then develop the tech > stuff in which it works. > > My 3 Euro cents, > > William -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050907/c59f917e/attachment.html>
