# Sources of information on HL7 EHR/OpenEHR **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2006-09-13 18:57 UTC **Views:** 2 **Replies:** 51 **URL:** https://discourse.openehr.org/t/sources-of-information-on-hl7-ehr-openehr/14561 --- ## Post #1 by @odysseas Hello, Are there any documents anywhere that describe or compare and contrast the OpenEHR initiative and the HL7 EHR effort? I have seen a couple of references to the fact that there are efforts to achieve harmonization but I was wondering if there is a detailed comparison anywhere\. We are in the process of working through the OpenEHR specification documents and implementation code as well as the specification documents coming out of the HL7 EHR effort so, I was wondering if there are is a study of some sort that would assist us in the process of making the comparison and establishing the association\. Thanks, Odysseas Odysseas Pentakalos, Ph\.D\. Chief Technology Officer SYSNET International, Inc\. --- ## Post #2 by @williamtfgoossen In een bericht met de datum 13-9-2006 21:25:34 West-Europa (zomertijd), schrijft odysseas@sysnetint.com: > Hello, > > Are there any documents anywhere that describe or compare and contrast the > OpenEHR initiative and the HL7 EHR effort? I have seen a couple of references > to the fact that there are efforts to achieve harmonization but I was > wondering if there is a detailed comparison anywhere. > > We are in the process of working through the OpenEHR specification documents > and implementation code as well as the specification documents coming out of > the HL7 EHR effort so, I was wondering if there are is a study of some sort > that would assist us in the process of making the comparison and establishing > the association. > > Thanks, > Odysseas > > Odysseas Pentakalos, Ph.D. > Chief Technology Officer > SYSNET International, Inc. > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical You could look at the NEHTA website for their paper that compares standards, including CEN 13606 (OpenEHR) and HL7 v2 and HL7 v3. There is an OpenEHR presenation / paper for the MIE 2006 conference, tackling some of the differences HL7 / CEN and ISO work together on a 13606-HL7 v3 R-MIM that does the conversion, it is currently developed as an implementation guide. There are comments from the Netherlands to CEN about the 13606 (available at the CEN website) in which some brief comparison is included. Most people compare the 13606 OpenEHR materials with the HL7 RIM. However, that is the wrong level to compare, appropriate would be to compare with the HL7 v3 Care Provision D-MIM derived from the RIM, because this is focused on the EHR extract and on the full Record exchange message. In general: OpenEHR / 13606 RIM is the most generic / a-specific model level, could potentially be used for shipbuilding records, supermarkets and healthcare records HL7 v3 RIM is more detailed in such that it covers health care specific classes and relationships D-MIMs are made of the HL7 v3 RIM virtual bricks to become meaningful domain models derived from D-MIMs are the R-MIMs which are subsets for specific message purposes. on the detailed level the archetypes in CEN 13606 and in HL7 v3 the templates and R-MIMs for specific care statements, cover the smallest molecules of clinical data. examples of the latter can be found at www.zorginformatiemodel.nl A problem with the archetype approach (see the definition of this in open EHR and 13606) is that it does not address the clinical vocabulary which is included in HL7 v3 R-MIM approaches and it does not tackle the clinical knowledge base that explains why some data have to fit together and why a relationship has to be kept. (E.g. for scientific instruments and scales). Hope this helps, dr. William Goossen co- chair HL7 v3 patient care TC --- ## Post #3 by @thomas.beale The main difference architecturally is that there in openEHR there is a reference model from which software and systems can be built\. Archetypes and templates simply designate legal configurations of instances of the reference model\. In HL7, the data are instances of schemas that are progressively refined from the RIM\. In recent discussions with the designers, they claim that the theory of DIMs, RMIMs etc is based on "relational projections" on the RIM \(i\.e\. that's the basis of attribute "removal"\)\. Anyway, the end result is a schema per message\. Williamtfgoossen@cs\.com wrote: > > on the detailed level the archetypes in CEN 13606 and in HL7 v3 the > templates and R\-MIMs for specific care statements, cover the smallest > molecules of clinical data\. > examples of the latter can be found at www\.zorginformatiemodel\.nl you can see the openEHR archetypes at http://svn.openehr.org/knowledge/archetypes/dev/index.html > > A problem with the archetype approach \(see the definition of this in > open EHR and 13606\) is that it does not address the clinical > vocabulary which is included in HL7 v3 R\-MIM approaches and > it does not tackle the clinical knowledge base that explains why some > data have to fit together and why a relationship has to be kept\. \(E\.g\. > for scientific instruments and scales\)\. this is a problem I was unaware of William, can you elaborate with an example? \- thomas --- ## Post #4 by @system Dear William, It is nice to see a balanced approach to the problem of plug-and-play semantic interoperability that Archetypes and Template will bring about. As far as I can see is the Reference Model provided by CEN/tc251 in EN13606 an openEHR a stable, well researched, developed and complete specification to be implemented in EHR-systems. I have some founded doubts about the stability of the HL7v3 RIM as reference model, as several papers and debates indicate. I fail completely to see the problems you mention with CEN/tc251 EN13606 and openEHR archetypes. So I'm (and many more will be) very curious to see an example. The experiences so far at TNO in the Netherlands have not given any indication of the type of problems you mentioned. On the contrary. Archetypes bind coding systems, and their codes, tightly to clinical concepts used in a defined context. That is the essential purpose (requirement) for archetypes that they have these characteristics. Greetings, Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #5 by @Dipak_Kalra Dear William, Please note that some of the vocabulary mappings, and correspondence with the main HL7 Act specialisations are provided in 13606 Part 3\. I recognise this is not the complete solution you seek, but it is a start\. \(The Enquiry draft of Part 3 was recently circulated to CEN Working Group members\. Although not yet on the public CEN TC/251 web site I am sure it will be soon\. You, of course, William have had direct access to it via NEN\.\) Others can let me know if they would like me to e\-mail you a copy\. with best wishes, Dipak Kalra Clinical Senior Lecturer in Health Informatics CHlME, UCL --- ## Post #6 by @grahamegrieve Hi Tom > The main difference architecturally is that there in openEHR there is a > reference model from which software and systems can be built\. This is not a difference; it's true of HL7 as well > Archetypes > and templates simply designate legal configurations of instances of the > reference model\. this is true about archetypes > In HL7, the data are instances of schemas that are > progressively refined from the RIM\. well, it doesn't have to be; and also, you could do this with archetypes and/or templates, and it would have some use too\. > In recent discussions with the > designers, they claim that the theory of DIMs, RMIMs etc is based on > "relational projections" on the RIM \(i\.e\. that's the basis of attribute > "removal"\)\. well, I can't speak for "the designers" \(I'm spending some time with him today on this subject ;\-\), but archetypes and HL7 models are the same thing\. I can interconvert between them\. The only issues are syntactical differences in things that are allowed in each language, and they are minor\. Obvious conclusion: they are the same thing\. There are differences, but they are really primarily engineering differences\. And some philosophical stuff in the reference models, but I'm starting to think this isn't as big as I thought It appears that this is stuff we can sort out and actually work together\. Grahame --- ## Post #7 by @system >> al"\)\. >>     > well, I can't speak for "the designers" \(I'm spending some time with him > today on this subject ;\-\), but archetypes and HL7 models are the same thing\. > I can interconvert between them\. The only issues are syntactical differences > in things that are allowed in each language, and they are minor\. Obvious > conclusion: they are the same thing\. >   Yes, this is partly true\. I even started writing a tool which translated automatically HL7 XSD's to ADL\-files\. So it was possible to use OpenEHR as a HL7 storage machine\. I stopped this work because there is a bug in the java\-kernel concerning Archetype\-slots, which are really necessary for this job\. Now, also, because I changed my plans, the need disappears to finish this, but it can be done, in fact, I did it, except from the places where CMETs which incorporate other CMETs \(and a few other smaller things\), and the code is quite easy, from which one can conclude that ADL is fit to store CMETs\. So, OpenEHR is fit as a HL7 storage machine\. The product is however in beta, beta phase\. I wrote it in a few weeks, and it needs some time to come to a really stable and good product\. \(it even is more powerful, than for HL7 storage machine, my code does not know it is handling HL7, it handles every XSD\-file, also when more are referred to each other, which almost always is\) The code I wrote is however based on the 0\.95 kernel\. But it can easily be transformed to a newer version\. And why is this good? --- ## Post #8 by @grahamegrieve I have code to build the archetypes from the internal source of the R\-MIM's rather than the schemas\. I will be publishing this through eclipse shortly\. I will be able to go the other way too, but both formats will need modifications for gap coverage\. I am presenting changes to the RMIM diagrams tomorrow for HL7 consideration, and also talking to Thomas about changes to ADL to address the gap\. Grahame Bert Verhees wrote: --- ## Post #9 by @thomas.beale Grahame Grieve wrote: > Hi Tom > >> The main difference architecturally is that there in openEHR there is a >> reference model from which software and systems can be built\. >>     > This is not a difference; it's true of HL7 as well >   I think people would have a hard time finding it \- where is the reference model from which you can build software? It's not the RIM as we are told time and time again \(I can pull a dozen quotes from all the core RIM designers to say that the RIM is not a basis for software, only generating other schemas \- this has been practically religion for 10 years\)\.\.\. you could call the sum total of all the HMDs a "reference model" I guess, since they are what software is based on, but that's stretching the meaning of the term\.\.\.anyway, it's a pretty clear difference for all practical purposes\. >   >> In HL7, the data are instances of schemas that are >> progressively refined from the RIM\. >>     > well, it doesn't have to be; and also, you could do this with archetypes > and/or templates, and it would have some use too\. >   I'm just saying how things work now, so that new people have some hope of understanding\. I doubt if it would have any use with archetypes / templates though \- the subtractive logic based on relational projections just isn't a part of normal object modelling or openEHR\. >   >> In recent discussions with the >> designers, they claim that the theory of DIMs, RMIMs etc is based on >> "relational projections" on the RIM \(i\.e\. that's the basis of attribute >> "removal"\)\. >>     > well, I can't speak for "the designers" \(I'm spending some time with him > today on this subject ;\-\), but archetypes and HL7 models are the same thing\. > I can interconvert between them\. The only issues are syntactical differences > in things that are allowed in each language, and they are minor\. Obvious > conclusion: they are the same thing\. >   That's a somewhat misleading statement\. An archetype isn't a new model; it's a statement about putting together pieces from an existing model\. An RMIM is a new model with respect to the model from which it was derived \- different classes, different attributes\. That's the whole point of the HL7 refinement method \- to iteratively derive new schemas from the RIM\.\.\.you can't pick up an RMIM and say what configuration of classes from another model you have, because you don't have classes from another model, you have \_modified\_ classes from another model\. I know that some RIM people will then say that the classes aren't really modified, the missing attributes are "projected out", which means the new classes are indeed new classes \- each one specifying a new projection on a class in the preceding model\. Which brings us to the question of the quality of the original model \(the RIM\), as well as the details of the refinement method as a way of specifying content models\. Some archetypes and RMIMs are trying to say the same thing however\. Is reliable machine conversion possible? The key point is that while conversion between the formalisms of some part of an archetype and an RMIM and vice versa may be possible, conversion between actual real archetypes and real RMIMs is not the same thing, due to the reference models involved\. Conversions that might be considered: a\) existing openEHR or CEN archetypes \-> RMIM "language" \- based on the RIM? b\) existing RMIMs \-> archetypes based on the RIM c\) existing RMIMs \-> archetypes based on openEHR a\) might be possible, but seems hard, because the RIM lacks numerous primitives present in the openEHR reference model; if it was achieved, it would allow openEHR content to be communicated in an HL7v3 message \(although why incur all the pain of transformation at both ends, when the information can just be sent in the normal way is beyond me \- sending it as an opaque payload would be easier and safer\); b\) may well be doable, and I suspect is the transformation you have most likely achieved already \- this would allow archetyping tools to be used in HL7, but still wouldn't provide a way for openEHR archetypes to be used in HL7, due to the difference reference models; c\) I cannot see being possible because of the differences in reference models and also another problem: it is hard to tell with RMIMs what was intended and what "had to be done that way" due to the limited language available in the RIM\. Actually reverse\-engineering the true intention of the modellers from an RMIM in general will be hard, due to this effect, and it should not be under\-estimated\. So c\) is only likely to be doable my manual means, but it certainly should be considered, because there is a goldmine of domain thinking locked up in the RMIMs which needs to be shared by systems and technologies outside of HL7v3 messages\. One of the things newcomers to this field have to do is have a very hard look at the reference models involved, how they enable semantically rich systems and how they provide business value; then they need to understand the methodologies involved in actually building software, and what the costs and benefits are\. \- thomas beale --- ## Post #10 by @system >> al"\)\. > > well, I can't speak for "the designers" \(I'm spending some time with him > today on this subject ;\-\) , but archetypes and HL7 models are the > same thing\. > I can interconvert between them\. The only issues are syntactical > differences > in things that are allowed in each language, and they are minor\. Obvious > conclusion: they are the same thing\. >   Yes, this is partly true\. I even started writing a tool which translated automatically HL7 XSD's to ADL\-files\. So it was possible to use OpenEHR as a HL7 storage machine\. I stopped this work because there is a bug in the java\-kernel concerning Archetype\-slots, which are really necessary for this job\. Now, also, because I changed my plans, the need disappears to finish this, but it can be done, in fact, I did it, except from the places where CMETs which incorporate other CMETs \(and a few other smaller things\), and the code is quite easy, from which one can conclude that ADL is fit to store CMETs\. So, OpenEHR is fit as a HL7 storage machine\. The product is however in beta, beta phase\. I wrote it in a few weeks, and it needs some time to come to a really stable and good product\. \(it even is more powerful, than for HL7 storage machine, my code does not know it is handling HL7, it handles every XSD\-file, also when more are referred to each other, which almost always is\) The code I wrote is however based on the 0\.95 kernel\. But it can easily be transformed to a newer version\. And why is this good? --- ## Post #11 by @williamtfgoossen In een bericht met de datum 13-9-2006 23:44:53 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: > The main difference architecturally is that there in openEHR there is a > reference model from which software and systems can be built. Archetypes > and templates simply designate legal configurations of instances of the > reference model. In HL7, the data are instances of schemas that are > progressively refined from the RIM. In recent discussions with the > designers, they claim that the theory of DIMs, RMIMs etc is based on > "relational projections" on the RIM (i.e. that's the basis of attribute > "removal"). Anyway, the end result is a schema per message. Sometimes a set of schema's even to also refer to generic message parts. However, once this set of messages per domain is ready, it can be used over and over and over. It is stable along clinical domains, as we have proven in different projects in the Netherlands. Key is that there is a data specification and mapping per clinical domain. Here the archetype / templates come into place. Once the mapping is made for common data, they can be carried over from one clinical domain to the other. E.g. the bloodpressure archetype / template / mapping table specification does not differ between domain of stroke care or domain of general surgery, it is common knowledge and reusable. We are currently working on harmonizing the procedures to specify the clinical knowledge, to model it once and to use tools to transform between OpenEHR, HL7 v3 and other technical solutions. --- ## Post #12 by @minreddy_minreddy Hi I compiled java ADL parser and when i ran this with the file archetypes/dev/adl/openehr/demographic/openehr-demographic-person.person.draft.adl It fails with following error --- ## Post #13 by @grahamegrieve Hi Tom >> This is not a difference; it's true of HL7 as well >>   > > I think people would have a hard time finding it \- where is the > reference model from which you can build software? You can build it from RIM or DMIM's or Messages\. Would this be a good choice? I suspect not\. But let's be correct here\. >>> In HL7, the data are instances of schemas that are >>> progressively refined from the RIM\. >>>     >> >> well, it doesn't have to be; and also, you could do this with archetypes >> and/or templates, and it would have some use too\. >>   > > I'm just saying how things work now, so that new people have some hope > of understanding\. I doubt if it would have any use with archetypes / > templates though \- the subtractive logic based on relational projections > just isn't a part of normal object modelling or openEHR\. The "subtractive logic" as you call it, is exactly what cADL is\. It's true that it's not part of normal object modelling \- and that's a deficiency of normal object modelling\. So you invent cADL and Hl7 invents Static Model Diagrams, but they both do the same thing, and in this regard OpenEHR and HL7 do not follow normal object modelling\. >> well, I can't speak for "the designers" \(I'm spending some time with him >> today on this subject ;\-\), but archetypes and HL7 models are the same thing\. >> I can interconvert between them\. The only issues are syntactical differences >> in things that are allowed in each language, and they are minor\. Obvious >> conclusion: they are the same thing\. >>   > > That's a somewhat misleading statement\. An archetype isn't a new model; > it's a statement about putting together pieces from an existing model\. it's not a misleading statement\. I am aware that lot's of HL7 people are making misleading statements about HL7 modelling \- but they are mislead themselves, and they are generally open to being educated\. if I can interconvert, therefore it's true that the 2 formats are presentations of the same concept\. ADL is a more natural fit, and I think that in the long term, most people would prefer to develop in the tools that arise out of the ADL constructs\. But they are still the same concept So let's all move on: these things are the same concept, there's some engineering differences about how to represent and use the concepts\. > Some archetypes and RMIMs are trying to say the same thing however\. Is > reliable machine conversion possible? The key point is that while > conversion between the formalisms of some part of an archetype and an > RMIM and vice versa may be possible, conversion between actual real > archetypes and real RMIMs is not the same thing, due to the reference > models involved\. agree that automated conversion between reference models is not \(yet\) possible, and agree that the key difference is in the reference models\. This is something we all need to work on\. At least we have made major progress with data types\. I suggest as an opening gambit regarding how to progress this that the OpenEHR reference model corresponds more closely to the HL7 domain models than to the RIM, and that's the useful point to pursue genuine interoperability\. Grahame --- ## Post #14 by @thomas.beale Williamtfgoossen@cs\.com wrote: > > Yes, it is currently not possible in the archetype editor to define > the goal of an instrument, have a abstract of the evidence base in the > clinical world underpinning it, work instructions, interpretation > guidelines, references to the literature or websites per archetype\. It > should not be too difficult to add this and then it would be useful > tool for any standard development once Grahame Greave has done his > tooling work\. > Hi William, Since I am not 100% sure of the details of what you want to do, I won't make any claims yet, but it seems to me that the archetype "description" section \(i\.e\. the meta\-data in an archetype\) is the place where you can reference online and other resources \(e\.g\. guidelines, medline content\) used to build or otherwise related to the archetype\. See here for this information being displayed in an archetype \(it happens that in this archetype the "resources" fields are empty, but they are there\) \- http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.png \. The meta\-data design is based on CEN and CDA meta\-data specifications\. Looking at the latest version of the Archetype Editor, it seems that the resources fields cannot be edited directly yet \- this functionality needs to be added\. Would this address the need in this area? As for the "goal of an instrument" \- I am not sure what you mean \- can you explain a bit further? \- thomas --- ## Post #15 by @williamtfgoossen In een bericht met de datum 14-9-2006 20:33:51 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: > Hi William, > > Since I am not 100% sure of the details of what you want to do, I won't > make any claims yet, but it seems to me that the archetype "description" > section (i.e. the meta-data in an archetype) is the place where you can > reference online and other resources (e.g. guidelines, medline content) > used to build or otherwise related to the archetype. See here for this > information being displayed in an archetype (it happens that in this > archetype the "resources" fields are empty, but they are there) - > http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.png > . The meta-data design is based on CEN and CDA meta-data specifications. > > Looking at the latest version of the Archetype Editor, it seems that the > resources fields cannot be edited directly yet - this functionality > needs to be added. Would this address the need in this area? > > As for the "goal of an instrument" - I am not sure what you mean - can > you explain a bit further? > > - thomas I know Thomas that we are almost getting there: It needs indeed to be editable at least when entering the first version and then updatable with versions. The goal or purpose is the reason why a clinician would use the data, instrument, observation in first place: clinical knowledge. E.g. apgar score must be measured after birth of a baby 1 min, 5 min, 10 min. It is often very obvious, but the more we move into detailed clinical area's the less obvisous is gets and such functionality allows to trace back the clinical knowledge. One upcoming project will be to set up the real specified criteria for defining the background knowledge of what in next stepp will become an archetype / synonym. I have spoken with Sam, Heath and Sebastian Garde on how we can do this. Just give us the time to manage it (requirements). Thanks, William --- ## Post #16 by @Tim_Churches Bert Verhees wrote: > I stopped this work because there is a bug in the java\-kernel concerning > Archetype\-slots, which are really necessary for this job\. \.\.\. > The code I wrote is however based on the 0\.95 kernel\. But it can easily > be transformed to a newer version\. Bert, What "java\-kernel" are you referring to? Tim C --- ## Post #17 by @thomas.beale Williamtfgoossen@cs\.com wrote: > In een bericht met de datum 14\-9\-2006 20:33:51 West\-Europa > \(zomertijd\), schrijft Thomas\.Beale@OceanInformatics\.biz: > >> Hi William, >> >> Since I am not 100% sure of the details of what you want to do, I won't >> make any claims yet, but it seems to me that the archetype "description" >> section \(i\.e\. the meta\-data in an archetype\) is the place where you can >> reference online and other resources \(e\.g\. guidelines, medline content\) >> used to build or otherwise related to the archetype\. See here for this >> information being displayed in an archetype \(it happens that in this >> archetype the "resources" fields are empty, but they are there\) \- >> http://svn.openehr.org/ref_impl_eiffel/TRUNK/apps/doc/images/description_1.png >> >> \. The meta\-data design is based on CEN and CDA meta\-data specifications\. >> >> Looking at the latest version of the Archetype Editor, it seems that the >> resources fields cannot be edited directly yet \- this functionality >> needs to be added\. Would this address the need in this area? >> >> As for the "goal of an instrument" \- I am not sure what you mean \- can >> you explain a bit further? >> >> \- thomas > > I know Thomas that we are almost getting there: > > It needs indeed to be editable at least when entering the first > version and then updatable with versions\. > > The goal or purpose is the reason why a clinician would use the data, > instrument, observation in first place: clinical knowledge\. E\.g\. apgar > score must be measured after birth of a baby 1 min, 5 min, 10 min\. It > is often very obvious, but the more we move into detailed clinical > area's the less obvisous is gets and such functionality allows to > trace back the clinical knowledge\. there are two levels of expression of clinical knowledge, guidelines, evidence etc that we can use, namely a1\) guidelines etc that are mentioned in an archetype, and inform the design of the archetype\. This can be done as I described\. In this case, the guideline or other knowledge reference is the same for all data built from the archetype\. a2\) resources that are referenced on a per\-archetype basis, but not in the archetype, rather they are referenced from the archetype classification ontology that indexes archetypes b\) guidelines referenced in data, i\.e\. on a per instance basis\. On the model you see here: http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html the class CARE\_ENTRY has the attributes "protocol" \(how / why did I create this clinical statement/observation/whatever\), "guideline\_id" that enables the referencing of guideline that caused this Entry to be created \(e\.g\. maybe some guideline told the doc to measure the BP and also ask questions about smoking\); ENTRY\.workflow\_id may also be relevant, for Entries created due to workflow execution\. I would think these go close to supporting today's requirements in this area, although I realise we cannot predict the requirements of the future\.\.\. > > One upcoming project will be to set up the real specified criteria for > defining the background knowledge of what in next stepp will become an > archetype / synonym\. > > I have spoken with Sam, Heath and Sebastian Garde on how we can do this\. > > Just give us the time to manage it \(requirements\)\. yes, of course \- this is clearly an emerging area for the medical people\.\.\.\.maybe you will have more requirements for the models one day\.\.\. \- thomas --- ## Post #18 by @system Tim Churches schreef: > Bert Verhees wrote: >> I stopped this work because there is a bug in the java\-kernel concerning >> Archetype\-slots, which are really necessary for this job\. > > \.\.\. >> The code I wrote is however based on the 0\.95 kernel\. But it can easily >> be transformed to a newer version\. > > Bert, > > What "java\-kernel" are you referring to? It is the old kernel from Rong, you can find it in SVN I am still using it because I have software based on that, and I did some small patches in the grammar\-parser, ADL serializer \(called Outputter\) and ontology, and I have no time for a migration, maybe in one month, or so\. Bert --- ## Post #19 by @williamtfgoossen In een bericht met de datum 14-9-2006 22:22:42 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: > there are two levels of expression of clinical knowledge, guidelines, > evidence etc that we can use, namely > a1) guidelines etc that are mentioned in an archetype, and inform the > design of the archetype. This can be done as I described. In this case, > the guideline or other knowledge reference is the same for all data > built from the archetype. > a2) resources that are referenced on a per-archetype basis, but not in > the archetype, rather they are referenced from the archetype > classification ontology that indexes archetypes > b) guidelines referenced in data, i.e. on a per instance basis. On the > model you see here: > http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html > the class CARE_ENTRY has the attributes "protocol" (how / why did I > create this clinical statement/observation/whatever), "guideline_id" > that enables the referencing of guideline that caused this Entry to be > created (e.g. maybe some guideline told the doc to measure the BP and > also ask questions about smoking); ENTRY.workflow_id may also be > relevant, for Entries created due to workflow execution. > > I would think these go close to supporting today's requirements in this > area, although I realise we cannot predict the requirements of the future... Yes, this is indeed what we need, I do like b also very much, have not thought of this in this way due we use the moodcode dynamics and care plan R-MIM. Key in that is that we do what you express in b: explain that something (an observation) from the guideline goes into the careplan because the patient meets the criteria for it and the clinician determines to follow this. Moving to 'independent' modeling with the new tools will sort all these clinical materials out and allow both expression of knowledge and of workflow and of the result of resoning :-) thanks again, William --- ## Post #20 by @system Dear all, The 'next frontier' will be the various types of "workflow" and the interaction with the EHR and other components in an EHR-system. Before rushing into quick decisions and quick fixes I call for a study of: - CEN/tc251 System of Concepts for Contuity of Care, ContSys. - CEN/tc251 Health Information Services Architecture, HISA. The first contains the set of concepts dealing with co-operation between healthcare providers around the care of a patient. Several concepts dealing with care plans, clinical path ways in various sorts are defined. The second can help us think about the various levels where types of workflow take place because it defines in a generic way EHR-system components,their inter faces and behaviour. Each type of workflow will use its own model and behaviour of its components. The whole exercise needs to start with a validated set of requirements and the study of some important literature. It is my expectation that En13606/openEHR, ContSys and HISA contain more than enough ingredients to find a good solution. With regards, Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #21 by @Heath_Frankel Gerard, Interesting you raise this topic as it is becoming an interest of mine to start investigating the use of openEHR instructions to support the documentation requirements of clinical workflows such as medication prescriptions, dispense and administration, and referrals. The existing work of ContSys could certainly assist in this but being a techo, I need some clinicians to assist in developing these requirements and my Ocean clinician colleagues are already over extended. As you know, Ocean has and continues to develop the tools to support a simulation of these kind of clinical workflow scenarios and are looking for ways to gather more and varied clinical content to populate and test the OceanEHR suite. Are there people interested in providing clinical scenarios and data to assist in the requirements and content gathering process to be used in clinical workflow simulations? How can we initiate and progress this kind of activity and investigation? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: [heath.frankel@oceaninformatics.biz](mailto:heath.frankel@oceaninformatics.biz) --- ## Post #22 by @Andre_Duszynski Hello Heath, As part of an Australian RACGP/GPCG informatics project, i've made tentative steps into generating a resource for clinicians in migrating traditional paper\-based clinical guidelines to their equivalent within an EHR framework; openEHR being the type example\. The web resource is an evolving project in that I acknowledge that I've bitten off too much to chew \- had hoped to generate both the archetypes and templates for asthma management \!\! Anyways\. This resource which is very much open to comment, refinement and collaboration is available at: http://www.adelaide.edu.au/health/gp/units/medic-gp/openehr/ Being semi\-techo and straddling the clinical domain, i've used the Australian Asthma Management Handbook for primary care as the type example\. In respect to clinical workflows for asthma management, you may want to look at the following link which aims to abstract clinical asthma workflows from the handbook: http://www.adelaide.edu.au/health/gp/units/medic-gp/openehr/asthma/ I very much believe that a generic set of archetypes would straddle many   clinical activities and would act to bind management motifs across disease states \(or alternate considerations\)\. Thus very keen to see and add to this domain of knowledge \! Thanks additionally to Gerard for raising CEN/TC251 \- interesting\. Regards, Andre Duszynski\. --- ## Post #23 by @Heath_Frankel Andre, Thanks for these links, this resource will be useful in the future\. However, it is significantly more in\-depth then I am looking for at the moment\. It is probably a terminology issue also when I talked about clinical workflow, perhaps I should not have used this term as I wasn't talking about guidelines\. Although I have an interest in guidelines my current issue is the day\-to\-day work of a clinician prescribing medication and writing referrals, and following the state transitions of these instructions through to conclusion by recording them in the EHR\. It is mainly the generation of clinical scenarios and content that I am seeking assistance to allow me to simulate the scenarios using the Ocean openEHR suite of tools to test the application of openEHR in the process of medication orders to Pharmacies, and clinical and diagnostic referrals for starters\. Once we get these day to day clinical processes supported then we can look at the more complex work flows like guidelines and care plans\. Do you have any clinical scenarios and sample clinical content for your Asthma guidelines? Hope this clarifies\. Heath --- ## Post #24 by @thomas.beale Grahame Grieve wrote: > ``` > > ``` > > > ``` > > I'm just saying how things work now, so that new people have some hope > > of understanding. I doubt if it would have any use with archetypes / > > templates though - the subtractive logic based on relational projections > > just isn't a part of normal object modelling or openEHR. > > > > ``` > > ``` > > The "subtractive logic" as you call it, is exactly what cADL is. > > ``` No, it's not - this is a fundamental misunderstanding. The subtractive logic of the HL7v3 methodology is the ability of one model in the chain (say an RMIM) to remove attributes in class A that were defined in the same class A in the predecessor model (say a DIM). The models are defined, starting with the RIM, loaded with attributes that can be deleted (projected out) in this way. In the cADL formalism (which is mathematically based on F-logic), you cannot do any such thing. A cADL text simply says how instances from an existing object model fit together to create some particular lump of content.It is like the LEGO instruction sheet that says how to put LEGO blocks together; but you cannot modify the LEGO blocks themselves. As a consequence, the object model (the openEHR reference model) is defined in the normal way, rather than containing every possible attribute so that they can be later masked out. > ``` > It's true that it's not part of normal object modelling - and that's > a deficiency of normal object modelling. > ``` This isn't a deficiency in object modelling, because it is not part of the object model; cADL is mathematically a query or configuration of object model instances, but is not itself an object model. A good way to think about a cADL statement is like a piece of cardboard with a particular shape cut out of the centre; then you pass this over a database fully of various cardboard shapes; those that fit in the cADL hole are "matched" - this is how to understand a cADL statement as a query. > ``` > So you invent cADL and > Hl7 invents Static Model Diagrams, but they both do the same thing, > and in this regard OpenEHR and HL7 do not follow normal object > modelling. > > ``` No, that's not true. The object modelling part of openEHR is quite clear - it is the reference model, service models and so on (see [http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html](http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html)). Whether this is a "good" object model is open to debate, but it does follow normal precepts of object modelling, including abstraction, specialisation and extension. It doesn't contain all possible attributes in the most abstract classes, as the HL7v3 RIM does, because its mode of use is not part of a subtractive methodology. The two models can be compared side-by-side and the differences are clear; similarly, the differences in the two methods for creating content models are quite demonstrable. The differences are what makes HL7v3 so difficult to use (also easily demonstrable). > ``` > > ``` > > > ``` > > That's a somewhat misleading statement. An archetype isn't a new model; > > it's a statement about putting together pieces from an existing model. > > > > ``` > > ``` > > it's not a misleading statement. I am aware that lot's of HL7 people are > making misleading statements about HL7 modelling - but they are mislead > themselves, and they are generally open to being educated. > > if I can interconvert, therefore it's true that the 2 formats are > presentations of the same concept. ADL is a more natural fit, and > I think that in the long term, most people would prefer to develop > in the tools that arise out of the ADL constructs. But they are > still the same concept > > ``` but there is still the key difference to do with attribute deletions. It could be faked by including a lot of invariants in an archetype to force all such attributes to 0, Void whatever, but we cannot get away from the fact that this is an ugly workaround, nor that the HL7 RIM had to be built in the first place to support it (by containing numerous attributes that only relate to some instances of some subclasses). And the other problem with this is that two distinct RMIMs each containing (say) a clone of the Observation class from the RIM could delete different combinations of attributes (i.e. create 2 new projections on the RIM Observation class); multiply this up to N RMIMs doing the same thing, and M classes. None of this can happen in openEHR. The reason I want to make this clear is simply that potential and actual users of both approaches need to understand what the approaches represent, what the consequences are - and why they are different for software. In openEHR, there is only one schema, forever - that of the reference model. Believe me, if interconversion was easy, we would have done it years ago (when we did in fact try, in concert with senior HL7 people). What you are now able to do is a conversion between formalisms (or parts thereof; RMIMs etc don't have a place to put the meta-data, archetype terminology or code-bindings), which is not the same as a conversion between artifacts. It will be great if the ADL formalism can be used more widely, but please don't imply that a) archetypes and RMIMs now seamlessly interconvert or b) that the methods are really the same in HL7 and openEHR. This will just confuse people. > ``` > > ``` > > > ``` > > Some archetypes and RMIMs are trying to say the same thing however. Is > > reliable machine conversion possible? The key point is that while > > conversion between the formalisms of some part of an archetype and an > > RMIM and vice versa may be possible, conversion between actual real > > archetypes and real RMIMs is not the same thing, due to the reference > > models involved. > > > > ``` > > ``` > > agree that automated conversion between reference models is not (yet) > possible, and agree that the key difference is in the reference models. > This is something we all need to work on. At least we have made > major progress with data types. > > ``` the problem of overuse of coded attributes in HL7 is what killed this kind of effort the last time it was tried - the HL7 people could not produce reliable rules as to when some value went into Act.code and when it went into Act.code.text, and so on. The combinatorial problem quickly grew out of hand due to the number of coded attributes on Act and Act_relationship. I an not saying "don't try", just pointing out the difficulties... > ``` > I suggest as an opening gambit regarding how to progress this that the > OpenEHR reference model corresponds more closely to the HL7 domain models > than to the RIM, and that's the useful point to pursue genuine > interoperability. > > ``` The comparison I have made recently has the following equivalence: - openEHR data types and support model ----- HL7 data types - openEHR data structures ----- (nothing) - openEHR Common IM (~8 patterns) + Demographic model ----- RIM (~2-3 patterns + left hand side) - openEHR EHR IM ----- some mixture of DIMs from patient care, clinical statement pattern, .... I agree with you about the importance of the DIMs - which I had previously under-estimated (and I suspect some HL7 people underestimate). My worry with all of the HL7 models is: how much was modelled the way it was because of the limited language of the RIM, and how much was intended to be exactly that way? Anyway, I think we will be all very interested in the progress you make on this front. - thomas --- ## Post #25 by @grahamegrieve > But\. > \-1\- > The HL7 RIM is a reference model for any sentence\. > The EHRcom reference model defines any document\. > The former will be more difficult to implement generally by writing generic > software, because sentences can express very many nuances of trillions of things\. > The latter is more easy to implement\. The model for any generic document is only > a limited amount of classes and structural codes\. Perhaps the answer is that the reference models are not equivalent\. The openEHR reference model is equivalent to the HL7 DIMs\. The fact that the HL7 DIM's are based on a metamodel with a structural code pattern is both a strength and a weakness when compared with the OpenEHR reference model, which is not based on a seemantic metamodel, only on a technical metamodel \(MOF\)\. So we should not compare reference models, we should compare the openEHR reference model with the HL7 Domain Models > \-2\- > The HL7v3 method, using the RIM as template for further developments, produces > R\-MIMs in a not\-computable way\. they are computable, but not compatible with each other in a computible fashion\. > Each R\-MIM generates an unique xml\-schema needing unique software\. well, I will keep saying this until everyone listens: \* R\-MIM's need not be treated this way \* Archetypes can be treated this way\. Each approach has advantages\. HL7 chose one, OpenEHR chose the other\. Full analysis suggests that HL7 should change on this issue, we are considering this\. > \-3\- > Using the Message paradigm, a community of healthcare providers, together with > the vendors, produce a series of XML\-schema's for a clinical domain\. > In the Archetype \(or Two Level Model\) paradigm only healthcare providers meet to > produce the archetypes/templates\. All vendors have to implement one relatively > simple and stable XML\-scheme based on the EHRcom reference model\. Implementing a reference model is more costly than implementing a few messages with specific models\. Implementing a lot of messages with specific models is more costly than implementing a reference model\. The structural code pattern allows HL7 users to choose either approach, but this has not proved very successful, partly because the nominated reference model is actually the metamodel\. > \-4\- > HL7v3 is based on the philosophy that only the common information model is used > in the exchange structure\. It is system agnostic\. It is not impacting the > proprietary components of the communicating systems\. > EHRcom impacts one or more components is EHR\-systems in order to be able to reap > the benefits of this standard\. The full deployment of EHRcom needs a new layer > in EHR\-systems\. One layer that conditions the archetypes and accompanying data > such that it provides a uniform interface with the other EHR\-SYSTEM components > like the persistence layer, the presentation layer and the business logic layer\. > \(This is why the CEN/tc251 HISA standard is important next to EN13606 EHRcom\) so this is why they have different scope\. But the scopes very clearly have a large overlap > \-5\- > EHRcom is an European standard \(and will become an ISO standard as well\) > European standards play a reserved role in the European Market\. > Only European standards \(or equivalent standards\) can be used in legislation in > Europe and its Member States\. > Several European Directives regulate this in the European Economic system\. > > In view of the first four topics mentioned above, I don't think HL7v3 messages > and EHRcom can be considered equivalent\. they are not the same\. But the focus clearly overlaps\. > In our game of 'EHR\-chess' you will not be surprised to learn that my next move is: > \*/CEN/tc251 EN13606 EHRcom \(openEHR\) deserves to be considered for worldwide > patient safe communication between EHR's and EHR\-systems\./\* > It is a new exciting paradigm\. I could respond with: HL7 V3 is the primary contender for world wide communication between all health systems, including EHR's\. But that's not what I'm here for, we cannot afford to compete and confront\. Instead, my move is about stepping in the direction towards this statement:   The HL7/CEN healthcare standard provides a solid base for everyone who   wishes to communicate and manage information in healthcare\. ok\. my move: If we work together \(i\.e\. our different focuses overlap with common engineering and semantics support, and we can use each others content models\), this will be a net benefit to everyone\. For instance, I note that OpenEHR does not include general business process / orchestration models, and you really need to consider this before systems can usefully communicate\. This is a core interest of HL7\. But OpenEHR/13606 have a focus of managing persisted information \- everyone has to do this, and HL7 is not good here\. So, it's good to work together for everyone's benefit\. We can do this if we share: \* reference models \* constraint pattern expressions \* wire formats So, we can move ahead in each of these areas: \* I have a data types ITS for HL7 V3 which is well cross\-mapped to the OpenEHR    data types\. The differences are mainly due to requirements differences, and    we can use this as a base to move to a single model that everyone shares\.    I am starting to work on the reference model\. \(There is a joint working party    already working the reference model who have made significant progress, some    of the contributers to this are on this list\) \* I can interconvert between R\-MIM's and ADL diagrams\. I have code for this\.    To complete the work, some small changes are needed in ADL and HL7 constraint    methodology\. I have been proposing changes here at Boca Raton for the HL7    methodology, and I have been discussing the changes required in ADL with Tom\.    I believe that they make sense in their own right, not just justified by    harmonization\.    And in Eclipse, we will be working on having a single editor for both    archetypes and HL7 models \* The HL7 wire format is being reexamined\. For technical reasons, a wire format    that closely resembles the OpenEHR wire format is emerging as a front runner\.    \(i\.e\. a single schema at the domain level\)\. This is not an established decision,    it's something that is still being worked on So, in each of the 3 areas, fundamental progress is being made, and, while not complete, progress is accelerating, and being taken seriously by everyone\. I look forward to advancing this even further in Geneva in a few weeks time\. Last point: the most important thing to understand is that both OpenEHR and HL7 are \*very closely\* aligned in goals and methods\. There is some engineering differences\. I wish that important clever people who should know better would stop claiming these differences are significant, and start talking about how these things are nearly the same after all\. Then we can accept that both are flawed, and have useful discussions about how to move forward together\. \(and pigs will fly, I guess, in some cases\) Grahame --- ## Post #26 by @grahamegrieve >> The "subtractive logic" as you call it, is exactly what cADL is\. >>   > > No, it's not \- this is a fundamental misunderstanding\. The subtractive logic of > the HL7v3 methodology is the ability of one model in the chain \(say an RMIM\) to > remove attributes in class A that were defined in the same class A in the > predecessor model \(say a DIM\)\. In cADL, I can say something like this:    attributeName cardinality matches \{0\} matches \{\*\} this is a statement that attributeName cannot be valued in this model\. But attributeName must exist in the reference model, and it is superfluous to say this if some other archetype on which you are based has already said this\. And you cannot add or define attributeName in cADL In an RMIM, you make a statement that attributeName cannot be valued in this model\. AttributeName must exist in the reference model, and it is superfluous to say this if some other RMIM or DMIM on which you are based has already said this\. And you cannot add or define attributeName in DMIMs or R\-MIMS If you want, you can interpret the statement, either in an archetype or an RMIM, as a definition of a new class which has had that value "subtracted", as HL7 does with RMIM's\. This may or may not be a good idea, but doesn't change the fact that what is going on in concept is no different > The models are defined, starting with the RIM, > loaded with attributes that can be deleted \(projected out\) in this way\. you've been listening to someone who's trying too hard to pretend these things are not the same too much; ignore him\. In spite of the fact that I will use "projection" below, I think it's an extremely unhelpful term\. > This isn't a deficiency in object modelling, because it is not part of the > object model I believe that it should be; it's certainly part of Bertrand Meyer's scope for an object model: design by contract\. >> So you invent cADL and >> Hl7 invents Static Model Diagrams, but they both do the same thing, >> and in this regard OpenEHR and HL7 do not follow normal object >> modelling\. You objected to this\. And yes, The reference models for both are normal object models\. But the idea that the value of the construct is found in constraint definitions on the construct is not normal practice\. I believe it's the only game in our town, but it is not normal practice\. I think it should be\. > but there is still the key difference to do with attribute deletions\. It could > be faked by including a lot of invariants in an archetype to force all such > attributes to 0 what's fake about that? We could talk about whether it is good that HL7 constraint statements implicitly prohibit anything not mentioned \- but this is a policy, it doesn't really bear relevance on the question of the concepts > And the other problem with this is that two > distinct RMIMs each containing \(say\) a clone of the Observation class from the > RIM could delete different combinations of attributes \(i\.e\. create 2 new > projections on the RIM Observation class\); multiply this up to N RMIMs doing the > same thing, and M classes\. None of this can happen in openEHR\. really? So I cannot make cADL statements that make different constraints on a reference model class in different archetypes \(or even the same one\)? Of course this is how things work\. If I chose to treat an archetype as a "projection" \- which I could \- then this might be a problem\. If I chose not to treat an RMIM is a "projection", then it's not a problem\. I'm going to keep saying this until everyone listens: the difference is not in what is being done, it's in how the outcome is treated\. > Believe me, if interconversion was easy, we would have done it years ago \(when > we did in fact try, in concert with senior HL7 people\)\. What you are now able to > do is a conversion between formalisms \(or parts thereof; RMIMs etc don't have a > place to put the meta\-data, archetype terminology or code\-bindings\), which is > not the same as a conversion between artifacts\. It will be great if the ADL > formalism can be used more widely, but please don't imply that a\) archetypes and > RMIMs now seamlessly interconvert or b\) that the methods are really the same in > HL7 and openEHR\. This will just confuse people\. the methods are the same, the perception is different\. Agree that RMIM's are missing some things\. They can \- and will \- be changed\. But yes, I don't \(yet\) convert between reference models\. I don't want to imply something different, but the language you have chosen to use is confusing\. what's an "archetype"? Is it an ADL statement against any reference model, or an ADL statement against the openEHR reference model? Please advise me how to describe things so they aren't confusing\. > the problem of overuse of coded attributes in HL7 is what killed this kind of > effort the last time it was tried \- the HL7 people could not produce reliable > rules as to when some value went into Act\.code and when it went into > Act\.code\.text, and so on\. The combinatorial problem quickly grew out of hand due > to the number of coded attributes on Act and Act\_relationship\. I an not saying > "don't try", just pointing out the difficulties\.\.\. sure\. If it was easy, where would the challenge be? And I agree that the structures is going to be one of the more interesting challenge\. Grahame --- ## Post #27 by @thomas.beale Grahame Grieve wrote: >>> The "subtractive logic" as you call it, is exactly what cADL is\. >>>   >> >> No, it's not \- this is a fundamental misunderstanding\. The subtractive logic of >> the HL7v3 methodology is the ability of one model in the chain \(say an RMIM\) to >> remove attributes in class A that were defined in the same class A in the >> predecessor model \(say a DIM\)\. >>     > In cADL, I can say something like this: > >    attributeName cardinality matches \{0\} matches \{\*\} >   Grahame, you can only do this if the reference model already says that the cardinality \(which is only for container types by the way\) is 0\.\.something\. You can't say and attribute value is absent unless the reference model already allows that\. > this is a statement that attributeName cannot be valued in this model\. > But attributeName must exist in the reference model, and it is superfluous > to say this if some other archetype on which you are based has already said > this\. And you cannot add or define attributeName in cADL >   no, that's not right \- the attributeName of course exists in the RM, but if its cardinality is 0\.\.1 or 0\.\.\*, clearly it is allowable for there to be no value in the data\. cADL statements are statements about objects, i\.e\. instances, not models\. > In an RMIM, you make a statement that attributeName cannot be valued > in this model\. AttributeName must exist in the reference model, and it > is superfluous to say this if some other RMIM or DMIM on which you are > based has already said this\. And you cannot add or define attributeName in > DMIMs or R\-MIMS > > If you want, you can interpret the statement, either in an archetype or > an RMIM, as a definition of a new class which has had that value > "subtracted", as HL7 does with RMIM's\. This may or may not be a good > idea, but doesn't change the fact that what is going on in concept is > no different >   see above\. There are no new classes of any kind in ADL archetypes, nor any subtractions, additions or any other modifications to the reference model, because archetypes are not saying anything about models, or classes, they only make statements about instances\. > > The models are defined, starting with the RIM, >   >> loaded with attributes that can be deleted \(projected out\) in this way\. >>     > you've been listening to someone who's trying too hard to pretend these > things are not the same too much; ignore him\. In spite of the fact that > I will use "projection" below, I think it's an extremely unhelpful term\. >   well, he's the most vocal advocate/defender/architect of the RIM, and seems to represent HL7 on the matter\.\.\.and that's how he describes the theory behind the RIM\. >   >> This isn't a deficiency in object modelling, because it is not part of the >> object model >>     > I believe that it should be; it's certainly part of Bertrand Meyer's scope > for an object model: design by contract\. >   that is something else entirely \- DbC statements like in Eiffel and OCL are statements attached to models, defining or modifying their semantics\. Archetypes don't add anything to the model, they say how its instances should be used\. >   >>> So you invent cADL and >>> Hl7 invents Static Model Diagrams, but they both do the same thing, >>> and in this regard OpenEHR and HL7 do not follow normal object >>> modelling\. >>>       > You objected to this\. And yes, The reference models for both are normal > object models\. well, I don't think many people would agree,with respect to HL7 \- I have numerous reports and references to that effect over the years\. And they are right: no\-one builds object models by including all possible attributes in the most abstract classes so that they can be stripped out in "derived" models \- there is not one paper, textbook or other published source that says to do this, and there are many that show why it should not be done\. I will write a cheque for £100 to anyone who can find one that anyone has heard of \(not published by HL7 obviously\), describing why an object model should be built this way\. > But the idea that the value of the construct is found in > constraint definitions on the construct is not normal practice\. I believe > it's the only game in our town, but it is not normal practice\. I think > it should be\. > well constraints on models have been normal since Djikstra and others invented the concepts; it's a pity that only languages like Z, Eiffel and a few others have incorporated them\. In fact, I think we should consider it an aberration that the other programming languages have failed to do something so basic so far\.\.\.\. But now Java has the JML effort, and C\# will finally get design by contract\. But we need to be careful in our understanding \- these contracts are constraints on the reference model; there is no point trying to express domain specific constraints \(i\.e\. business rules\) on instances as contracts, because a\) we don't want that stuff built into the software and b\) there are different sets of constraints depending on the particularities; they have to be separated from the object model and encapsulated each on their own\. I made some points about this difference some years ago\.\.\.\.see http://www.deepthought.com.au/it/ocl_review.html >> And the other problem with this is that two >> distinct RMIMs each containing \(say\) a clone of the Observation class from the >> RIM could delete different combinations of attributes \(i\.e\. create 2 new >> projections on the RIM Observation class\); multiply this up to N RMIMs doing the >> same thing, and M classes\. None of this can happen in openEHR\. >>     > really? So I cannot make cADL statements that make different constraints on > a reference model class in different archetypes \(or even the same one\)? Of course > this is how things work\. yes you can, naturally\.\.\.but since cADL is not defining any classes, or saying anything about the reference model, it's not the same thing \- 2 archetype models are just like 2 LEGO instruction sheets \- they give 2 different ways to put the LEGO pieces together; they don't invent or modify the LEGO pieces\. > If I chose to treat an archetype as a "projection" \- which > I could \- then this might be a problem\. If I chose not to treat an RMIM is a > "projection", then it's not a problem\. >   but \- an archetype isn't, and an RMIM is\.\.\.\.these are both facts \- they are in the formal expressions\.\.\.\. > I'm going to keep saying this until everyone listens: the difference is not > in what is being done, it's in how the outcome is treated\. > And I am going to keep repeating: two different things are being done here: a\) constraining instances \(archetypes\) and b\) creating new schemas in terms of projections of existing classes \(xIMs\)\. There may well be practical solutions to connecting them, but establishing such a solution doesn't change the underlying theory of the two approaches; and neither should we \- the theories are clear\. > >> Believe me, if interconversion was easy, we would have done it years ago \(when >> we did in fact try, in concert with senior HL7 people\)\. What you are now able to >> do is a conversion between formalisms \(or parts thereof; RMIMs etc don't have a >> place to put the meta\-data, archetype terminology or code\-bindings\), which is >> not the same as a conversion between artifacts\. It will be great if the ADL >> formalism can be used more widely, but please don't imply that a\) archetypes and >> RMIMs now seamlessly interconvert or b\) that the methods are really the same in >> HL7 and openEHR\. This will just confuse people\. >>     > the methods are the same, the perception is different\. Agree that RMIM's > are missing some things\. They can \- and will \- be changed\. >   see above \.\.\.\. > But yes, I don't \(yet\) convert between reference models\. I don't want to > imply something different, but the language you have chosen to use is > confusing\. what's an "archetype"? Is it an ADL statement against any > reference model, or an ADL statement against the openEHR reference model? > Please advise me how to describe things so they aren't confusing\. >   I accept any criticism of the above sort \- I know we have to find better ways of explaining things\. To answer your question: \* an archetype is a set of statements constraining the instances of a reference \(object\) model to a particular configuration or set of configurations \* an openEHR archetype is the above, where the reference model is the openEHR reference model hope this helps, \- thomas --- ## Post #28 by @system Dear Graham, This round no next move from me. I call for a time out. This gives time for some reflections: -1- HL7 as an organisation is extremely valuable. We really must preserve this precious resource of healthcare providers, their organisations and Software vendors. -2- This is not to say that everything they thought of is valuable and must be preserved. -3- The same is true for CEN/tc251 but for other reasons -4- Lets say the HL7 v3 community and the CEN/tc251 community are equal. (And I think they are) -5- And that both perceive an internal and external drive to harmonise (As many know I'm in favour of this since I tried to get at a Memorandum of Understanding between CEN and HL7) -6- So far it is my perception that the voice of CEN/tc251, and their not unimportant contributions to medical informatics, was not heard, understood by our American partners. -7- Then the question arises: When the world starts to experience the multitude of difficuties with the HL7v3 RIM and message development method what will we do? Will we start to patch up something that has intrinsic problems? (Do you remember the recent discussion on a HL7 e-mail list. My conclusion was that they don't know the definitions of the major classes of the RIM. Luckily HL7v3 is not deployed that widely, so there are not much legacy systems to reckon with?) Or will we start from a more sound starting point. One that will become an European standard and is on its way to become an ISO standard as well? I reserve my next move until you and Thomas agree on technical details in your interesting dispute. (For the moment I'm in Thomas's corner. I agree more with him than with your position. As said. I wait for your next moves and Thomas' moves in the technical dispute) Have a nice weekend. Gerard ps: In the end we all **MUST** co-operate. Their is only _**one**_ patient with _**one**_ problem that needs our _**undivided**_ attention, care and devotion. The poor sod needs the **best** solution for his problem. -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #29 by @thomas.beale Grahame Grieve wrote: > > ``` > > But. > > -1- > > The HL7 RIM is a reference model for any sentence. > > The EHRcom reference model defines any document. > > The former will be more difficult to implement generally by writing generic > > software, because sentences can express very many nuances of trillions of things. > > The latter is more easy to implement. The model for any generic document is only > > a limited amount of classes and structural codes. > > > > ``` > > ``` > > Perhaps the answer is that the reference models are not equivalent. The openEHR > reference model is equivalent to the HL7 DIMs. The fact that the HL7 DIM's are > based on a metamodel with a structural code pattern is both a strength and a > weakness when compared with the OpenEHR reference model, which is not based on > a seemantic metamodel, only on a technical metamodel (MOF). > ``` This actually isn't as big a difference as you might think. The heavy use of codes in the HL7 model is a way of getting out of statically typing things. The various mood codes for example (originally 6, now 15 I think) are in lieu of using further typing in the model to express the basic differences between observation, recommendation, intention etc. The openEHR model includes type equivalents of some of these codes (although not drawn from speech/act theory) in the Entry model (see [http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html](http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)). They are both ontological commitments, but they are just expressed in different ways. The challenge of static typing is to be careful to express only what is universally true for all instances; the advantage is that you can build software directly from statically typed models. The problem of embedding so many coded attributes in the HL7 model is that it creates a massive uncontrolled combinatorial space - but without other structure. This has to be defined later in the form of DIMs, RMIMs etc, then irrelevant coded attributes masked out, then constraints added on value sets. Ultimately a comprehensible model is possible - but painful, and with limited re-use. > ``` > > ``` > > > ``` > > Each R-MIM generates an unique xml-schema needing unique software. > > > > ``` > > ``` > > well, I will keep saying this until everyone listens: > * R-MIM's need not be treated this way > * Archetypes can be treated this way. > > ``` I actually agree with this at a practical level, even though the different design intentions were clear from the outset. But the problem still remains: the semantics of the reference models. > ``` > > ``` > > ``` > Implementing a reference model is more costly than implementing a few messages > with specific models. Implementing a lot of messages with specific models is > more costly than implementing a reference model. > ``` this is a fair enough statement. The problem is that in health we are clearly in the territory of "lots of messages"... > ``` > ok. my move: > > If we work together (i.e. our different focuses overlap with common engineering > and semantics support, and we can use each others content models), this will be > a net benefit to everyone. For instance, I note that OpenEHR does not include > general business process / orchestration models, and you really need to > consider this before systems can usefully communicate. > ``` this is true. What is there now: * CEN HISA * emerging openEHR service models for EHR, demographics, terminology access and archetype access * state-based process management for Instructions, i.e. medications, orders, procedures. * high-level HL7 HSSP specifications like RLUS etc * older and probably undervalued Corbamed specifications, like PIDS What is nedeed: * CEN Contsys part 2 * more generic inter-enterprise orchestration models, probably in the form of web-service interaction profiles * an accepted standard language for writing distributed workflows. Our approach in openEHR will be to add some small pieces to the reference model as time goes by, principally in the workflow area, as well as service definitions, hopefully mostly extracted from the standards work, and expressed within the openEHR type system. > ``` > Last point: the most important thing to understand is that both OpenEHR and > HL7 are *very closely* aligned in goals and methods. > ``` goals yes.... methods, I think they could hardly be further apart....unfortunately. > ``` > There is some engineering > differences. I wish that important clever people who should know better would > stop claiming these differences are significant, and start talking about how > these things are nearly the same after all. Then we can accept that both are > flawed, and have useful discussions about how to move forward together. (and > pigs will fly, I guess, in some cases) > > ``` well.....some of us people have been trying since 1999 to get this kind of convergence going (by going to HL7 meetings in the US of course). The engineering differences are quite significant; they are the main game to be solved. But it requires commonality on some of the basics (e.g. data types, approach to modelling), and this has been missing. Let's hope that it is changing. - thomas --- ## Post #30 by @williamtfgoossen In een bericht met de datum 15-9-2006 18:56:19 West-Europa (zomertijd), schrijft gfrer@luna.nl: > -7- > Then the question arises: > When the world starts to experience the multitude of difficuties with the HL7v3 RIM and message development method what will we do? > Will we start to patch up something that has intrinsic problems? > (Do you remember the recent discussion on a HL7 e-mail list. My conclusion was that they don't know the definitions of the major classes of the RIM. > Luckily HL7v3 is not deployed that widely, so there are not much legacy systems to reckon with?) > Or will we start from a more sound starting point. One that will become an European standard and is on its way to become an ISO standard as well? This is reversable: When the world starts to experience the multitude of difficuties with the OpenEHR and CEN 13606 and archetype development method what will we do? Will we start to patch up something that has intrinsic problems? Do you remember the recent discussions on the OpenEHR list. My conclusion was that they don't know the definitions of the major classes of the RIM and other technicalities. Luckily OpenEHR / 13606 is not deployed that widely, so there are not much legacy systems to reckon with? Or will we start from a more sound starting point. One that is an International standard and is on its way to become an ISO standard as well? Of course this reversion is just to point to the fact that we are apparently back in our corners and have this dispute that is nonsence and not contributing. I am the last to tell that HL7 v3 is perfect, but will be one of the firsts to tell it is working. I am the last to believe OpenEHR / 13606 is perfect, and wait till I see it work in real practice. In the meantime, we have harmonized and differences (few) and commonalties (biljons) have been determined. In the meantime, we will start working with existing tools, set requirements and improve the tools. I do not care where the tools come from, I care what they can do for the very difficult work of entering, storing and exchanging information about patients and care in a intelligent, semantic interoperable way. I do like HL7 v3 D-MIMs because I see several good working EHR systems based on this. To me, beside philosophical problems (fundamental to limits in human thinking), and technical approaches, it really does not make a difference: make the clinical materials available electronically and make clinicians not have to worry about the technology and transformations behind. Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future. William --- ## Post #31 by @grahamegrieve >> In cADL, I can say something like this: >> >>    attributeName cardinality matches \{0\} matches \{\*\} >>   > > Grahame, > > you can only do this if the reference model already says that the > cardinality of course >> this is a statement that attributeName cannot be valued in this model\. >> But attributeName must exist in the reference model, and it is superfluous >> to say this if some other archetype on which you are based has already said >> this\. And you cannot add or define attributeName in cADL >>   > > no, that's not right \- the attributeName of course exists in the RM, but > if its cardinality is 0\.\.1 or 0\.\.\*, clearly it is allowable for there to > be no value in the data\. cADL statements are statements about objects, > i\.e\. instances, not models\. ok, I'll rephrase: This is a statement that attributeName cannot be valued in an instance that conforms to this constraint\. But attributeName must exist in the reference model, and it is superfluous to say this if some other archetype on which you are based has already said this\. And you cannot add or define attributeName in cADL This is a statement that attributeName cannot be valued in an instance that conforms to this model\. But attributeName must exist in the reference model, and it is superfluous to say this if some other \*IM on which you are based has already said this\. And you cannot add or define attributeName in an \*IM If you want, you can interpret the statement, either in an archetype or an RMIM, as a definition of a new class which has had that value "subtracted", as HL7 does with RMIM's\. This may or may not be a good idea, but doesn't change the fact that what is going on in concept is no different so, you say: > There are no new classes of any kind in ADL archetypes, nor > any subtractions, additions or any other modifications to the reference > model, because archetypes are not saying anything about models, or > classes, they only make statements about instances\. And I say that this is equally true about archetypes and \*IMs, and you can choose, if you want, to create schemas or class models from either\. HL7 chooses to\. OpenEHR doesn't\. > that is something else entirely \- DbC statements like in Eiffel and OCL > are statements attached to models, defining or modifying their > semantics\. Archetypes don't add anything to the model, they say how its > instances should be used\. So, an archetype is not a definition of semantics for how to use a model in a particular context? > well, I don't think many people would agree,with respect to HL7 \- I have > numerous reports and references to that effect over the years\. And they > are right: no\-one builds object models by including all possible > attributes in the most abstract classes so that they can be stripped out > in "derived" models you do\. tell me that this isn't how openEHR works? You define everything you will need in the reference model and strip it out from the instances using archetypes >> If I chose to treat an archetype as a "projection" \- which >> I could \- then this might be a problem\. If I chose not to treat an RMIM is a >> "projection", then it's not a problem\. >>   > > but \- an archetype isn't, and an RMIM is\.\.\.\.these are both facts \- they > are in the formal expressions\.\.\.\. So, I can see that I'm not getting anywhere\. I am claiming that this difference is a feature of how these things are used, and hoe they are presented, not what they are\. And that you can use either in either way\. Am I wrong to claim that you \*can\* use either in either way? \(I am not claiming that anything is useful, only possible\) You told me that you could a schema from an archetype\.\.\.\. And, if you remember, we spoke about why this would be useful and how it would be limited \- they are exactly the same issues that HL7 V3 implementers face today Grahame --- ## Post #32 by @grahamegrieve > I call for a time out\. time out is good\. I'm about to hit the road for a while I agree with \#1 \- \#6 > When the world starts to experience the multitude of difficuties with > the HL7v3 RIM and message development method what will we do? keep watching, we will find out next meeting\. Grahame --- ## Post #33 by @grahamegrieve Last email for a little while > This actually isn't as big a difference as you might think\. The heavy use of > codes in the HL7 model is a way of getting out of statically typing things\. The > various mood codes for example \(originally 6, now 15 I think\) are in lieu of > using further typing in the model to express the basic differences between > observation, recommendation, intention etc\. yes, this coding pattern is very troublesome\. It's a good thing I like challenges huh? I will be happy, in this discussion, if we can accept that the real differences we must master are our philosophy and reference models \(which are tightly tied together\); these are real differences\. We should not ignore the engineering differences \- but these can be solved if we want > this is true\. What is there now: > \* CEN HISA > \* emerging openEHR service models for EHR, demographics, terminology access and > archetype access > \* state\-based process management for Instructions, i\.e\. medications, orders, > procedures\. > \* high\-level HL7 HSSP specifications like RLUS etc > \* older and probably undervalued Corbamed specifications, like PIDS and the HL7 v2 and HL7 v3 event models\. yes, we need to work together on this\. and there is finally meaningful traction on this\. Not easy, never easy to make progress, but the glaciers are moving\. Grahame --- ## Post #34 by @thomas.beale Grahame Grieve wrote: > ``` > So, an archetype is not a definition of semantics for how to use a > model in a particular context? > > > ``` sure - how to _use_ it, i.e. how to use instances obeying it..... > ``` > > ``` > > > ``` > > well, I don't think many people would agree,with respect to HL7 - I have > > numerous reports and references to that effect over the years. And they > > are right: no-one builds object models by including all possible > > attributes in the most abstract classes so that they can be stripped out > > in "derived" models > > > > ``` > > ``` > > you do. tell me that this isn't how openEHR works? You define everything > you will need in the reference model and strip it out from the instances > using archetypes > > ``` no. We don't do that at all. In HL7, the major classes are full of attributes (Act has 22 of them) that are only there to support some derived classes down the specialisation tree, as created by the refinement methodology. There are quite a few in Entity that clearly don't sensibly apply even to all the RIM subclasses of Entity, let alone all the subclasses created via cloning in RMIMs. You won't find any classes with anything like this number of attributes in openEHR. There are 2 key differences in the approach: - most of the attributes in Act (for example) do not have any meaning for all or even most instances of all or even most classes descending from Act. In openEHR, and normal object modelling, this is not the case; any attribute you find in an abstract parent class has meaning for all descendant classes and (in general) all instances of all those classes. There are some, but not many optional attributes in openEHR. Nearly everything is optional in the HL7 Act class. - you have to think of all the attributes you might need in any descendant class from Act, in advance, and put it in Act (i.e. in the RIM). This is clear on inspection, and the designers of the RIM have stated this as being the case. This means that you have to know all possible attributes in advance, since derived "classes" cannot add, as in normal OO, but are instead "projections" (i.e. like a select statement of attributes) on the original class. This is the consequence of the subtractive logic; object modelling is extensional. You don't have to think of everything in advance. Clearly no-one can ever succeed 100% at this, so it is a deep problem for RIM and models based on it. There is no escape from the fact that with the RIM approach, you have to have it all right in the beginning. In normal OO modelling, you can always extend descendant classes, which is what happens in openEHR, and what will continue to happen as more pieces of the reference model are (slowly) added. > ``` > > ``` > > ``` > > So, I can see that I'm not getting anywhere. I am claiming that this > difference is a feature of how these things are used, and hoe they are > presented, not what they are. And that you can use either in either way. > > Am I wrong to claim that you *can* use either in either way? (I am not > claiming that anything is useful, only possible) > > You told me that you could a schema from an archetype.... > And, if you remember, we spoke about why this would be useful and > how it would be limited - they are exactly the same issues that HL7 V3 > implementers face today > > ``` well, we could generate schemas from archetypes ...as we have said - but they would be purely generated artifacts, never to be seen by human eyes, and never to be the subject of any design work. The challenge with doing this is: you instantly start creating data that conform only to that schema; it prevents Observations from two different archetypes (e.g two different path test archetypes) just conforming to the main reference model schema. The DSTC tried this approach about 4 years ago, and gave up....for the EHR. Where it can make sense is if we create such schemas and just give them to e.g. path labs and other message sources. But the instance data for such schemas should never be persisted in that form, it should always be converted to the reference model - based form, to allow proper longitudinal querying in the EHR. As long as this rule is followed, it makes good sense, and constitutes an archetype-compatible basis for messages.... Probably you are right - I continue to underestimate / forget the interest in doing it this way, since it is contrary to distributed object thinking. But it is nevertheless attractive to some people to just work off an XML-schema. We just have to be aware of the danger: as soon as anyone starts persisting such messages in a database, the story is over. - thomas --- ## Post #35 by @thomas.beale Grahame Grieve wrote: >   >> this is true\. What is there now: >> \* CEN HISA >> \* emerging openEHR service models for EHR, demographics, terminology access and >> archetype access >> \* state\-based process management for Instructions, i\.e\. medications, orders, >> procedures\. >> \* high\-level HL7 HSSP specifications like RLUS etc >> \* older and probably undervalued Corbamed specifications, like PIDS >>     > and the HL7 v2 and HL7 v3 event models\. > sorry, I should have included those as well\. I have a reservation that they seem too pre\-defined, and the real world just constantly throws up exceptions, but I will be guided by others with more experience with these models\. \- thomas --- ## Post #36 by @system Dear William, Either the brave Dutch are stupid or very clever to become almost the only nations on this earth to vote negative on: the CEN/tc251 EN13606 EHRcom and HISA standards. I know one thing for certain. Based on the openEHR specification in TNO project we have one working implementation from Sweden using Java and one from Australia using .Net. And besides openEHR and CEN/tc251 are based on several working implementations produced in many European projects. Not only the theoretic foundation is in order, the implementations are there, and they work as claimed. It can be proved this solutions are scalable. I know that there are parties that started to implement HL7v3 messages on a large scale and encountered scalability problems. There parties are changing there point of view and are moving towards CEN/tc251 EHR related standards. To read recently in a HL7 e-mail list a discussion dealing with the definitions used in HL7 with respect to several of the founding classes of the RIM (Entity and Act) and the confusion in the documentation is a tell tale example of only one of the serious problems in the HL7 community. And all this after 10 years of work and the production of tons of documentation that can not be printed. You can reverse any statement I make. You can decide not to believe any statement I make, as you and several of my country fellow man did when we were discussing EN13606 EHRcom, lets see how history will prove who is right and who is wrong. So we stop this debate and see how things evolve in time. In the end what matters is, not only that the healthcare sector is able to express what they want, but can it Plug-and-Play be implemented without reprogramming. And then I'm confident that openEHR and CEN/tc251 EHRcom plus HISA will provide just this, because it was in our requirements, also, from the start. I agree. There is only **one** patient, with **one** problem that needs our **unified** attention and devotion. So we have to co-operate. But we have to continue to discuss and provide arguments and listen to the arguments given. Instead of attacking persons, as I have been able to observe several times it to happen in the Netherlands. Lets start the real debate. Patients and healthcare providers need real solutions that empower them. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #37 by @Randolph_Neall I'm a .Net developer in the U.S. researching development of EHR. I've been absolutely fascinated by the recent debate between advocates of HL7 and openEHR. For me it was hugely informative and I'm glad it all happened. You don't learn this stuff just be reading the papers from each community. Since I'm not sufficiently acquainted with all the details of either system I could not follow each nuance of the argument. But among the things I'm taking away from this is that HL7 involves a complex and ever-changing schema at the DB storage level, something that worries me. I did not hear a rebuttal of this point from the HL7 side. Randy Neall Veriquant, LLC tel 828-685-1302 fax 828-685-1957 [randy.neall@veriquant.com](mailto:randy.neall@veriquant.com) --- ## Post #38 by @system Dear William, One very important point I forgot to make: You wrote: **Any discussion in favour of one and against another approach is going back to the trenches of WW1 where we would like to work towards the future.** **What you write is that any discussion pro or contra a point of view will lead to a kind of war and prevents good results in the future.** This line of reasoning is strange for a person active in academic worlds with a PhD thesis in his CV. A discourse pro and contra a point of view is the essence of science because it leads to better understanding of our complex world. **This line of reasoning of yours makes me feel uneasy because this way of argumentation is one seen in religious fanatics that don't want any real discussion.** With regards, Gerard Freriks -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #39 by @William_E_Hammond Gerard, I am amazed at the comments to your collegue. We are making great strides in bringing ISO/CEN/HL7 together with the potential of taking a step beyond even harmonization. I am in favor of pro and con discussion. As I read your earlier mail, I interpret those remarks as saying we don't need HL& and don't even look at HL7. I don't think such remarks encourage a position of cooperation. I would sugget to Randy that he look at both HL7 and openEHR. Both have components in their favor and both have cons. It is my believe that working together gets us further along the road. I don;'t fully know what the referral is to an ever-changing schema at the DB storage level. CCD is becoming the recommended standard for the exchange of data in HL7. On the other hand, I think the work with archetypes brings a lot into the equation. Competition is good at some times and destructive at others. Incrediably stupid doesn't sound like a scientific argument. I am sorry for these remarks, but I needed to express them. Ed Hammond > > **"Randolph Neall" **
Sent by: openehr-technical-bounces@openehr.org

09/15/2006 05:08 PM
Please respond to For openEHR technical discussions

|
To: "For openEHR technical discussions"
cc:
Subject: Re: Antw: Re: EHRcom/openEHR the new exciting paradigm | > - | - | - | I'm a .Net developer in the U.S. researching development of EHR. I've been absolutely fascinated by the recent debate between advocates of HL7 and openEHR. For me it was hugely informative and I'm glad it all happened. You don't learn this stuff just be reading the papers from each community. Since I'm not sufficiently acquainted with all the details of either system I could not follow each nuance of the argument. But among the things I'm taking away from this is that HL7 involves a complex and ever-changing schema at the DB storage level, something that worries me. I did not hear a rebuttal of this point from the HL7 side. Randy Neall Veriquant, LLC tel 828-685-1302 fax 828-685-1957 [randy.neall@veriquant.com](mailto:randy.neall@veriquant.com) --- ## Post #40 by @Gavin_Brelstaff As an unqualified lurker in these groups I must say I was v\. impressed by the breadth and depth of knowledge of HL7 that Thomas Beale has shown in these recent discussions \- it gives me even more confidence in the principled basis behind openEHR and the openess of the openEHR people in their responses\. my2cents \\Gavin Brelstaff CRS4 Italy William E Hammond wrote: --- ## Post #41 by @williamtfgoossen In een bericht met de datum 15-9-2006 22:21:23 West-Europa (zomertijd), schrijft gfrer@luna.nl: snip snip: > I agree. > There is only **one** patient, with **one** problem that needs our **unified** attention and devotion. > So we have to co-operate. > But we have to continue to discuss and provide arguments and listen to the arguments given. > Instead of attacking persons, as I have been able to observe several times it to happen in the Netherlands. > > Lets start the real debate. > Patients and healthcare providers need real solutions that empower them. > > Gerard I agree with several comments on HL7 v3, there are solutions for that underway. I agree that CEN 13606 / Open EHR and HL7 v3 have their advantages and disadvantages. I agree that we can work together I agree that there is a lot to be done I agree that both approaches have led to implementations and also to the determination of problems in the technological approach. I disagree that we should discuss this from a view point of superiority of one approach against the other. That is the WW 1 approach. That WW1 'for or against' approach will not lead to working solutions. My comments are based on believing that your points 1-6 are sensible to discuss and find solutions. Your comment 7 is not useful and I would suggest you to refrain from the pro - con discussion. For the one patient with always more problems (there is no situation in health care where a patient has only one problem, he might have one disease, but that will always have more than one interelated problems) that need our dispersed attention to tackle this in a holistic way. So the 'standard' approach is: one patient with one or more diseases and none to many associated problems / complaints and none to many associated nursing diagnoses / allied health problems and one to many activities for the disease (s) and one to many activities for the associated problems (the minimum, so always one has to be there is to monitor the onset of a potential problem) and one to many activities for the associated nursing diagnoses / allied health problems. Definitely this is is with respect to workflow a difficult non-linear process of care delivery and of changes of the disease(s) and the different problem situations. Thus we need to be able to have a system that can track what these changes are, and what the status of this set of mixed activities is. We must also be able to exchange this in the multitude of systems available in health care that will last for several decades. I am pretty sure that I can deal with these complex situations in HL7 v3 speak. I have not seen examples of these complex care situations in 13606 speak since that is missing examples from health care with this respect. Perhaps we need to work more from the clincial perspective and determine the requirements and from there to the technical bits. William --- ## Post #42 by @williamtfgoossen In een bericht met de datum 15-9-2006 23:15:45 West-Europa (zomertijd), schrijft randy.neall@veriquant.com: > Since I'm not sufficiently acquainted with all the details of either system I could not follow each nuance of the argument. But among the things I'm taking away from this is that HL7 involves a complex and ever-changing schema at the DB storage level, something that worries me. I did not hear a rebuttal of this point from the HL7 side. I am not a specialist on this, but I believe it is possible to have a quite simple DB schema based on HL7 v3. Difficult parts include the Entity parts (person, patient, organisation) because the entries in fields will change for some and not for other (e.g. changing addresses, phones etc. relationships between entities are handled via roles: that is not changing. participation from a role in activities are not changing. Of course there are different kinds of participation that change, but that is doable with coding then there are acts that have relationships with other acts, identifiers, moodcode and status codes, as are codes, times and where the act is an observation: there is a value. These parts of the RIM and D-MIMs have been stable for quite a while. Key of Act storage is to store the code for the act, the time, the author (via participation / role relationships), the mood (request, promise plan, carried out) and the status (activive, obsolete, competed). These things have not changed in principle. However, the D-MIMs derived from RIM have changed in those domains where development is ongoing. For some implementers it means for instance that the condition class cannot be used anymore. Instead we work with a problem list allowing activities to be associated on problem level and not on 'condition' level. Condition is changed to an observation. Part of this is because not all components of the HL7 v3 standard are ready now. Early implementers of work in progress thus will face changes that affect their developments. For the Netherlands national ICT project we include the industry in the work in progress and discuss this situation with them before starting and during development and balloting of standards. To prevent too many changes we have now the draft standard for trial use DSTU that allows a couple of years fixation of the standard, testing, finding out the problems, revising and then develop the final standard and ballot that. William Goossen --- ## Post #43 by @gordon.tomes Heath *Are there people interested in providing clinical scenarios and data to assist in the requirements and content gathering process to be used in clinical workflow simulations? How can we initiate and progress this kind of activity and investigation?* Try contacting NICS - the National Institute of Clinical Studies http://www.nicsl.com.au/asp/index.asp They may be interested in assisting with this work. Gordon Tomes Projects Director Acute Care Division Department of Health and Ageing (MDP 63) PO Box 9848, Canberra ACT 2601 Ph 02 6289 5081 | Mobile 0423 024 922 | Fax 02 6289 7630 2006 Biennial Health Conference Exploring and debating acute care provision 14-16 November, Sydney, Australia for the latest information visit http://www.healthconference.com.au/ > > **"Heath Frankel" **
Sent by: openehr-technical-bounces@openehr.org

15/09/2006 12:04 PM
Please respond to For openEHR technical discussions


|
To: "'For openEHR technical discussions'"
cc:
Subject: RE: Sources of information on HL7 EHR/OpenEHR | > - | - | - | Gerard, Interesting you raise this topic as it is becoming an interest of mine to start investigating the use of openEHR instructions to support the documentation requirements of clinical workflows such as medication prescriptions, dispense and administration, and referrals. The existing work of ContSys could certainly assist in this but being a techo, I need some clinicians to assist in developing these requirements and my Ocean clinician colleagues are already over extended. As you know, Ocean has and continues to develop the tools to support a simulation of these kind of clinical workflow scenarios and are looking for ways to gather more and varied clinical content to populate and test the OceanEHR suite. Are there people interested in providing clinical scenarios and data to assist in the requirements and content gathering process to be used in clinical workflow simulations? How can we initiate and progress this ki! nd of activity and investigation? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: [heath.frankel@oceaninformatics.biz](mailto:heath.frankel@oceaninformatics.biz) --- ## Post #44 by @thomas.beale Williamtfgoossen@cs\.com wrote: > > So the 'standard' approach is: > > one patient with > one or more diseases > and none to many associated problems / complaints > and none to many associated nursing diagnoses / allied health problems > and one to many activities for the disease \(s\) > and one to many activities for the associated problems \(the minimum, > so always one has to be there is to monitor the onset of a potential > problem\) > and one to many activities for the associated nursing diagnoses / > allied health problems\. > > Definitely this is is with respect to workflow a difficult non\-linear > process of care delivery and of changes of the disease\(s\) and the > different problem situations\. > Thus we need to be able to have a system that can track what these > changes are, and what the status of this set of mixed activities is\. > We must also be able to exchange this in the multitude of systems > available in health care that will last for several decades\. > > I am pretty sure that I can deal with these complex situations in HL7 > v3 speak\. I have not seen examples of these complex care situations in > 13606 speak since that is missing examples from health care with this > respect\. Hi William, the workflow aspects of the above need workflow languages and service models to support multi\-enterprise choreography\. There are guideline and workflow languages \(not provided by HL7 or openEHR\), and the beginnings of models for choreography coming from WfMC and other places\. I can't think of much HL7 provides in this area\. But the main question with respect to workflow is: what needs to be automated? Humans are far better at performing real\-world tasks than machines, due to their ability to handle exceptional cases\. Mostly what we need to solve right now is: \- clinical content \- simple workflow around medication prescription and management \- some basic workflow around admission, discharge, referral Other workflows are wonderful problems for computer science theses, but mostly are done better and more economically by human beings at the moment\. If we just get clinical content solved, that will be a huge step\. > > Perhaps we need to work more from the clincial perspective and > determine the requirements and from there to the technical bits\. exactly\.\.\. \- thomas --- ## Post #45 by @Dr_LONJON_Roger Hello, I am completely okay with T Baele\. We have in France a comparable debate with the DMP project \(Personal Medical record\)\. The physician needs information under shape of documents\.He/it wants them quickly and sure being that the content is reliable to be able to take a decision or to prescribe a treatment\. For he/it is asked to the physician to be the supplier of data to put medicine in a system of information for decision\-makers, payers or political\. It is another probléme\.\.\.\.\. Dr R LONJON france Selon Thomas Beale <Thomas\.Beale@oceaninformatics\.biz>: --- ## Post #46 by @williamtfgoossen In een bericht met de datum 18-9-2006 10:45:04 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz: > There are guideline and > workflow languages (not provided by HL7 or openEHR), and the beginnings > of models for choreography coming from WfMC and other places. I have looked into the WfMC materials, and the basic process flow descriptions are currently met with the HL7 v3 Care Plan. (This is not a point if HL7 can do, it is the point that it is possible to define the clinical process using a standard, I think it is transferable to OpenEHR archetype as well). The key here is the use of the following mood codes: definition will tell you wat according to best practice or evidence base should be done for a patient with problem x. (including monitoring of observations, tests, meds etc). The OpenEHR template specification that links archetypes could perhaps do similar things. intent mood helps the clinician to carry over from guideline into the care plan what is necessary for individual patient P. Thus the set of data required can be determined, and it can be justified why items are not carried from guideline to plan. (E.g. you do not female things for a male patient). Then if some professional wants to order a observation this can be done with request. e.g. the doctor askes the nurse to measure the blood pressure 4 times a day. In the Goal mood, the expected value can be set, e.g. the expected value of BP in a week should best be 130/90. the observatoin is carried out say 7 days 4 times a day leading to 7 x 4 = 28 observations in event mood. The statement collecter allows to trend this. The comparison of goal versus the event(s) trends, or the last value of day 7 allows to determine if the goal is met (conclusion being then the 29th observation). The derivation method allows to specify also workflow rules like: do BP measurements until 4 x < 130/90 or similar as a criterion for the do X until Y workflow standard. I am not telling this is best handled in HL7 v3, I just want to say that a] it is possible to express clinical meaningful workflows, that at EHR level are pretty handy for a nurse to pop up on the worklist every 6 hours, and that it is possible to exchange the semantics of such a workflow / careplan via a message. Yes, this is interesting stuff and needs a lot of work. William --- ## Post #47 by @grahamegrieve >>> this is true\. What is there now: >>> \* CEN HISA >>> \* emerging openEHR service models for EHR, demographics, terminology access and >>> archetype access >>> \* state\-based process management for Instructions, i\.e\. medications, orders, >>> procedures\. >>> \* high\-level HL7 HSSP specifications like RLUS etc >>> \* older and probably undervalued Corbamed specifications, like PIDS >>>     >> >> and the HL7 v2 and HL7 v3 event models\. >> > > sorry, I should have included those as well\. I have a reservation that > they seem too pre\-defined, and the real world just constantly throws up > exceptions, but I will be guided by others with more experience with > these models\. yep, they are\. but 90/10 rule, they are very useful and they are proven to cover 90% so worth considering\. Grahame --- ## Post #48 by @Heath_Frankel William, There are still a few missing links in the V3 Care Plan model in regard to work flow modelling, some of which are supported in openEHR and others that are left to more dedicated work flow modelling and tooling, deliberately. The key issue in the V3 Care Plan is the lack of work flow decision points. The event criterion (EVN.CRT) mood is only supported on the Observation Act in the Clinical Statement and hence the Care Plan model, therefore you can not model decision points that are not Observations like Procedures and Substance Administrations, which I would have thought to be rather key. This is not to downgrade HL7, just to correct your statement that these can be done in HL7. It is true that it could be done but not with the current Care Plan Clinical Statement model. The second issue is the use of derivation expression. This is an interesting attribute that is just a catch all that is not already supported. So we can do some modelling using RMIMs but then what we can't say we put into derivation expression but then what is the language to use here? HL7 doesn't have an endorsed constraint language (although it has a standard for one, GELLO) and it also doesn't have work flow language. So to actually make what you suggest can be done in HL7 you need to invent your own rule expressions. My main issue here is not that they don't have these, but that you have more than one way of representing these. To build software on this you need to be able to process the HL7 event criterion and the derivation expressions in what ever invented language you used. That doesn't seem to be overly interoperable. As you said it's not perfect. openEHR has drawn the line and said, we will not reinvent the wheel on Work Flow. openEHR will provide the data required, record the states and the recommendations but not the actual rules used by software. It is intended to use existing work flow engines in conjunction with an openEHR repository. Although, I understand that there might be a future effort to develop an abstract model of work flow that work with archetypes that could be mapped into the existing Work Flow models and engines. Now this needs to be proven and worked through and as the original Author of the HL7 V3 Care Plan I am very interested in working this through in openEHR. The HL7 V3 Care Plan model is just to cumbersome even though I agree that the mood code did allow for a very powerful representation of a Guideline and Care Plan. I just don't think we can reliably write software to process those models within the development budgets that we have in Healthcare, even in the UK, and certainly not in Australia. Considering the amount of money spent in the UK (I don't know the Netherlands budget) on building an EHR repository which is nothing more than a message store using V3 compared with what we have achieved with a very small team to build an openEHR repository, I suspect we can extrapolate this into clinical work flow processing. It is this cost of implementation (not that it can't be done, but how much it costs to do it) that has turned me away from HL7 V3 whereas the more I do with openEHR the more I am amazed how easy things are to implement. Again, I didn't want to beat up on HL7 V3, but I did want to present my experience being someone that is intimate with both sides of the fence and up until recently sat on the fence but I am certainly getting blown to one side where the implementation experience is more favourable. And on a final note, the CEN 13606 based RMIM I developed that was the cyclone that hit me considering you need an A3 page to represent something that fits on an A4 page in UML, just imagine if we represented HL7 V3 models in UML :>. And there are so many issues that HL7 still have not solved around versioning, attestation, templates, term bindings and queries. I really do hope that we can collaborate in a two-way exchange. As Gerard mentioned, there are agreements to collaborate with HL7 but that presently appears to be one-directional and it would be a nice change if HL7 parties begin actively participating the development of knowledge artefacts in openEHR/CEN space. Now I know there is an initiative in the US to trial this but I wonder if the likes of yourself could start getting deeper into the Instruction model and how it will work for care planning and make an objective assessment between the two approaches. We don't have enough people that are fluent in both and those that are get caught up in time wasting religious debates. I think you said it a couple of time, we need to determine what the requirements first, but we never get to do this because we argue about it it can or can't be done in a particular technology. I know the archetype and template tools don't support the requirements gathering you require but we should have an archetype repository that is able to store additional meta-data fairly soon. There is nothing wrong using Word and Excel as you are now. What we need is equivalent openEHR archetype for each of your Care Statement RMIMs and in your mapping spreadsheet a couple of columns for the openEHR archetype mappings. Once we get the process right we can then develop the tools to support it. BTW, a member of my development team (who was a obstetrician) is going through the process of developing a pregnancy clinical scenario (mega storyboard) and mapping the data element and sample data into archetypes. I wonder of you would be interested in working with her or at least sharing your experiences and current process? Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 fax: +61 (0)8 8223 2570 mb: +61 (0)412 030 741 email: [heath.frankel@oceaninformatics.biz](mailto:heath.frankel@oceaninformatics.biz) --- ## Post #49 by @grahamegrieve ok, we have real convergence here\. OpenEHR works exactly like HL7 \- define a reference model with all the needed semantics, and then refine things away in constraint models \(and use the refinements as a basis for composition\)\. So the principle is the same\. We can generate \[class models|schemas|wire formats\] from constraint patterns\. Doing so has benefits and costs\. The same benefits and costs in either HL7 or OpenEHR\. And one of the clear costs relates to persistence\. I think we need to search for a better way, but that's not going to happen in the short term\. But the OpenEHR & HL7 reference models are quite different\. In most parts, the HL7 reference model is more abstract \(Which is way Act gets 22 attributes\)\. So harmonising between the reference models is going to require actual change rather than adroitly altering perspectives, as with data types and the constraint model things\. This will be hard, and painful\. And it must involve compromise, so this is when we find out who really values collaboration\. And we don't want to take away the real benefits that OpenEHR has in the process \(same for HL7\) Grahame --- ## Post #50 by @ognian.pishev Grahame, One of the theoretical difficulties of the debate that you are contributing so eloquently to is to separate methods proper to computing from methods defined by domain specificity\. Object\-oriented programming, modular design, abstract data types, etc\. are fundamental principles whose existence does not follow from any particular domain features\. They lead to better information modelling in terms of architecture, computational semantics and have been adopted as the best engineering methodology to create information processing systems\. The abstractions that bridge the gap between computing and domain\-driven modelling have to be able to represent in machine processable form the business objects we are dealing with\. What you are doing in this case is less important than what you are doing it to\. The marriage of the two strands does not deny their individuality but produces an offspring that blends their essential features in an organic way\. openEHR contains RECORD in its name as the basic abstraction\. The RECORD is a container structure that has well defined computational semantics \- data entry is structured in the form of compositions that may be of different type \(instruction, observation, etc\.\) because of differences in computing requirements \- data representation, etc\. Thus we have a model of a record \(document\) management system which at its highest level is generic\. However, its type system is geared towards the faithful representation of information in the health care domain with the goal of producing a shared longitudinal patient record\. HL7 as the name attests is based on the messaging paradigm\. The MESSAGE has been historically the modelling abstraction that defines HL7\. Thus, we have to ask ourselves, which root abstraction fits better the twin criteria of clear and purposeful computational semantics and faithful representation of domain specifics\. You said: > ok, we have real convergence here\. > OpenEHR works exactly like HL7 \- define a reference model > with all the needed semantics, and then refine things away > in constraint models \(and use the refinements as a basis for > composition\)\. So the principle is the same\. \(I have the feeling that you are thinking of HL 7 V4\.0\) Convergence is a really strong statement\. I understand your motivation and your honest desire to overcome the gap between openEHR and HL7\. However, one has to be equally honest in appraising the two approaches and their results\. openEHR doesn't "work exactly like HL7"\. A brief look at the history of the two would show that while openEHR has always been based on sound software engineering and knowledge modelling principles, HL7's effort to a reference model to its messaging structures is not necessarily a product of organic development, hence th gap between version 2 and version 3\. openEHR does define a reference model with all the needed computational semantics but leaves domain\-specific knowledge modelling to the second level of its methodology \- archetype modelling\. Implementation efforts have clearly shown openEHR's ability to produce clean clean computational models that enhance domain\-specific semantic interoperability first and foremost throught the strict enforcement of the separation of concerns between information modelling and knowledge representation\. The two sides click together at run\-time in a very efficient and effective way\. This is not refining things away in constraint models\. The fundamental difference is how one deals with modelling or how one uses abstraction\. "Abstraction means to strip away the superficial or incidental aspects of a thing and to reveal its most important aspects, or essence, aka theory, hypotheses\. Abstraction is important and can lead to deeper \(beyond surface understanding \) of things\. Abstraction can also go wrong\. There are different ways to abstract\. How do we test whether our abstractions \(theories, hypotheses\) are right or wrong?" \(to quote a good blog: http://billkerr2.blogspot.com/2006/08/ascending-from-abstract-to-concrete.html). The key to using abstraction in theoretical modelling is to understand how one can "ascend from the abstract to the concrete\." I don't think constraining and refining actually play such an important role in the design process\. The same blog: "Marx talked of "ascending from the abstract to the concrete" which on the surface can seem rather absurd\. How can a concrete view of reality be superior to a more abstract view? We all know that science takes us beyond the surface appearance of things and proposes deeper explanations that are not immediately apparent\. And anyone who has studied child development knows that initially children view the world in a "concrete" way and as they become able to think better they become capable of thinking more abstractly\. So isn't abstract thinking more advanced than concrete thinking? The difficulty arises from confusing the Marxist idea of "the concrete" with the idea that what is concrete is that which is easily and immediately perceived via the sense organs \- ie the surface appearance of things\. \(note: the whole idea of anything being "immediately perceived" is in any case incorrect\. Perception always involves some cognitive processing \)\. However what Marx meant by "concrete" was not what is meant by the pedagogical distinction between concrete and abstract \(or formal\) thinking\. Marx's use of the word "concrete" has to do with the notion of truth and is not related to the idea of concrete thinking as child\-like and primitive\. To ascend from the abstract to the concrete means to move from the initial ability to abstract away from surface appearance \(via everyday and relatively easy generalisations and simple concepts\) toward a richer and more accurate view of concrete reality\. This does involve abstraction \- but it is abstraction that is on its way to a richer and more concrete \(truthful\) world view\." You don not find the richer and more truthful world view through constraining and refining\. You have two processes at work: the first one is maintaining valid and verifiable data structures that exist within the type system of your information model; the second one deals with concrete instances of data and information from the clinical world that live in your software system, their machine processable nature is defined by computer semantics and platform specificity but their meaning is not\. The concrete clinical notions modelled via archetypes are thus something more than just a constrained pattern\. These produce concrete instances, objects much richer in content than the abstract model whose elements they represent\. The trick is to accomplish this ascent seamlessly within your defined universe on the basis of a stable single view of that universe\. Your knowledge model represents the domain\-specific semantics your are dealing with and it will exist with or without an underlying computational system\. But machine processing requires that we have a working system even when our knowledge acquisition process is ongoing\. To sum up \- information models are based on abstractions and data types chosen because of their computational semantics and suitability to faithfully represent instances of domain\-specific business objects\. The latter derive their meaning from the theoretical \(clinical\) body of knowledge and the only information processing constraint is that they be in a machine computable form, that is, they do not break information model and the sharing of data between system\. Archetypes represent concrete reality as machine processable entities that co\-exist in the same knowledge universe\. This universe is open to future study and representation\. What is important in openEHR's view of the world is to abide by the open/closed principle which means that our models should be closed in a sense that they can work today while leaving open the system boundaries for future extension \(sic\!\)\. > We can generate \[class models|schemas|wire formats\] from > constraint patterns\. Doing so has benefits and costs\. The > same benefits and costs in either HL7 or OpenEHR\. And one > of the clear costs relates to persistence\. I think we need > to search for a better way, but that's not going to happen > in the short term\. Persistence is orthogonal to design and modelling\. Persistence closure requires that all object references be stored and then reproduced when necessary \(it doesn't need to know about actual object creation\)\. It also involves efficient query mechanisms but again, we have two sides of the same story \- generating class models, schemas, wire formats is a case of clean computational semantics while creating, storing and quering of knowledge structures \(archetypes\) has to do with domain\-specific knowledge\. I cannot comment on the costs of persistence but recent trends in database theory point in the direction of knowledge\-aware persistence mechanisms\. > But the OpenEHR & HL7 reference models are quite different\. > In most parts, the HL7 reference model is more abstract > \(Which is way Act gets 22 attributes\)\. So harmonising between > the reference models is going to require actual change rather > than adroitly altering perspectives, as with data types and > the constraint model things\. I don't think that one can discuss whose model is more abstract \(or bigger\)\. What interests me is whether the two models have the right abstractions for the task, and whether principles of information and knowledge modelling have been put to good use\. Actual change should contribute to the goal of greater expressiveness and focused coverage rather than to the elusive goal of harmonisation\. > This will be hard, and painful\. And it must involve compromise, > so this is when we find out who really values collaboration\. Blood, sweat and tears? In the name of what? What do you mean by compromise? What is the nature of compromise in scientific research? This is a term that belongs in areas such as politics and conflict resolution\. In research, the middle ground, as Goethe would say, is where conflict begins \(my apologies for the imprecise quote\)\. Who really values collaboration? Again, strong words, Grahame\. What is the nature, program and goals of such collaboration? Is it the creation of an open Electronic Health Record based on computational and domain\-specific semantic interoperability? What is the mechanism of this collaboration? I'd be interested to see the specific research program and see how emerging joint efforts lead to uncompromising collaboration in the name of a clearly defined final goal\. > And we don't want to take away the real benefits that OpenEHR > has in the process \(same for HL7\) I agree, Ogi Pishev --- ## Post #51 by @system Graham, Isn 't is a matter of scope, as the thing we need to have agreement on first? Isn 't is a matter of requirements, as the thing we need to have agreement on second? Will the rest of the harmonisation process follow from that? I think that harmonising two things with substantial different scopes and requirements is impossible. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 --- ## Post #52 by @Sam William I think targets are more complex than setting a mood code, but I might be wrong. The Goal is 130/90 - is it greater than this or less than this? What if the BP is 40/20 - does this meet the goal - how does the computer know? It is hard to get this right - but very important if we are to make use of computers. Cheers, Sam --- **Canonical:** https://discourse.openehr.org/t/sources-of-information-on-hl7-ehr-openehr/14561 **Original content:** https://discourse.openehr.org/t/sources-of-information-on-hl7-ehr-openehr/14561