# 'Actionability' of orders **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2005-09-06 20:27 UTC **Views:** 2 **Replies:** 39 **URL:** https://discourse.openehr.org/t/actionability-of-orders/14503 --- ## Post #1 by @Sam Gerard This area is interesting. At a recent meeting of Standards Australia it was determined that an extract should say if it is for information only or there is, within it, the expectation that some action is required. This should, we felt be boolean ie unambiguous. It took some time to come to this - but an example is an extract containing a medication order that is sent to the pharmacy (action required) and copied to the specialist (no action required). The *open*EHR instruction class that is almost fully specified now and will be in version 1, will take this sort of thing to a new level. We need more debate on this, Sam Gerard Freriks wrote: --- ## Post #2 by @williamtfgoossen In een bericht met de datum 6-9-2005 22:32:06 West-Europa (zomertijd), schrijft sam.heard@oceaninformatics.biz: 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 --- ## Post #3 by @system 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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #4 by @Jan_Ravet Ok, Do we also need to "grade" the degree of execution for "orders"? If I want the patient to take a short course of antibiotics: I could: a. write a manual prescription b. make a note in EHR to that effect OR use my computer system to: print the prescription record details As a general practitioner, my remit is normally served by the further actions of: signing the prescription giving it to the patient. We could also consider recording, somewhere along the line: when was the prescription given to the pharmacist when it was dispensed, ready for collection who the dispensed product was given to (patient or "agent") and when the patient started treatment when they stopped, (resumed, started again...) (why they stopped, resumed...) how many tablets were left after the patient stopped taking the tablets and maybe even disposal of those tablets. I guess most of those are implemented in relation to narcotics, in most countries. I would humbly submit that Completion of the order is not a simple Boolean. For each of the above, a truly detailed record would retain: date, time, identity of the agent completing that step, identity of the agent recording the step, and possibly a text field to record any further ambiguity not originally compassed in the definition, such as the patient vomiting at some undefined interval after oral administration. Jan Ravet Augusta West Australia --- ## Post #5 by @williamtfgoossen In een bericht met de datum 7-9-2005 0:13:04 West-Europa (zomertijd), schrijft gfrer@luna.nl: > - execution of a procedure. > > And next we need the machinery to indicate the cancellation of these. Yes, this is exactly as the two attributes in HL7 v3 RIM Acts: moodcode to indicate the plan versus execution (INT versus EVN) statuscode to determine whether this Act is active versus cancelled or on hold or similar. William --- ## Post #6 by @system William, The difference is that in CEN it pertains to an archetype And in HL7 to a much more molecular/atomic construct. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #7 by @Hubert_Mensch Gérard, May I propose a contribution on the the question you pose ? 1 - Concerning the cooperation between actors and roles The two reasons you mention make me think of the Searle's speech acts, amongst other developped afterwards by Vinograd in his "conversation for action". i) - reason one : "illocutionnary" act which can be : -- a request for an action performing (order, instruction, letter where one can find a request, ...) expressed by a requester to an offerer and which implies an answer from the offerer : accept (and then the offerer commit to do what is requested), amend, refuse. -- a commitment for an action performing expressed by the offerer. In practice and depending on the cooperation rules, the commitment is sanctionned by an appointment. The appointment can be in the letter ... -- a report on the the action performing expressed by the offerer to the requester (professionnal opinion or advice following a request, lab result, ...) -- a validation of the report (or of the action performing ?) by the requester ii) - reason two : "propositional" act which gives the content of the speech act : -- professional content for a request, with reason, target, condition of the patients influencing the performing of the requested action -- professional content for the commitment -- for the report. it is interesting to distinguish there the differences of the professional content between a diagnostic and a terapeuthic action. The conversation for action is one of the components of the cooperation. Another one is the coodination of the care plan performing, when for instance an actor/role notifies the following one that the action he was responsible for is performed (or is not performed). May-be other component exists ? Reports and notifications are different : report is sent to the requester within the conversation for action, and notification is sent to the following actors/roles within the workflow coordination, may-be with an another professional content. The information system is intended to support this cooperation messaging. 2 - Concerning the fact that the EHR is the support of cooperation messaging. In the schema you describe, the EHR is the obliged "documentation device" (or I could say messaging device) between HCPs to communicate within the "conversation for action" or for the coodination. One can imagine that there are 3 dossier elements related to the same action performing - in the performer dossier - in the cooperation system - in the requester dossier The utilisation of these "versions" inof the same act the care process should be studied. HI H. Mensch GMSIH --- ## Post #8 by @williamtfgoossen In een bericht met de datum 7-9-2005 13:32:50 West-Europa (zomertijd), schrijft hubert.mensch@gmsih.fr: Dear Hubert, I am very pleased to read that others relate the activities of professionals to theories as Searle, Vinograd and probably others. I agree with the analysis below for the need to distinguish between the illocutionary and propositional aspects of speech acts. I also believe that it has been studied within the HL7 standard, in which for Acts (expanding it to potential other acts, however, if we look carefully all HL7 acts are speech acts because they are communicated between HC professionals) the illocutionary aspects are modelled carefully as request, promise and event. Validation is an interesting addition, which would require more attention. Currently the Care Provision model is becoming more explicit on care planning, for which your comments will be a good contribution. Again, the way of modeling care with the RIM is flexible and allows implementation in the EHR and in messages. Distinction between the two does not really exist from the point of speech acts, there is a messenger system, which can be the language, a letter, a system, or elektronic exchange between system. However, of course this only works if the semantics are tackled, so the propositional part of speech acts needs to be tackles, which has been proven to work with vocubulary etc. Withing the IT solutions the idea of the archetypes is perfectly capable of making explicit what needs to be contended. Yes, difference between diagnostic and therapeutic is important for me too: first describes the patient (thruh the eyes of the professional) and second describes the professional (from prof. point of view). I really would ask the OpenEHR community to adapt the HL7 RIM models for describing the propositional content and the UML activity diagrams and sequence diagrams for the illocutionary aspects of Acts. This is an established model that does tackle many of the issues raised. If at implementation level particular attributes or mechanics of these models do not work, they can be adjusted or constrained. The advantage is obvious, we can work out common illocutionary expressions (placing orders with their dynamics does not differ for a battery of lab tests in an laborder , or a set of vital sign observations ordered by a physician to the nurse, or the request of a nurse to a physician to check a patient who's condition deteriorated. The principles of request, promise, event and validation hold for these examples. The content can be archetyped / templated to assure broad understanding by clinicians regardless the technical solution to support them in speech acts. William Goossen --- ## Post #9 by @williamtfgoossen In een bericht met de datum 7-9-2005 8:27:14 West-Europa (zomertijd), schrijft gfrer@luna.nl: > William, > > The difference is that in CEN it pertains to an archetype > And in HL7 to a much more molecular/atomic construct. > > Gerard Yes, but in HL7 the same ideas work for the CMETS / archetypes / Templates in such a sense that we talk about groupings of observations or groupings of acts (batteries for example). William --- ## Post #10 by @system Dear all, Some personal thoughts about the scope of CEN/tc251 documents plus extracts and HL7v3 messages. And the basic set of 'ancestor archetypes' that we need for the EHR. The EHR is the place where the healthcare provider documents: - the data obtained like: letters received, orders received - the data obtained via anamnesis, personal observations, test results - the thoughts about it: the evaluation of the data obtained, the production of the professional opinion - the resulting action like a plan - the optional resulting action like an intervention - the optional resulting action like an order - the evaluation of the plan Any archetype (e.g. medication: drug name, dossage, amount, usage, etc) can occur in all 7 bullit points. In En13606 each of these 7 points provide the context for 'medication'. It is not an attribute in the part 1 Document model, or part the Archetype model that will provide the context information. In EHRcom it has to be a special 'ancestor' archetype that provides the intended context. This is they way in which EHRcom provides the same function as the Mood code in HL7v3. Again EN13606 is about the documentation of that what happened. E.g. it documents that an order for medication is given. The EHRextract might contain this documented fact. The EN13606 will not provide mechanisms for the 'transactional' concepts that one needs to transmit the medication order (prescription). The EN13606 is not a substitute for HL7 v3 messages that are used to transmit a medication order. The CEN/tc251 HISA norm might provide the definition of this type of function. The state machine involved will have to be aligned with HL7 are the plans as far as I can see. But this is NOT part of the EN13606 EHRcom norm. The preceding paragraph indicates the distinction between HL7 v3 messages and EHR documents and EHR extracts. The scope of the EN13606 is substantially different from that of HL7. Not withstanding this difference, both HL7 v3 messages and EHR documents or extracts can/should contain the same clinical and non-clinical archetypes/templates. In to few places this essential distinction between EHRcom and HL7v3 messages is described. In my view CEN/tc251 and HL7v3 are complementary and not in competition. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #11 by @Sam 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 > > -- -- > > Gerard Freriks, arts > > Huigsloterdijk 378 > > 2158 LR Buitenkaag > > The Netherlands > > T: +31 252 544896 > > M: +31 654 792800 > > > > 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 - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #12 by @Sam Jan This is exactly as the Instruction class is designed - if you have a look on the Ocean website at the medication archetype - you will see that it has a set of pathway steps such as these. I have asked Tom to provide the latest paper on Instruction to get this discussion moving further. Sam Jan Ravet wrote: > Ok, > > Do we also need to "grade" the degree of execution for "orders"? > > If I want the patient to take a short course of antibiotics: > I could: a. write a manual prescription > b. make a note in EHR to that effect > OR > use my computer system to: print the prescription > record details > As a general practitioner, my remit is normally served by the further actions of: > signing the prescription > giving it to the patient. > > We could also consider recording, somewhere along the line: > when was the prescription given to the pharmacist > when it was dispensed, ready for collection > who the dispensed product was given to (patient or "agent") > and > when the patient started treatment > when they stopped, (resumed, started again...) > (why they stopped, resumed...) > how many tablets were left after the patient stopped taking the tablets > and maybe even > disposal of those tablets. > > I guess most of those are implemented in relation to narcotics, in most countries. > > I would humbly submit that Completion of the order is not a simple Boolean. For each of the above, a truly detailed record would retain: date, time, identity of the agent completing that step, identity of the agent recording the step, and possibly a text field to record any further ambiguity not originally compassed in the definition, such as the patient vomiting at some undefined interval after oral administration. > > Jan Ravet > Augusta > West Australia > > > **From:** [Gerard Freriks](mailto:gfrer@luna.nl) > > **To:** [Williamtfgoossen@cs.com](mailto:Williamtfgoossen@cs.com) > > **Cc:** [openehr-clinical@openehr.org](mailto:openehr-clinical@openehr.org) ; [d.kalra@chime.ucl.ac.uk](mailto:d.kalra@chime.ucl.ac.uk) ; [thomas.beale@oceaninformatics.biz](mailto:thomas.beale@oceaninformatics.biz) > > **Sent:** Wednesday, September 07, 2005 6:12 AM > > **Subject:** Re: Antw: Re: 'Actionability' of orders > > > > 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 > > > > -- -- > > > > Gerard Freriks, arts > > > > Huigsloterdijk 378 > > > > 2158 LR Buitenkaag > > > > The Netherlands > > > > T: +31 252 544896 > > > > M: +31 654 792800 > > > > > > > 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 - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #13 by @Sam William and Hubert Thank you for this discerning discussion. As a clinician I have been working to resolve the many issues around workflow in the shared EHR environment. Sistine Barreto and Eric Browne here in Australia have been studying this area. Thomas Beale has pulled this together for the openEHR: > "The speech-act theory on which HL7 is based is interesting, but it is questionable as to whether it is a good basis for modelling recorded data in an information system. The reason for scepticism is that once information structures (very discrete) are tangled with linguistics (very slippery), the semantics of the information is obscured with largely irrelevant linguistic details. The intention of the mood code is to replicate the speech act mood of interlocutors (ultimately humans, mediated via systems, such as a pathology result system and a hospital EMR) in a 'conversation' that supposedly takes place about an observation, an order, an appointment etc. In such conversations between humans, there may be nearly infinite shades of tone and voice, and hence intention and commitment. However information systems cannot easily deal with so many shades of meaning particularly to do with future "intention". And most likely they don't need to. Usually, the need is for something to be actioned or not. The problem with mood codes comes down to this: they are an attempt to mark every item of information with the mood of the speech act which corresponds to the item. Even assuming that there always are such speech acts (there may not be, e.g. communication between two software packages), this means that we are forced to mark each item with possibly a very subtly different marker from every other item. Consider the shades of commitment: "intent", "promise", "proposal". Which one is it in any circumstance? In HL7, you have to decide at message design time. Originally there were only about 6 mood codes. Now there are 13. It may keep growing. None of the mood codes are of any use in the EHR, and I would argue, they are of little use in messages." The Instruction and Act classes in openEHR are the result of this work and have had a long gestation including some PhDs! We have also linked the pathway steps in an instruction (which may involve communication) with the fundamental machine states in a standard workflow engine. This design approach, which I am sure Tom will want to talk about, aims to ensure that the machine ,as well as the person, can discern what is going on (to the extent that it is required to support workflow or decision support). It is also clear that for safety the state in disconnected systems may be set differently from connected systems for the same step. For example, in community health a medication order may be set to an active state when prescribed (as the dispensing and administration events will not be recorded), where as it is still 'initial' (prior to actioning) in a connected inpatient environment (where the first administration record may set it to active. The sort of 'promised', 'proposed' and other moods can be set in the archetype if appropriate for that sort of activity. Cheers, Sam --- ## Post #14 by @system 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 -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #15 by @Bernie_Cohen Surely the issue here is not merely that of the \(binary?\) nature of a Speech Act, but the significance of that act to the enterprise within which it occurs\. Thus even a delivery 'for information only' might invoke some action on the part of the receiver, even if it is only the obligation to record its arrival, e\.g\. for audit purposes\. What is missing here are definitions of the protocols governing the performance of these acts by the enterprise's actors\. This 'deontic ontology' would permit the parties suitably to label each transaction and to relate those labels to the appropriate protocols, which would indicate the appropriate actions and enable the identification of, and recovery from, transmission and other errors\. Formal languages, such as LOTOS etc\., for defining such protocols hav ebeen around for years, particularly in the telecoms industry\. I suggest that you investigate the inclusion of a suitable metalanguage\. Bernie > Date: Wed, 07 Sep 2005 05:57:29 \+0930 > From: Sam Heard <sam\.heard@oceaninformatics\.biz> > Reply\-To: openehr\-clinical@openehr\.org > To: Gerard Freriks <gfrer@luna\.nl> > Cc: Dipak Kalra <d\.kalra@chime\.ucl\.ac\.uk>,      Thomas Beale <thomas\.beale@oceaninformatics\.biz>,      openEHR\-Clinical <openEHR\-Clinical@openehr\.org> --- ## Post #16 by @thomas.beale Sam Heard wrote: > Gerard Freriks wrote: > > > Hi, > > > > Reading an HL7 list. > > > > To me it seems there is exchange of the same data for two reasons. > > 1- an order, an instruction, an advice, a professional opinion, a letter, a lab result, itself, etc > > 2- the documentation of , the provision of information about, the order, the instruction, the advise, the opinion,the letter, the lab result, etc. > > > > Eg: the prescription on paper handed to the patient, the prescription electronically that is sent and serves as a kind of trigger event to make acts happen at the receiver side. > > And the documentation of acts in a system about the real world. > > > > What they have noticed is one of the fundamental criticisms on the RIM by the philosophical ontologists. > > > > In CEN it is simple we deal only with the EHR and considers the EHR a documentation device that deals with reason two only: documentation of what has happened. > > A lab test that is sent to an EHR system as data (information about the patient) is received and stored in the in-tray of the system. > > The physician reads the data and accepts it to the healthcare record at that moment he documents the reception of the lab results and make them part of the EHR. Then he is able to formulate a comment about them or act up on them. The comments or the actions will be documented again in the EHR. > > > > In CEN we deal with the EHRextract for exchange only. The extract is an abstract of that what has been documented. > > > > Question: Is data that is not yet documented part of the extract? > > If so. How is that indicated? > > If not what should we do? > > I think it should not, because the EHR is there to document what has happened in the view of the healthcare provider. > > Orders, instruction, letters them selves are outside of the scope of the EHR. I don't agree. I think that while this is what most extracts will be about, this is not in principle true. The Extract is capable of sending any piece of an EHR. The requested piece (e.g. 'everything to do with a cystic fibrosis patient's care for the last 2 years') could easily have Observations, Evaluations (i.e. any kind of opinions, including diagnoses, risk analyses, plans, goals etc), Instructions (and a CF patient will have a lot of those), and Acts (records of actions taken due to Instructions). THere is no reason not to be able to transport this kind of information in the Extract. The openEHR (and CEN) approach is simple. The information contains the "triggers"; you send the information to the right person/place and it gets acted on. Just like writing a letter: you put a stamp and address on the front, and you drop it in teh post box. You don't have to ring up the post office to ask them to send the letter; they already know what to do. If you write in that letter to your aunt that you would like some dried flowers from her garden to give to your daughter on her birthday, your aunt knows what to do, once she has read the letter, and barring difficulties, she does it. If she fails, she writes back and tells you she cannot. If she has fallen down teh stairs and is in hospital, someone from there or your family will ring you. Personally I do not believe the obsession with "trigger events" is meaningful in health information. "Triggers" are part of protocol design; protocols are for sending information, and should be kept separate from the requests/replies of the information. So, like the post office example, the protocol of how mail is sent around the world is a 'post-office protocol' which you, the letter writer know nothing about. You just know about the request you made to your aunt, and her reply. > > I think that next to the EHR extract we need something that indicates that it is not an extract of what is documented but something that is an order, instruction, advice, a letter, a lab result, that is data to the receiver until he documents the reception and accepts it to his record system. > > I prefer a new construct that carries the notion that it is a trigger. In an openEHR environment, the receiver and sender systems will both understand the order, since it will be based on an appropriate, shared archetype of an Instruction (e.g. an order for a drug), and it will be at the "prescribed" step (prior to the "dispensing" step). What is _not_ in the Instruction is the information that some particular pharmacy X is being asked to dispense the drug. But consider what normally happens: a patient presents a printed prescrption to the pharmacist and recieves a package in return. In e-health, the pharmacy receives a request for a drug; the request itself does not need to indicate which pharmacy is to dispense the drug; only the envelope in which the request is carried (like the postal example above). In other words, the pharmacy processes all requests for drugs (assuming apporpriate details included in the message) directed to it, rather than some other pharmacy. How does this get done? Consider the following possibilities: - the pharmacy acts like a provider, and is able to see the patient EHR. In this case, all the data required for dispensing will be in the Instruction in patient B's record. The trigger for actually dispensing will be a notification from the physician's sytem to the pharmacy system asking for Instruction 0494585 to be acted upon. - the pharmacy is just a service, and not privy to health records of patients. It therefore has no reason or capability to receive or view pieces of an EHR. In this case it needs to be sent message which acts as a notification, and carries the content. Such a message can be constructed from the relevant Instruction. Now, in the second case, the easiest solution in principle is to generate a copy of the appropriate part of the Instruction, and send it off to the pharmacy by some communication servce, such as a call to their webservice. In a messaging environment, one might assume an HL7 or EDI message. Generating an appropriate HL7v2 message would not be hard. But for v3, the situation may be more problematic: v3 RMIMs contain predefined models of much clinical content (replicating clinical models and information models of EHR content), mixed in with the schema representing the message; it may or may not be easy to generate the appropriate message, since there are many attributes which are required, which are not present in the EHR. How this can be solved will remain to be seen. > > Since the content of this new construct will be the same information as an EHR-extract I foresee an envelope for the EHR indicating that it is an extract of a document and an envelope indicating that it is a trigger. This is the solution-in-principle above; it still requires sensible service models for both sender and receiver; these service models encapsulate the protocols for sending and receiving, acknowledgement and all such things. > > The signature placed on the extract of the document indicates: I sign this and take responsibility for the content of the extract. > > The signature placed on the trigger indicates: I order you, I instruct you to do something and I take responsibility for that order, instruction. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #17 by @thomas.beale Hubert Mensch wrote: > Gérard, > > May I propose a contribution on the the question you pose ? > > 1 - Concerning the cooperation between actors and roles > The two reasons you mention make me think of the Searle's speech acts, amongst other developped afterwards by Vinograd in his "conversation for action". > i) - reason one : "illocutionnary" act which can be : > -- a request for an action performing (order, instruction, letter where one can find a request, ...) expressed by a requester to an offerer and which implies an answer from the offerer : accept (and then the offerer commit to do what is requested), amend, refuse. > -- a commitment for an action performing expressed by the offerer. In practice and depending on the cooperation rules, the commitment is sanctionned by an appointment. The appointment can be in the letter ... > -- a report on the the action performing expressed by the offerer to the requester (professionnal opinion or advice following a request, lab result, ...) > -- a validation of the report (or of the action performing ?) by the requester all of this is part of the 'protocol' of communication > ii) - reason two : "propositional" act which gives the content of the speech act : > -- professional content for a request, with reason, target, condition of the patients influencing the performing of the requested action > -- professional content for the commitment > -- for the report. it is interesting to distinguish there the differences of the professional content between a diagnostic and a terapeuthic action. personally, I find it perverse to call information "acts" when it is clearly information! But in any case, this is the content of the request, sent under the control of the protocol which is implemented in the relevant services. > The conversation for action is one of the components of the cooperation. Another one is the coodination of the care plan performing, when for instance an actor/role notifies the following one that the action he was responsible for is performed (or is not performed). May-be other component exists ? in the new openEHR Instruction, this is shown by an Act (= 'observation of an act having been performed') instance being committed to the record; the Act indicates which Instruction activity it was based on, who performed it, when, and what differences there were with respect to the specification of the Act (the 'activity' as we call it in openEHR). THere is an overall Instruction_execution which tracks all happenings due to an Instruction. > Reports and notifications are different : report is sent to the requester within the conversation for action, and notification is sent to the following actors/roles within the workflow coordination, may-be with an another professional content. The information system is intended to support this cooperation messaging. If the executor of some act, e.g. a drug administration in a hospital, creates the appropriate Act instance in the EHR, any other physicians (e.g. the GP and specialist) concerned with that patient and the problem in question, can be notified by their system that a new Act has been committed. > 2 - Concerning the fact that the EHR is the support of cooperation messaging. > In the schema you describe, the EHR is the obliged "documentation device" (or I could say messaging device) between HCPs to communicate within the "conversation for action" or for the coodination. One can imagine that there are 3 dossier elements related to the same action performing > - in the performer dossier > - in the cooperation system > - in the requester dossier > > The utilisation of these "versions" inof the same act the care process should be studied. I agree. This is more or less what we are trying to do with Instruction, Act, Instruction_execution and so on - clarify this threads of information and activity. - thomas - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #18 by @thomas.beale Williamtfgoossen@cs\.com wrote: > If an EHR can only store what has already happened, so the past, it becomes useless for supporting clinical practice\. Well, certainly the openEHR idea of an EHR includes all past \(observational\), opinion/decisional, and future \(instructional\) information\. What other EHRs have in them may vary\. The EHR Extract is just a copy of some parts of the EHR \(\+ appropriate demographic information\), suitably packaged for sending\. > 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\. the mood codes should be artifacts of conversations between systems \(this is their speech act basis\)\. Unfortunately they are mixed up in an information model of content, i\.e\. the protocol definition of communications is the same as the definition of the information being sent\. And this is further confused by whether the protocol\-related parts of HL7 relate to the interaction of two systems processing messages, or the communications between two health professionals\. > 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\. I think logically there is a need for a "notification"; however, remember that in any protocol, the sending of a message containing a request for a drug \(say\) to a receiver which is capable of dispensing drugs, is normally taken as being the notification\. You don't send a request for a drug X to pharmacy A if you really want pharmacy B to dispense it\. Clearly there are more elements to the protocol than just this\. The key is not to confuse the protocol design with the design of the information, nor with who the interlocutors are for any given level of 'message'\. \- thomas beale --- ## Post #19 by @system Thomas, > I don't agree. We agree more than you think. > In an openEHR environment, the receiver and sender systems will both understand the order, since it will be based on an appropriate, shared archetype of an Instruction (e.g. an order for a drug), You write: "since it will be based on the shared archetype of an instruction". This is correct: semantic notions are expressed as archetypes. But what is the EHR? Answer: the record that documents what the healthcare provider received as data, his thoughts, his professional opinion, the plan, the orders, and what he wants exchanges with others. The EHR is a document that documents. Then the EHR is the record of what happened. In that context it records that an order was given to dispense medication. But this is not the same as the medication order itself. When this information is sent to the pharmacist he will interpret it as an instruction for him to dispense. When the same piece of information is sent to the patient it means that this is the record of what he was advised to do, or is the meaning that this is an prescription he must bring to the pharmacist, In other words. An EHR with a record of something (e.g. an instruction) needs something extra that indicates what the purpose is. A record of an order is not the same as the order itself. My question was: how will OpenEHR (EHRcom) indicate what the purpose of the order is? Will we indicate this inside the EHRextract? Will we indicate this in the envelope? Will we leave this completely to the HL7 machinery of messages. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #20 by @thomas.beale Gerard Freriks wrote: > Thomas, > >> I don't agree\. > > We agree more than you think\. > >> In an openEHR environment, the receiver and sender systems will both understand the order, since it will be based on an appropriate, shared archetype of an Instruction \(e\.g\. an order for a drug\), > > You write: "since it will be based on the shared archetype of an instruction"\. > > This is correct: semantic notions are expressed as archetypes\. > But what is the EHR? Answer: the record that documents what the healthcare provider received as data, his thoughts, his professional opinion, the plan, the orders, and what he wants exchanges with others\. > The EHR is a document that documents\. > Then the EHR is the record of what happened\. > In that context it records that an order was given to dispense medication\. > But this is not the same as the medication order itself\. In openEHR, we side\-step all such problems and keep it simple\. An instance of an Instruction documents roughly what might be in a prescription \- the description of the drug or therapy\(ies\), the administration timing, route, etc, procedure if relevant, and other activities like monitoring, conditions for suspending etc\. This is enacted by human or computer workflow executors\. Each thing they do they record using an instance of Act or Instruction\_act \(new Entry subtypes in openEHR\)\. It does not have to be part of the data who is being asked to enact it \(but it can be \- done with particpations\); they will be asked via some appropriate notification \(e\.g\. the patient coming to their hospital acts as a notification\)\. They will obtain permission to see the relevant part of the EHR, and will start giving care, i\.e\. performing activities in the Instruction, which they will document with Act\_instructions \(Acts are used to document activities undertaken but not 'prescribed', e\.g\. ad hoc self\-administration by patient\)\. These Entry types by the way indicate the current state \(in the state machine sense\) of the Instruction \(e\.g\. "active", "suspended" etc\)\. So we don't record 'orders' as such; we record what is to be done, and usually by whom\. Then, notifications \(including humans presenting themselves\) cause things to happen, and those happenings are documented\. > When this information is sent to the pharmacist he will interpret it as an instruction for him to dispense\. > When the same piece of information is sent to the patient it means that this is the record of what he was advised to do, or is the meaning that this is an prescription he must bring to the pharmacist, > > In other words\. > An EHR with a record of something \(e\.g\. an instruction\) needs something extra that indicates what the purpose is\. > A record of an order is not the same as the order itself\. > > My question was: how will OpenEHR \(EHRcom\) indicate what the purpose of the order is? as you can see from above, we don't work this way\! > Will we indicate this inside the EHRextract? > Will we indicate this in the envelope? > Will we leave this completely to the HL7 machinery of messages\. > > Gerard \- thomas --- ## Post #21 by @thomas.beale Bernie Cohen wrote: > Surely the issue here is not merely that of the \(binary?\) nature of a > Speech Act, but the significance of that act to the enterprise within > which it occurs\. > Thus even a delivery 'for information only' might invoke some action on > the part of the receiver, even if it is only the obligation to record its > arrival, e\.g\. for audit purposes\. > What is missing here are definitions of the protocols governing the > performance of these acts by the enterprise's actors\. This 'deontic > ontology' would permit the parties suitably to label each transaction and > to relate those labels to the appropriate protocols, which would indicate > the appropriate actions and enable the identification of, and recovery > from, transmission and other errors\. > Formal languages, such as LOTOS etc\., for defining such protocols hav > ebeen around for years, particularly in the telecoms industry\. I suggest > that you investigate the inclusion of a suitable metalanguage\. > Bernie > I missed this post this morning, but it hits the nail right on the head\. The problem to be solved is protocols\. They can be defined in the form of: \- protocol definitions, as in the telecom industry, to which Bernie refers above \- in terms of service interfaces, which can be designed to implement intended protocols of communication They can be implemented in terms of: \- in message definitions, where different parts of the message, and different message types explicitly implement a protocol definition\. \- in generic distributed object technology, e\.g\. RPC, Corba etc, where the messages are defined and created by magical tools which read the input service interface definitions to determine what the packets must be \- in generic messaging technology\. Personally, I believe we should be using service models and generic distributed technology\. \- thomas beale --- ## Post #22 by @thomas.beale Gerard Freriks wrote: > 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\. I forgot to mention that the Instruction proposal can be viewed at http://my.openehr.org/wsvn/specification/TRUNK/publishing/proposals/Instruction.pdf?op=file&rev=0&sc=0 This is a very draft version, and is also somewhat out of date\. But you will get the idea\. Comments welcome\. \- thomas beale --- ## Post #23 by @thomas.beale Williamtfgoossen@cs\.com wrote: > In een bericht met de datum 7\-9\-2005 0:13:04 West\-Europa \(zomertijd\), schrijft gfrer@luna\.nl: > >> \- execution of a procedure\. >> >> And next we need the machinery to indicate the cancellation of these\. > > Yes, this is exactly as the two attributes in HL7 v3 RIM Acts: > > moodcode to indicate the plan versus execution \(INT versus EVN\) > statuscode to determine whether this Act is active versus cancelled or on hold or similar\. actually, I think what is really needed is a state machine for the state of an Instruction\. We have defined just such a state machine in the proposal \(see http://my.openehr.org/wsvn/specification/TRUNK/publishing/proposals/Instruction.pdf?op=file&rev=0&sc=0). Any Instruction can be moved into one of the states by appropriate acts or conditions becoming true, which can be defined in the archetype\. The moodcode of HL7 differentiates between Instruction and Instruction\_act \(ie\. the execution of some part of an Instruction\); the statuscode differentiates among teh various states possible for the Instruction when it is executed\. What is missing in the HL7 approach is a way to define Instructions, including the mapping of real\-world events and conditions to state\-machine changes, in something like an archetype \- in a clinically comprehensible way\. What is most problematic is that some parts of such semantics \_are\_ being defined in RMIMs; the problem with this is a\) that these kinds of definition originate in EHRs, not in the messages that carry the data from place to place, and b\) such definitions need to be cleanly separeted from the machinery of messaging, and all the associated attributes\. How HL7v3 will carry such information created in EHRs and based on archetypes will be very interesting to see indeed\. \- thomas beale --- ## Post #24 by @thomas.beale Hi William, we would have preferred to be able to do this. But as we (and many others) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions. Some of the problems (relating to just this topic) include: - the lack of clarity over whether the RIM is an ontology of information or an ontology of reality (in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?). The HL7 documentation contains numerous conflicting statements about this. One practical consequence is that modellers of RMIMs etc are unclear about what attributes are needed to ensure that some object is a clear documentation of something (in which case it is not an Act, it is a documentation of an Act) or somehow a model of that thing actually occurring in time. - the RIM doesn't clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a) specifications of future acts and b) their execution. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows. - I agree that the dynamics of request/reply etc should be the same for most things, or at least a generic protocol definition should be able to encompass these ideas. The problem with the RIM is that it mixes such protocol notions with content notions. And to make things more difficult, there are many attributes in Act and Act-relationship which don't make sense in those classes, only in instances of particular subclasses - these attributes are simply there so they can be removed during RMIM development. This makes it hard to use the model in normal object-oriented development. Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #25 by @williamtfgoossen In een bericht met de datum 12-9-2005 3:41:30 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: > Hi William, > > we would have preferred to be able to do this. But as we (and many others) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions. Some of the problems (relating to just this topic) include: Hello Thomas, I agree with your points below (your comments TB, mine WG), this is still an issue to be worked out. Part of the solution of this however is dealt with on the D-MIM level. Perhaps you have not looked at the care provision D-MIM recently. It does include more detail for the clinical stuff that goes in the documentation. Of course the D-MIM has both the ontologies below. However, at R-MIM specification it is possible to distinghuish between them. In particular the careplan section does describe the information about what to document. It are mostly classes in intent mood: so telling what eventually to do. The other example is the event message in wich the actual observations, including time, value etc. are expressed. TB: t > he lack of clarity over whether the RIM is an ontology of information or an ontology of reality (in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?). The HL7 documentation contains numerous conflicting statements about this. WG: I have never gone through all of these detials at this stage, merely because I work through the modelling use case by use case and find solution per needs basis. Until now we have been able to include a lot of stuff that clinicians want. TB: One practical consequence is that modellers of RMIMs etc are unclear about what attributes are needed to ensure that some object is a clear documentation > of something (in which case it is not an Act, it is a documentation of an Act) or somehow a model of that thing actually occurring in time. WG: Yes, you need to make this distinction in a late stage by pulling out the right mood code out and making the constraint explicit. TB: t > he RIM doesn't clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a) specifications of future acts and b) their execution. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows. WG: Well, this is not completely through. Yes for the RIM, no for the HL7 standard. Basically we deal with two key features of clinical information: the what = the structures (data, documentation, values) and the dynamics. The RIM with the D-MIM and R-MIMs helps to model structure. The UML notations as sequence diagrams and activity diagrams help to model the dynamics. It is very much feasible to analyse these seperately, model each in appropriate tools and finally integrate at higher model level and system/message level. TB: I > agree that the dynamics of request/reply etc should be the same for most things, or at least a generic protocol definition should be able to encompass these ideas. WG: Yes, indeed I agree. TB: The problem with the RIM is that it mixes such protocol notions with content notions. WG: Well yes the RIM does, but conceive the RIM as your big box with virtual lego bricks, and the D-MIM as the space shuttle you built from it (without missing the last 5 atomic bricks, due to virtual unendlessness). From this analogy, the D-MIM can serve this purpose because both the protocol or guideline can be made explicit and linked to one single act / observation, or to a complex set of this, compared to the content itself as unrolled in the different observation classes needed. TB: And to make things more difficult, there are many attributes in Act and > Act-relationship which don't make sense in those classes, only in instances of particular subclasses - these attributes are simply there so they can be removed during RMIM development. This makes it hard to use the model in normal object-oriented development. WG: Well, we do have experiences now with three vendors that built their record systems based on the Care Provision D-MIM (as mimicked with some adaptations), and hundreds of R-MIM / CMET / GPIC / archetype / template examples in a relational database. The Care Provision Model serves as the CEN 13606 RIM, but then in proper HL7 v3 modelling, allowing entries and groupings of clinical documentation. The R-MIM / CMET / GPIC / archetype / template examples just fit in the slots in the XML message (CDA level 3 somewhere halfway), and is the specification for system development (storage, business logics like calculations, conditional execution, user interface). WG I believe it has the strength of your excellent new design to distinghuish between the systems operations and the expression of the clinical content, and the strength of the HL7 standard to guarantee semantic interoperability between more parties than 1 to 1, which is in my opinion the key flaw of the CEN 13606 and OpenEHR approach: every party willing to exchange documents / information must seek agreements with the receiving parties again on which archetypes to use / develop, so an unendless standardisation effort for very small content items. The formula n x n-1^2 tells me that the OpenEHR way stops to be feasible after about 5-7 parties step in. due to the many to many to many to many to many to many to many relationships on the archetype collections to agree upon with party 1, party 2, party 3 party 4, party 5, party 6. TB: > Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future. WG: I look forward to this, however, I would like to see the results of the study based on the D-MIMs that are made for purpose, where the RIM is more the collection of stuff to built with. I mean, if compared to the OpenEHR, the D-MIM is the part in which clinical content is expressed and dealt with. My approach and study work is: 1. make explicit the clinicians knowledge, information and processes, (so roughly the semantics) 2. model this appropriately using UML artefacts (where the RIM is a specification of UML class diagrams), and of course: archetypes / templates / GPICS / R-MIMs / CMETs to express the real details clinicians look for and want to control with respect to content, terminology, coding. (roughly the interoperability based on standards) 3. implement the clinical material in technology, where it does not matter in principle if the technology is messages only, is a (distributed) database only, or if it is multiple databases with multiple messaging from one to another. We see different technical architectures dealing appropriately with the same clinical content. (so roughly the systems being able to semantically interoperate) Of course each kind of technical representation would require constraining, and the examples you give above explain very well why this is necessary. A message via R-MIM to XML schema etc. needs a different constraining compared to a record system with database, logics and user interface, each adding to the requirements. And yes the RIM is probably to rich for the latter, where only a few attributes are necessary. OK, then from the same D-MIM, you constrain messages via adding/working out some peculiar unrolling of attributes and content, and for EHR by completely removing the rubbish you don't need. I still think than that from the clinicians point of view it currently is better to start with the richer model, allowing both technical workouts and constrain from the rich model to the 'poorer' stuff (poorer here as sufficient for the function). From R-MIM to OpenEHR archetype works well, and is about 1 % of initial investment time with the benefit of well expressed clinical materials (70% of work), message standard with unique coding (20% of work), tools to 'XMLise' it (9% of work), and tools to 'archetypise' it (1 % of work). (Estimates from about 90 archetypes expressed in R-MIM). You could say: go from the 70 to the 1 % and save 19,... but if you need to work backwards from archetype to R-MIM / message, you probably would need to put in much much more effort. > - thomas beale William Goossen --- ## Post #26 by @thomas.beale Williamtfgoossen@cs\.com wrote: > In een bericht met de datum 12\-9\-2005 3:41:30 West\-Europa \(zomertijd\), schrijft Thomas\.Beale@OceanInformatics\.biz: > >> Hi William, >> >> we would have preferred to be able to do this\. But as we \(and many others\) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions\. Some of the problems \(relating to just this topic\) include: > > Hello Thomas, > > I agree with your points below \(your comments TB, mine WG\), this is still an issue to be worked out\. Part of the solution of this however is dealt with on the D\-MIM level\. Perhaps you have not looked at the care provision D\-MIM recently\. It does include more detail for the clinical stuff that goes in the documentation\. Of course the D\-MIM has both the ontologies below\. However, at R\-MIM specification it is possible to distinghuish between them\. In particular the careplan section does describe the information about what to document\. It are mostly classes in intent mood: so telling what eventually to do\. The other example is the event message in wich the actual observations, including time, value etc\. are expressed\. > > TB: > t > >> he lack of clarity over whether the RIM is an ontology of information or an ontology of reality \(in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?\)\. The HL7 documentation contains numerous conflicting statements about this\. > > WG: I have never gone through all of these detials at this stage, merely because I work through the modelling use case by use case and find solution per needs basis\. Until now we have been able to include a lot of stuff that clinicians want\. Hi William, my concern here is that while you can "have what you want" by deleting inconvenient attributes where you feel like it, cloning others, renaming and so on, you are always in the business of building a new schema while doing this\. Every such exercise is a new schema\. This is not a good basis for building generic tools \- neither to handle the clinical models \(which are effectively embedded in the RMIM level\) nor the information\. How can one one piece of software for 2 messages when the Observation class from the RIM has been mutated in two different ways in each message? It might still be called Observation, but it won't be the same class in each\. Message definitions just are not the right place to be doing clinical modelling\. > TB: > t > >> he RIM doesn't clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a\) specifications of future acts and b\) their execution\. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows\. > > WG: Well, this is not completely through\. Yes for the RIM, no for the HL7 standard\. Basically we deal with two key features of clinical information: the what = the structures \(data, documentation, values\) and the dynamics\. The RIM with the D\-MIM and R\-MIMs helps to model structure\. The UML notations as sequence diagrams and activity diagrams help to model the dynamics\. It is very much feasible to analyse these seperately, model each in appropriate tools and finally integrate at higher model level and system/message level\. I will be very interested to see how this all gets re\-integrated smoothly\.\.\. > TB: The problem with the RIM is that it mixes such protocol notions with content notions\. > > WG: Well yes the RIM does, but conceive the RIM as your big box with virtual lego bricks, and the D\-MIM as the space shuttle you built from it \(without missing the last 5 atomic bricks, due to virtual unendlessness\)\. From this analogy, the D\-MIM can serve this purpose because both the protocol or guideline can be made explicit and linked to one single act / observation, or to a complex set of this, compared to the content itself as unrolled in the different observation classes needed\. I should have been clearer here \- I meant 'protocol' in the IT communications sense \(as in http, ftp etc\) not in the medical sense\. > TB: And to make things more difficult, there are many attributes in Act and > >> Act\-relationship which don't make sense in those classes, only in instances of particular subclasses \- these attributes are simply there so they can be removed during RMIM development\. This makes it hard to use the model in normal object\-oriented development\. > > WG: Well, we do have experiences now with three vendors that built their record systems based on the Care Provision D\-MIM \(as mimicked with some adaptations\), and hundreds of R\-MIM / CMET / GPIC / archetype / template examples in a relational database\. The Care Provision Model serves as the CEN 13606 RIM, but then in proper HL7 v3 modelling, allowing entries and groupings of clinical documentation\. The R\-MIM / CMET / GPIC / archetype / template examples just fit in the slots in the XML message \(CDA level 3 somewhere halfway\), and is the specification for system development \(storage, business logics like calculations, conditional execution, user interface\)\. > WG > I believe it has the strength of your excellent new design to distinghuish between the systems operations and the expression of the clinical content, and the strength of the HL7 standard to guarantee semantic interoperability between more parties than 1 to 1, which is in my opinion the key flaw of the CEN 13606 and OpenEHR approach: every party willing to exchange documents / information must seek agreements with the receiving parties again on which archetypes to use / develop, so an unendless standardisation effort for very small content items\. The formula n x n\-1^2 tells me that the OpenEHR way stops to be feasible after about 5\-7 parties step in\. due to the many to many to many to many to many to many to many relationships on the archetype collections to agree upon with party 1, party 2, party 3 party 4, party 5, party 6\. This a strange way to see things\. With the archetypes approach, there are agreements at local, regional and national \(maybe international\) levels\. Once they are agreed \(e\.g\. we have 60\+ national ones in Australia\) then there is no argument about 1:1 agreements\. In fact, I have never even heard anyone previously suggest that archetypes were about 1:1 negotiations\! Quite the opposite; they will be \(already are in some places\) quite centrally available\. The main advantage is that they are clear clinical models, independent of the details of messaging or other ways of communicating health information\. This is no different from groups of parties, jurisdictions etc agreeing on RMIMs or messages\. The problem with the latter is that they are agreeing on a new clinical model and a new schema every time\. There is no end to the new schemas\. Consider for example that a lab result could be sent from lab\->EHR system, copied from EHR system\->EHR system; stored in an EHR system; displayed on the screen; printed; and so on\. No matter how many such situations, the model of the result should only have to be defined once\. At the moment we can do this with archetypes & templates: define it all once and use it for everything\. Only one schema \(the reference model\)\. A messaging standard that would help would be one that allows this\. But HL7 forces users to define the clinical content of messages as part of their information schemas\. Not only that, but if you want to use some or all of the lab result model in question in a different RMIM, there is no guarantee that it will be the same as in the first one; nor that it can be a re\-usable component in general \(since there is only one level of reusability \- CMETs\)\. How can I use the same definition for a screen form? THere is a whole lot of message attributes I don't want, but which I am forced to have\. Now we have a world containing N HL7 variants of some kind of lab result \(each also a new data schema\), and an archetype of the same result, resting on a single base ontology containing logical concepts of Observation, Evaluation, History, data structures, data types and so on\. We can use this model to define EHR content, EHR Extracts, messages, any printed or display form \(with additional display information of course\)\. It is a single\-source semantic model\. And all the while we only have to work with one information schema\. And all of this misses a major point in the first place: the source of all health information is systems, not messages\. If it is systems, then the designers of the information are the clinical \(administrative, allied etc\) professionals using the systems\. > TB: > >> Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future\. > > WG: I look forward to this, however, I would like to see the results of the study based on the D\-MIMs that are made for purpose, where the RIM is more the collection of stuff to built with\. I mean, if compared to the OpenEHR, the D\-MIM is the part in which clinical content is expressed and dealt with\. I think what you are saying is almost that we should ignore the RIM, and just see the set of DMIMs as HL7s information reference model\. But we cannot get away from the fact that each RMIM, drawn from a DMIM creates a new schema, and is full of messaging attributes all over the place, and so on\. \(If I want to create an HL7 lab observation for microbiology result, I have to definine mood code on every node, since every node is an Act\.\.\.but common sense dictates that it is only one result; it is therefore in OBS mood\.\.\.there are 2 or 3 other mandatory Act attributes to which this also applies\.\)\. > My approach and study work is: 1\. make explicit the clinicians knowledge, information and processes, \(so roughly the semantics\) > 2\. model this appropriately using UML artefacts \(where the RIM is a specification of UML class diagrams\), and of course: archetypes / templates / GPICS / R\-MIMs / CMETs to express the real details clinicians look for and want to control with respect to content, terminology, coding\. \(roughly the interoperability based on standards\) well, maybe you know more than I do; I don't know of any easy integration of archetypes & templates and GPICS, RMIMs, CMETs etc\. We tried it once at an HL7 meeting a couple of years ago, and just got lost in the attributes\.\.\.I personally cannot see any obvious mapping\.\.\. > 3\. implement the clinical material in technology, where it does not matter in principle if the technology is messages only, is a \(distributed\) database only, or if it is multiple databases with multiple messaging from one to another\. We see different technical architectures dealing appropriately with the same clinical content\. \(so roughly the systems being able to semantically interoperate\) But this will be difficult, because each RMIM is a data schema as well\. > Of course each kind of technical representation would require constraining, and the examples you give above explain very well why this is necessary\. A message via R\-MIM to XML schema etc\. needs a different constraining compared to a record system with database, logics and user interface, each adding to the requirements\. so what you are saying here is that there are more constraints related to the technological deployment context of each message? > And yes the RIM is probably to rich for the latter, where only a few attributes are necessary\. OK, then from the same D\-MIM, you constrain messages via adding/working out some peculiar unrolling of attributes and content, and for EHR by completely removing the rubbish you don't need\. but this can never work for building re\-usable software that a\) wants to process the same clinical concept in different places \(e\.g\. in an EHR service, in a query server; in a message gateway; in a presentation manager\) and b\) wants to be able to process more than one kind of message\. There is an N x M space of deployment context x messages of software modules to build\.\.\. > I still think than that from the clinicians point of view it currently is better to start with the richer model, allowing both technical workouts and constrain from the rich model to the 'poorer' stuff \(poorer here as sufficient for the function\)\. but what is the logic of building clinical models of something starting from a model which is full of attributes which don't relate to most instances \(quite apart from the fact that this practice violates the basic OO premise of model extensibility\.\.\.\)? > From R\-MIM to OpenEHR archetype works well, and is about 1 % of initial investment time with the benefit of well expressed clinical materials \(70% of work\), I assume you are talking about a human rewriting process here\. There is no automatic transform that I know of\. So already you are talking about 1 message structure and 1 archetype, with no obvious strategy for automatic conversion by computers\.\.\. > message standard with unique coding \(20% of work\), tools to 'XMLise' it \(9% of work\), and tools to 'archetypise' it \(1 % of work\)\. \(Estimates from about 90 archetypes expressed in R\-MIM\)\. You could say: go from the 70 to the 1 % and save 19,\.\.\. but if you need to work backwards from archetype to R\-MIM / message, you probably would need to put in much much more effort\. yes, but there are serious questions of quality and fitness for purpose which I have raised above, not just how many hours of work are involved\.\.\. \- thomas --- ## Post #27 by @williamtfgoossen In een bericht met de datum 12-9-2005 9:47:26 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: Tom Beale wrote: > my concern here is that while you can "have what you want" by deleting > inconvenient attributes where you feel like it, cloning others, renaming > and so on, you are always in the business of building a new schema while > doing this. Every such exercise is a new schema. This is not a good > basis for building generic tools - neither to handle the clinical models > (which are effectively embedded in the RMIM level) nor the information. As answer to my point of using the Care Provision D-MIM to express clinical content. Here you have a point that changing the class names everytime, which I admit I am doing currently in the R-MIM / CMET / archetype / templates development, will not hold in the long run. For the time being it allows me to express / model what clinicians want. I will work however with Kai Heitmann to improve this approach so that against the HL7 v3 XML schema, a more pure archetype expression can be developed by means of keeping the proper class names and finding a solution for it via coding and using the attributes. I agree on the need of generic tools: so give me the tools that allows me to express the clinical content that can be exchanged between system in an international standardized matter. OpenEHR does not do this for me, HL7 v3 D-MIM does it for the time being. I wont to be independent of the technology, OpenEHR is not independent of technology, it forces to go in the --- ## Post #28 by @thomas.beale Williamtfgoossen@cs\.com wrote: > I agree on the need of generic tools: > > so give me the tools that allows me to express the clinical content that can be exchanged between system in an international standardized matter\. > OpenEHR does not do this for me, HL7 v3 D\-MIM does it for the time being\. > > I wont to be independent of the technology, OpenEHR is not independent of technology, it forces to go in the > Hi William, I'm not sure what is lacking in principle\. Obviously openEHR isn't 'finished', but then again, what is? Our archetype tools \(and coming template tools\) are being used internationally, are based on an open and completely generic \(i\.e\. not tied in any way to health, let alone EHRs or health messages\) formalism \(ADL\), have a fully defined object model \(the AOM\), which has an XML\-schema expression \(tool\-generated, coming soon\)\. I don't want to say this is the perfect solution, but I have to admit I cannot think of how to be any more independent of technology specifics\. The archetypes being built are based on core features of the openEHR reference model \(mostly Entry and data types level\)\. However, there is a new CEN standards work item called the Archetype Knowledge Framework which will standardise the "domain base concept model", which will be a sharable ontology on which to base archetypes\. We did try very hard to get HL7 in the past to see the need for this, but they have never been too interested in cooperating with other organisations\. In any case, there are no archetypes in HL7, so I don't suppose anyone sees the need for a base ontology on which to base them \(unless one is to claim the RIM, but then why bother making DIMs and RMIMs?\)\. Whether this will change in the future is hard to judge; there appears to be an internal conflict between HL7 templates and HL7 RMIMs; I don't know how this will be resolved\. Whether each HL7 RMIM is "internationally standarised" is open to debate\. Within HL7 this is presumably so\. Whether it represents what clinicians around the world think is a BP measurement, an Apgar result, a cardiology exam, a chemotherapy administration I don't know, but seems doubtful to me, since the modelling process and framework is just too problematic\. Could you indicate which HL7 RMIMs are internationally standardised models of their chosen clinical concepts and where they can be downloaded from? It would be very interesting for the openEHR community to review them\. \- thomas --- ## Post #29 by @system Thomas, When we agree that the scope of OpenEHR is to document the professional opinions and the facts on which these are based then: > An instance of an Instruction documents roughly what might be in a prescription But it is semantically NEVER the same. It is the documentation of the process that lead to a prescription. It is NOT a prescription. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #30 by @system Whay are the arguments for your preference for service models and generic distrinuted technology? Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #31 by @Jan_Ravet To some extent, this line is getting silly. As a humble country GP, my primary interest is in the data. Most of the clinical data I want externally are numeric rather than Boolean, although I also have use for data that might be more suited to my primitive idea of a neural network: The rash "conforms fairly strongly with my impression of" an urticarial rash... The opinions offered by other practitioners come into that category, as are the opinions which I expressed at previous encounters with this patient or clinical problem. However, all of this is fundamentally different from rocket science. Rocket science gives me the impression of being close to absolute. Maybe variations in weather will affect solutions close to the Earth, but the long stretches between planets, or between stars should be much more predictable than balls on a billiard table. In contrast, there are very few absolute parameters in the "science" of Medicine. While not nearly as chaotic as weather patterns that might be affected by the beat of a butterfly's wings, I want to be free to make my own assessment of the data I receive from other practitioners. Each datum I receive in that manner should be subjected to a degree of critical review. Looking at scaling on that "degree of crticial review" I expect IT analysts to want to differentiate as many states as possible, but I do not believe that we will reach a quantal level of granularity. I am prepared to give a high degree of credibility to the serum rhubarb. That is not to say that I would not expect some variation in the values reported by different laboratories on samples taken from the same patient and the same time, but I do expect the variations to be within the limits of error of the several different techniques that might be used to perform the assay. However, I do expect to see some difference in the "normal range" ascribed by each laboratory, and I also expect a greater degree of variation ( for "abnormal" results) in the "comment" line reported by each lab, and even each of the reviewing specialists within a given lab. That's with the relatively "hard" data provided by the lab. With radiology, I accept that the "report" is likely to be less black and white than the films, and that the report from the radiologist will vary from day to day, even if the same films are under review. So I can go down the list of specialist opinions right down to... well, there's no need to be rude about those specialities. However, in each case, I need to be able to overlay my judgment array which will include: the reproducibility of the observation: a. generally b. in the hands of the reporter the usefulness of the observation the quality of this reporter for this type of observation ... Yes, it would be lovely, eventually, to mimic this process using software. However, my impression over the last three decades is that attempts to do this have merit at an academic level, both as an excercise in their own right and as a means of helping to train the next generation of practitioners in ths process. The other aspect of "opinion"s is that they are evanescent. The patient's "admission diagnosis" may have a strong positive correlation with the "discharge diagnosis", but if we could claim identity between the two lists, there would be no need for tests after admission, no need for changes in management and certainly no need to record "opinions". On the contrary, the initial (working) diagnosis is likely to be of limited precision, and to be accompanied by a list of other options. The tests ordered at that stage are ordered in the hope of being able to either strengthen or weaken the relative rankings of the differential diagnosis. Similarly, the effect of various treatment options can help to effect changes in those rankings, as will the opinons, prejudices and expertise of the various practitioners invited to participate in the process. The point to be made at this stage is that the addition of just one more datum at this point may be enough to change content as well as ranking within the "patient status report". If this occurs, then we may find that the opinion expressed by the most prestigious and competent practitioner can be totally reversed within the span of the few seconds it takes for that datum to be perceived. This bears some similarity to the Humean dichotomy between deeds and moral issues. So, much as I appreciate and indeed give a fair amount of weight to the opinions offered to me by others, those opinions are no more than information that I need to weigh in my own deliberations. Having played extensively with coding systems, it seems fairly clear that the best way of giving that opinion is verbally, with the language of the phone call, letter or email giving clues as to the matters in question, the observations used in moving toward the conclusion(s) reached and the advice sought or offered. Yes, I'm happy to compose the bulk of my letter from elements formally represented in my medical record and to parse the reply for similar elements, but the opinions expressed are likely to have their value reduced if they are removed from that context and the implicit timeframe. By all means let us look at ways of extracting useful elements from either letter, but let's not lose sight of the value of the letter which is undoubtedly greater than the sum of its parts. Jan Ravet --- ## Post #32 by @thomas.beale Hi Gerard, Gerard Freriks wrote: > Whay are the arguments for your preference for service models and generic distrinuted technology? a\) pragmatically: that is the way the world has been going for over 15 years \(RPC, Corba, OSF/DCE, webservices, WSDL etc etc\) b\) theoretically: the separation of computational \(service model\) and informational viewpoints \(a la ISO RM/ODP\) has major benefits in systems development and deployment: you can develop models of information separately from models of how the information will be commucated; and you can redeploy a back\-end behind a service without users of the service needing to be changed\. \- thomas --- ## Post #33 by @thomas.beale Gerard Freriks wrote: > Thomas, > > When we agree that the scope of OpenEHR is to document the professional opinions and the facts on which these are based then: > >> An instance of an Instruction documents roughly what might be in a prescription > > But it is semantically NEVER the same\. It is the documentation of the process that lead to a prescription\. It is NOT a prescription\. clearly not\. A prescription is a piece of paper in my hand from your doctor's rooms, containing an order for a medication from a pharmacy, and instructions to me \(to be typed or printed at the pharmacy\)\. But, if you wanted to generate such a physical \(or electronic\) document from an openEHR Instruction, all the information would be there \(the only exception would be if you wanted to indicate a particular pharmacy to go to\)\. \- thomas --- ## Post #34 by @system I agree. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #35 by @system Thomas, All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template. Only the intention is different. In the former it is about documentation. The latter is the prescription order that was documented. Can we agree that documentation is within the scope of OpenEHR (and EN136060) and that the electronic prescription as an order is not? And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages. In my view this subtle distinction in scope indicates where OpenEHR/CEN and HL7 are active and where they meet and are able to co-operate. When we agree about the scopes. I suggest that we revisit the present scope statements of OpenEHR and EN13606 and make things more explicit. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 --- ## Post #36 by @thomas.beale Gerard Freriks wrote: > Thomas, > > All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template\. > Only the intention is different\. > In the former it is about documentation\. > The latter is the prescription order that was documented\. > > Can we agree that documentation is within the scope of OpenEHR \(and EN136060\) and that the electronic prescription as an order is not? > And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages\. from the openEHR point of view, the content of a prescription is in the record\. The 'order' corresponding to a prescription is simply a notification from the prescriber to the filler\. This notification may be communicated in two ways: a\) by the patient turning up b\) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon c\) by an electronic message carrying the content \(due to shared EHR not being possible\) of the prescription and the notification What kind of electronic notification is used in b\) and c\) depends mostly on what receiver systems want to receive\. At this stage it could be similar to a v2 message\. The problem with the HL7 message though is that it is going to want to carry the content \(translated into HL7\-speak, and back out of it at the other end\) i\.e\. it will always want to do c\) above, so we have to be very careful about that\. It is clearly preferable if we are forced to work in mode c\) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread\. I agree: that should definitely be explored\. Then the obvious way to model b\) is to define something that looks like the EN13606 Extract \(augmented with notification info\), but allowing no content, but rather a logical pointer to some content\. I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from\. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this\. The key point to remember is that the EHR and other related systems are the sources or sinks of the information; messages should be able to carry whatever content they require, with 0 semantic translation, and minimal syntactic translation\. This is not the case today with HL7 messages\. I have just reviewed in detail some HL7v2 interfaces in Queensland Health in Australia, and it is clear that the messages are imposing semantic as well as syntactic translations\. HL7v3 messages will do the same\. It is also clear that this is an undesirable situation; it is like the postal service forcing everyone to write letters in latin \- and only using the postal service's allowed lexicon of latin phrases, even though the sender and receiver both want to speak english\. Anyone who has seen the Monty Python Hungarian phrase\-book sketch will know what I mean\. This is why I say that service models \(which are agnostic as to content\) are a preferable approach\. EN13606 is pretty agnostic as to content, and can easily fit into such a framework\. \- thomas --- ## Post #37 by @system -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 > Gerard Freriks wrote: > > > Thomas, > > > > All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template. > > Only the intention is different. > > In the former it is about documentation. > > The latter is the prescription order that was documented. > > > > Can we agree that documentation is within the scope of OpenEHR (and EN136060) and that the electronic prescription as an order is not? > > And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages. > > from the openEHR point of view, the content of a prescription is in the record. Correct to a degree. The record is there to document what has happened. eg a prescription was written. This has the status of an order TO BE fulfilled. The notification (in any form) has the same content as what is in the record, but is NOT the same. The notification must indicate (or contain) explicitly what is prescribed and has the status of an order to be fulfilled. > The 'order' corresponding to a prescription is simply a notification from the prescriber to the filler. This notification may be communicated in two ways: > a) by the patient turning up > b) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon > c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification > > What kind of electronic notification is used in b) and c) depends mostly on what receiver systems want to receive. At this stage it could be similar to a v2 message. The problem with the HL7 message though is that it is going to want to carry the content (translated into HL7-speak, and back out of it at the other end) i.e. it will always want to do c) above, so we have to be very careful about that. It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread. I agree: that should definitely be explored. Then the obvious way to model b) is to define something that looks like the EN13606 Extract (augmented with notification info), but allowing no content, but rather a logical pointer to some content. > > I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this. We are getting somewhere. In my mind, and on the basis of many years of a collective experience, we humans only trust a complete document handed to us, sent to us, that tells the whole story. This is what legal persons want to happen. Not a thing with a pointer to a place with content where you have no jurisdiction. Therefor I think that option C is what we are after when there is an order for an other in an other legal entity. Within the legal entity options a and b will be ok. > The key point to remember is that the EHR and other related systems are the sources or sinks of the information; Of events that have happened. They DOCUMENT. > messages should be able to carry whatever content they require, with 0 semantic translation, and minimal syntactic translation. This is not the case today with HL7 messages. I have just reviewed in detail some HL7v2 interfaces in Queensland Health in Australia, and it is clear that the messages are imposing semantic as well as syntactic translations. HL7v3 messages will do the same. It is also clear that this is an undesirable situation; it is like the postal service forcing everyone to write letters in latin - and only using the postal service's allowed lexicon of latin phrases, even though the sender and receiver both want to speak english. Anyone who has seen the Monty Python Hungarian phrase-book sketch will know what I mean. > > This is why I say that service models (which are agnostic as to content) are a preferable approach. EN13606 is pretty agnostic as to content, and can easily fit into such a framework. You are correct about your metaphor. But many people want to write and read in Latin. In a services environment this will be up to the actors that will make use of the services. They will speak Latin when they want to or OpenEHR (EN13606) when this fits their needs. --- ## Post #38 by @system Dear John, I agree. OpenEHR (and HL7) is about a part of the equation. They need an infrastructure but this is outside of the scopes. In some places they are touching it. In CEN/tc251 we are working on a standard: Health Information Systems Architecture. This will address the infrastructural topics. With regards --- ## Post #39 by @thomas.beale Gerard Freriks wrote: >> from the openEHR point of view, the content of a prescription is in the record\. > > Correct to a degree\. > The record is there to document what has happened\. eg a prescription was written\. This has the status of an order TO BE fulfilled\. > The notification \(in any form\) has the same content as what is in the record, but is NOT the same\. > The notification must indicate \(or contain\) explicitly what is prescribed and has the status of an order to be fulfilled\. > when I talk of 'notification', I am not talking about content; I am talking about a notification from a provider to a pharmacy \(in this example\), referring to a piece of information in an EHR system which expresses the prescription, and indicating that the pharmacy should act upon it for the patient in question\. >> The 'order' corresponding to a prescription is simply a notification from the prescriber to the filler\. This notification may be communicated in two ways: >> a\) by the patient turning up >> b\) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon >> c\) by an electronic message carrying the content \(due to shared EHR not being possible\) of the prescription and the notification >> >> What kind of electronic notification is used in b\) and c\) depends mostly on what receiver systems want to receive\. At this stage it could be similar to a v2 message\. The problem with the HL7 message though is that it is going to want to carry the content \(translated into HL7\-speak, and back out of it at the other end\) i\.e\. it will always want to do c\) above, so we have to be very careful about that\. It is clearly preferable if we are forced to work in mode c\) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread\. I agree: that should definitely be explored\. Then the obvious way to model b\) is to define something that looks like the EN13606 Extract \(augmented with notification info\), but allowing no content, but rather a logical pointer to some content\. >> >> I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from\. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this\. > > We are getting somewhere\. > In my mind, and on the basis of many years of a collective experience, we humans only trust a complete document handed to us, sent to us, that tells the whole story\. This is what legal persons want to happen\. > Not a thing with a pointer to a place with content where you have no jurisdiction\. you would never see that; don't forget we are talking computational systems here \- the user would of course see the content\. My description applies to what goes on behind the scenes\. > Therefor I think that option C is what we are after when there is an order for an other in an other legal entity\. > Within the legal entity options a and b will be ok\. Well, option b\) is more futuristic, and a\) and c\) both exist now\. b\) undoubtedly exists in some places right now but is not widespread\. >> The key point to remember is that the EHR and other related systems are the sources or sinks of the information; > > Of events that have happened\. They DOCUMENT\. not just events that happened\. Of opinions about what has happened, what should happen, and prescriptions \('Instructions'\) of events that will happen\. All this is of course some kind of documentation\. > You are correct about your metaphor\. > But many people want to write and read in Latin\. not if their natural language is 20th century english\! > In a services environment this will be up to the actors that will make use of the services\. > They will speak Latin when they want to or OpenEHR \(EN13606\) when this fits their needs\. whatever language they speak, it is unlikely that they will want to speak a mutually foreign language imposed upon them by the postal service, when they have standardised languages more closely fitting their communication semantics and systems\. \- thomas --- ## Post #40 by @thomas.beale > >> Surely it should be possible to come up with some agreed high level ontologies and implement systems that support this level of ontology without being too prescriptive in defining the lower levels\. It is then possible to refine the concepts through refining the business modelling they are based on and the systems that implement them\. As this is achieved the next layer of ontological definition for important processes will identify itself\. At this stage, in the area of Primary and Community Health, Ambulatory Care and Chronic Disease Management \(my particular areas of interest\) I believe that this approach translates into a focus on ontologies AND SUPPORTING INFRASTRUCTURE \(sorry for yelling\!\) for >> >> Patient/Client \(Identification, digital certificates, basic demographics, possibly allergies, etc\)s >> >> Provider \(Identification, digital certificates, speciality, qualifications, etc\) >> >> Service \(context of the provider \- service type, location, organisation etc\.\) >> >> Communications activities \(referral , orders, etc and their responses\) >> this is the sort of stuff many people are working on\. Some are working in the archetype world, others are working in the HL7 RMIM world\. >> I believe that the required descriptions are essentially there in both the the openehr and HL7 RIM ontologies\. My real problem is that I don't see anyone in the openehr mailing lists clamouring for the infrastructure initiatives required to support the broad implementation of ontologies at this level\. There is something of the chicken and egg about this \(how can we define the required infrastructure without the ontologies\) I would argue that the detail of these ontologies will change for many reasons, including responses to changing healthcare practice, government policies, etc\. and we should get on with implementing an agreed minimal set of directories, identification schemes and services in the above areas as basic infrastructure based on simple \(minimalist even\) high level ontologies\. This would provide a platform for getting on with the more detailed work of refining ontologies in specific contexts\. I realise that the issues of implementation are specific to particular jurisdictions, and it is possible that many of you are defining your ontologies in just the manner I am describing\. As an Australian, I wonder what our role in this is given that we don't have any of the required infrastructure in place \- nor any apparent source of funding to support its development? >> well, actually, some of the instructure is being built in Australia \(as it happens\) but for international use\. We have a large initial set of archetypes \(GPCG project 2005\) http://oceaninformatics.biz/archetypes/, and the beginnings of an ontology repository at http://www.dualitysystems.com.au/archetypefinder/archetypefinder. The interesting thing about this latter one is that it is not a normal screen form, it is dynamically generated from available meta\-data from existing archetypes in the database\. This is just a taster of course \- this kind of application has to get a lot more powerful to fulfill the needs of a large community of collaborating authors\. >> I realise that this may appear to be a simplistic approach but I feel that it is important not to lose sight of the real goal \- we want to build useful systems to support service providers in health care \- all of them, from providers of needle exchanges, drug and alcohol counselling, home help and meals on wheels to general practitioners, respiratory physicians, orthopaedic surgeons, medical researchers and epidemiologists\. In order to do this effectively, we should be wary of biting off more than we can chew\. When it comes to meeting the needs of the diverse range of actors and actions found in healthcare, we need to start by agreeing on very simple generic concepts, implement them, and work our way down \- rather than diving in to the detail while trying to keep the 'big picture' in mind\. This is not intended to denigrate such efforts, but rather to try and encourage an environment where they can flourish and really make a difference\. >> I don't thik we have any difference of vision here\. The openEHR reference model is designed to be as simple as possible \(in the Einstein sense\); it has about 80 classes including all the data types\. But that's it \- there is no growing collection of data schemas\. \- thomas --- **Canonical:** https://discourse.openehr.org/t/actionability-of-orders/14503 **Original content:** https://discourse.openehr.org/t/actionability-of-orders/14503