Without paying attention to EN13606 or OpenEHR I produced the text. So when you have special classes fine. Then these classes act as what I called 'ancestor archetypes'.
Gerard -- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 On 8-sep-2005, at 0:11, Sam Heard wrote: > Gerard > > I have to correct you here - in an openEHR context anyway. >> 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. >> > It is important to plan for when information is connected and flows > - and not get in a mess about all the possible disconnects. As > medication order is an instruction, it is has a state machine - and > it is possible to report who recorded this - and the source of the > information if required. But it is always an instruction. It can be > administered and Act statements (with or without an instruction) > can be recorded based on the medication order archetype. But > medication orders are always medication orders - even if you record > them after the fact, these are entered as completed instructions. > > So the following do not fit in open EHR model. >> 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 > The basis for such an approach is that queries are reliable - a > planned medication is a state of medication - as is completed - and > are determined by the last Act statement associated with the > instruction. This is managed by the workflow engine but can > propagate in a distributed environment. So if you order a Pap test > bi-annually, no matter where the person actually has the pap test, > the Act statement can propogate back to the source of the order. (A > bit futuristic but one day this will be the norm!). >> What we miss in this list is the context where the extract reports >> that something has been executed. > This is the openEHR ACT class. We need to get you in touch with the > INSTRUCTION class - perhaps Tom will put the latest paper around. >> 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 >> > > -- > Dr. Sam Heard > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > CEO and Clinical Director > Ocean Informatics Pty. Ltd. > Adjunct Professor, Health Informatics, Central Queensland University > Senior Visiting Research Fellow, CHIME, University College London > Chair, Standards Australia, EHR Working Group (IT14-9-2) > Ph: +61 (0)4 1783 8808 > Fx: +61 (0)8 8948 0215 > > - If you have any questions about using this list, please send a > message to d.lloyd at openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050908/2b3fb5ca/attachment.html>
