I believe there is some wrong viewpoints expressed below, and will include comments following my initials WG
In a message with datum 18-9-2005 1:47:54 West-Europa (zomertijd), Thomas.Beale at OceanInformatics.biz writes: TB: from the openEHR point of view, the content of a prescription is in the record. WG: This is probably from any patient record system, not exclusively the OpenEHR solution TB: The 'order' corresponding to a prescription is simply a WG: so you agree you need some kind of communication, i.e. a message, that fulfills this notification act. TB: This notification may be communicated in two ways: WG: 3 ways......a,b,c, ? TB: a] by the patient turning up WG: clear, TB: b) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon WG: Yes, so a message that holds the notification with a moodcode of request, assuming that the filler will act upon. The core dynamics of the HL7 approach by the way. TB: c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification WG: or by an electronic message pointing to the content. It is clear you have not kept up to date with current Care Provision R-MIMs and clinical statement pattern in HL7. A 13606 based requirement is included, which is the Actreference. Thus a message would do as asked: notify a filler, but instead of sending content, it refers to content that the filler can look up (in EHR or earlier content loaden message, yes content can be there if required by clinicians) and act upon. Oh, yes of course, the message can hold the content as well if required for another use case. In the current situation I believe the majority of systems do not share EHR, due to existing and future different views on system design. Plurality will always remain the norm for EHR, so how to communicate then? TB: 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. WG: Or like the Dutch national system approach, implemented on national scale from 1 January onward, with V3 medication messages, or the UK approach of v3 medication messages already operational. TB: 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. WG: As said this is an incorrect representation of how it really works. The HL7-speak is mainly for the message transfer, so how the notification does reach the fillers system. The message content is (or is OpenEHR archetyping about changing the content? No of course) exactly the same as in the OpenEHR approach: defined by clinicians, based on vocabulary that supports communication, especially supports the imposed meaning of the sender to be clear (e.g. for legal reasons), like the precise prescription order to be acted upon by the filler. WG 2: it is really dangerous to assume that there needs to be no precisely defined content: healthcare requires precisely defined content, especially for patient safety reasons. TB: It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead; WG: this case 'preferable'is based on wrong arguments: HL7 messages do not tamper with the content, nor do 13606 / OpenEHR. So not a valid argument! Both approaches do the job. TB: 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. WG: It should not necessarily be explored because it has been dealt with in the HL7 v3 dynamics, and as we are currently working on - this dynamics do work in the EHR as well, not only for messages. TB: 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. WG: Yes, you are defining here the use case for the current HL7 v3 Care Provision D-MIM and R-MIM: these do 100% of what you want the OpenEHR to do. But of course, reinventing the wheel is better? TB: 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. WG: My suggestion would be to follow the Dutch suggestion to CEN for 13606 improvements: which is not only to put in a phrase that it is harmonized with HL7 v3, but actually use the Care Provision D-MIM / R-MIM set for a] explaining how the very abstract 13606 RIM, which is not harmonized with HL7v3 RIM despite the MoU, can be used for real patient care, and b] include the dynamics which has been found to be lacking in the OpenEHR and which is carefully / research and experience based modeled in HL7 v3. TB: 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. WG: this is a real error in thinking, Thomas, you really need to think this through again, because you make absolute wrong assumptions here, resulting in a wrong judgment of the HL7 v3 messages. I agree with you that the EHR and related systems are examples of sources of information. I define the information here then as knowledge represented in the fields of the EHR (or if you like archetypes, organization of archetypes, entries, documents), filled with concrete data about a particular patient (so, baby Michelle, born Sept 17, 2005, temperature = 37 degrees C, APGAR score = 7, MD diagnosis = respiratory distress), and expressed in semantic meaningful wording or coding (e.g. for temperature, the archetype on www.zorginformatiemodel.nl, APGAR score from OpenEHR website, and P22.0 from ICD 10 see, http://www3.who.int/icd/vol1htm2003/fr-icd.htm ). I am afraid that the way you comment on HL7 as not content free is pertaining to your wish to not use such standard vocabularies. HL7 does not at all require semantic translations. It is the clinicians using different (agreed, not OpenEHR based) EHR systems that use different vocabularies. However, then the problem is on the clinicians level to agree upon the semantics. It makes absolutely no difference if this is in the framework of EHR development and use, or of messages. Any other suggestion ridicules clinician input and difficulties of defining the semantics in health care, which is much much much more complex than having an archetype agreement between 2 EHR systems. HL7 v3 messages do no semantic translations, unless wanted by clinicians to get their content exchanged. HL7 v3 messages only do syntactical things if system A (sender) operates different from system B (filler). Translation is important from GP system using ICPC referring a patient to a hospital using ICD 10 for the same diagnosis. However, the GP EHR will use the ICPC for decision support (guidelines, yearly calls for vaccinations etc), where the hospitals EHR will probably use the ICD for additional functions (billing, national statistics). So it is not HL7 requiring any translation, but the functioning of health care at large in general and knowledgeable caring for the individual in particular. So to the last points: you said something I cannot agree more with, which is that: "messages should be able to carry whatever content they require". This is THE BASIC PRINCIPLE of the HL7 v3 messages. TB: 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. WG: Hopefully they do, to keep patients alive and safe!! TB: 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. WG: maybe I am lucky of not having seen this Monty something. A message should impose semantics, which is what HL7 v3 messages are: filled with clinical content, to ensure that the receiver can determine the meaning as exact as possible. TB: 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. WG: Yes, this agnosticism renders it potentially dangerous for healthcare. We are spending millions now to sort out that clinical content is exchanged correctly, e.g. to prevent the hundreds of thousands medication errors. Especially within the 13606 and OpenEHR and HL7 v3 environment the exchange format should be secure enough for any clinical content, and the content needs to be defined by clinicians, preferably in a format that can be used in any technology, not just only one vendor lock in system as OpenEHR currently is. There was another suggestion on this list to work on the reusable bits and pieces that need to be documented and exchanged in a standardized and preferably world wide agreed format. 1. Person demographic data like, name, date of birth, gender, perhaps a social security number if legally possible, and those other things that make an individual an individual and only that individual. 2. Patient related administration data of a person that tend to change over time, like addresses, insurances, institutional defined identification numbers, which can be zero to many. 3. Relationship based administration data of the person, e.g. for next of kin, children etc, with a focus on contact addresses, emergency phone numbers and so on. 4. Persistent clinical data: those data that are specifically for health related issues and that will probably not change over time and everybody needs to know: allergies / intolerances / blood group, body length. 5. Clinical statements of a person; the smallest molecular items of information that have a meaning in the health care arena. Probably the archetype list of OpenEHR and my set at www.zorginformatiemodel.nl fall in this category. HL7 v3 provides standards for already the following: 1. CMET E_Person has already a good set of attributes for this 2. CMET R_Patient has already a good set of attributes for this 3. Most can be met in other HL7 v3 artifacts, new use cases will will hosted without any problems as the case is clear. 4. The allergy / intolerance R-MIM of patient care covers now almost all relevant components / attributes and work on semantics is underway. 5. These can be expressed in the clinical statement pattern / care statement pattern of current HL7 v3 (hypothesis: all?, if not challenge the model to become inclusive, not blame it). A bit clumsy is still that the R-MIM / CMET / archetype / template discussion has not been solved yet, but we are very close in doing so and get e.g. an XML expression that would allow hooking in the HL7 v3 message, in the CDA and in the 13606 / OpenEHR entries. From the clinical perspective the latter is merely a technical task to have it work in a open standard like HL7 v3 or a vendor / system specific approach as OpenEHR. Just to name a list of what is currently available in R-MIM format with explicit clinical input on knowledge, variables, terminologies, value sets: - vital signs all and length and weight - physical exam generic - urine function - assessment - history - family history - neurologic exam - nervous system exam subset - social aspects - communication - walking ability - somatic problems / dysfunctions - ADL functions open questions - Barthel index - psychologic and psychosocial factors - Mini Mental State exam - CES-D depression scale - FAC (Functional ambulation categories) - Frenchay arm test - Fatigue scale - 10 meter walk test - RAP protocol - Bamford stroke classification - Glasgow Coma Scale - Berg Balance Scale - Apraxia scale - consciousness assessment - checklist admission in hospital - COOP WONCA scales - coordination - cortical functioning - upper and lower extremities assessment - ergotherapy assessment - physiotherapy assessment - logepedia assessment - partly: nursing assessment (use of Gordon's functional health patterns as organizers of content, not determinants of, so no super imposed structure, but easily adaptable) - use of aids - encounter tracking and planning, e.g. preventive care - meningeal problems - modified Asworth scale - modified Rankin scale - Motricity index - NIH stroke scale - motor functioning assessment - pain score (VAS style currently, full assessment underway) - star cancellation test - sensibility assessment - smoking, alcohol, drugs use - reflexes assessment - trunk control test - feeding status - description of the home (e.g. to determine place for discharge of stroke patient) Al have a specific format that defines the purpose of the scale / assessment, the variables, value sets, codes, the method for use, interpretation, literature, an HL7 v3 R-MIM a systematic listing of a mapping table with variable, place in HL7 v3 D-MIM / R-MIM (the RIM itself makes no sense here, the format for EHR and Message is key), datatype, value set, cardinality, unique code (to keep semantics OK), and often examples of scores or result of the observation. Further, we have in some instances an XML representation (example message format) and for Barthel an OpenEHR archetype. Several have organizers or batteries, which allow to group sets in larger sets. Some in progress: - DSM IV scoring on 5 axis - Apgar score - meals on wheels - housekeeping as care for elderly and handicapped - house adjustments in case of disabilities Some in preparation: diabetes monitoring of complications like foot, eyes, renal functions etc. follow up visits, and much more. In preparation: European EPUAP guidelines for pressure ulcer risk detection, prevention, wound descriptions, wound care. And many more to come. Instead of arguing the case for or against HL7 v3 / OpenEHR, I prefer help in analyzing and improving what we currently have, suggest improvements and corrections, and to work on a technical representation that suits many systems, especially that does not worry about HL7 v3, 13606 or OpenEHR. I then leave it to the technicians that built one kind of solution versus the other to handle this clinical stuff. I further would suggest the HL7 v3 versus 13606 / OpenEHR debate to be removed from OpenEHR clinical to OpenEHR technical. For those who can read English and are not scared off by 90% of content in Dutch and pink coloured HL7 v3 Observation classes clinically organized together, the Mapping tables of the above instruments are available on www.zorginformatiemodel.nl. This stuff is copyright free and can be used. The only things I ask is to tell me if it is useful to you, and to not blame the current HL7 v3 R-MIM format. We use this because it is the only current process that leads to true XML messages that can be validated against the message schema's. I look forward to new tools that allow me concentrate on the content and that spit it out in HL7 v3 XML / archetype format. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20050918/54ee4e50/attachment.html>
