Dear William, I found your note of great interest. IMHO V3 definitely has a higher learning and implementation curve as compared to V2.x and I look forward to ideas that would simplify message creation in V3. I Would be interested in downloading details of DCM (detailed clinical models) to XML conversion (conversion tools, PPTs, PDFs, etc). Would be great if you could share some URLs.
Thanks in advance. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Certified HL7 Specialist Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 ----- Original Message ----- From: Williamtfgoossen at cs.com To: openehr-technical at openehr.org Sent: Friday, November 26, 2010 2:43 AM Subject: Re: HL7 modelling approach Just an example of downstream modeling designs in HL7 to counterbalance Thomas erreonous comments on HL7 modeling. 1. The path to get to implementable HL7 v3 XML is quite clear: we have the RIM as building blocks offering structure, attributes, and behaviour. Pure UML modeling. 2. From the LEGO bricks using constraining, we create LEGO guidelines (similar to the booklets that help in a step by step picture to put the right bricks together). This is the Domain message inf. model. Each of these D-MIM is taking into account a multitude of use cases identified and defined by clinicians, or from projects with clinicians. 3. Following the guideline booklet, actual messages are built, the R-MIMs 4. The object oriented models in R-MIM are serialised into XML. OK, that is the basic pattern. I have used this to create the about 100 R-MIM examples covering a lot of clinical content on the level that in the 13606 world would be an entry. I am still of the opinion that the semantic content of this R-MIM is 100% the same as the same content in an archetype. Well, I came to HL7 int with this and got 2 very important comments from experts in different committees: 1. That is an excellent example of representing clinical content in HL7 v3 specification, it does follow the steps and rules 1-4 above. So the modeling did fit. 2. If we continue to work this way and downstream have to make R-MIMs and serialize them we face the combinatorial explosion. If you have 3000 entry level or data element / data element clusters and 1000 assessment scales and want to vary that in the messages: well we face 3000 x 1000 x 5? variations. That is not sustainable. Hence we abandonned to create fully specified R-MIMs for each clinical artifact and changed the route to what now is DCM. DCM allow still at conceptual level to express what clinicians want and need, but downstream only deliver XML output with structure and coding etc in such a format that it can be inserted in one and the same base message. Hence the combinatorial explosion is 1 for instance for the care record which holds the clinical statement pattern allowing such serialised DCM content to be included. Hence, the downstream implementation in HL7 guided in this example the modeling approach. William ------------------------------------------------------------------------------ _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.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/20101126/2a19c1ba/attachment.html>
