Sources of information on HL7 EHR/OpenEHR
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
Antw: Sources of information on HL7 EHR/OpenEHR
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
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 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: mailto:heath.frankel at oceaninformatics.biz heath.frankel at oceaninformatics.biz _ From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Gerard Freriks Sent: Friday, 15 September 2006 7:39 AM To: For openEHR technical discussions Subject: Sources of information on HL7 EHR/OpenEHR 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 -- private -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 653 108732 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... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/5192fd8b/attachment.html
Sources of information on HL7 EHR/OpenEHR
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 -Original Message- From: Andre Duszynski [mailto:andre.duszyn...@adelaide.edu.au] Sent: Friday, 15 September 2006 12:17 PM To: For openEHR technical discussions Cc: heath.frankel at frankelinformatics.com Subject: Re: Sources of information on HL7 EHR/OpenEHR 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. --- Heath Frankel wrote: 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 at oceaninformatics.biz mailto:heath.frankel at oceaninformatics.biz -- -- *From:* openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] *On Behalf Of *Gerard Freriks *Sent:* Friday, 15 September 2006 7:39 AM *To:* For openEHR technical discussions *Subject:* Sources of information on HL7 EHR/OpenEHR 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
Antw: Sources of information on HL7 EHR/OpenEHR
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/bc7ff7d5/attachment.html
EHRcom/openEHR the new exciting paradigm
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
EHRcom/openEHR the new exciting paradigm
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/6625c1dd/attachment.html
Antw: Re: EHRcom/openEHR the new exciting paradigm
In een bericht met de datum 15-9-2006 18:56:19 West-Europa (zomertijd), schrijft gfrer at 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/f0f29275/attachment.html
Antw: Sources of information on HL7 EHR/OpenEHR
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/cf880ee3/attachment.html
EHRcom/openEHR the new exciting paradigm
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
Antw: Re: EHRcom/openEHR the new exciting paradigm
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 -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060915/271bea62/attachment.html
