On 09/05/2011 21:48, Athanassios I. Hatzis, PhD wrote: > > Hi, > > I have been reading architecture overview of openEHR, and I would like > to make some comments, questions with respect to the ontological > separation: > > a)There has not been an international agreement on the Reference > model, that is supposed to be stable, (openEHR RM vs HL7 RIM vs .....) > > I am not surprised as it is usually this level (RM) that is > implemented in software according to the openehr architecture > overview. But I would like to make clear for those that were reading > the posts of "one model vs one framework in e-health" that I was not > referring to that level of modeling. > > My interpretation on this issue is that we have many health standards > at that level ;-) >
indeed. > b)There has not been an international agreement on the "Domain Base > Concept Model", level 2 invariant domain concepts according to openEHR > ontological layering, where the archetypes are based on (clinical care > entries -- instructions, evaluations, observations, actions, etc), > administration entries (admission, registration, accounting, etc) > this level is part of the reference model in openEHR > My interpretation on that issue is that we have many health standards > at that level too ;-) > indeed. This is the key problem of standardisation in e-health - it has caused paralysis and indecision in many national programmes. I made a detailed analysis - see the first 4 posts at http://wolandscat.net/category/health-informatics/ > DO NOTE also the comment on the presentation of Ocean Informatics at > UCL in the year 2005: > > This level must be standardised and agreed for archetypes to be > sharable. So what has been the progress on that ? > yes, quite a lot. If you look at the Clinical Knowledge Manager <http://www.openehr.org/knowledge/>, you will see some hundreds of archetypes being worked on by 500+ clinical experts from around the world (if you login, you can see a lot of statistics etc). > c)There has not been an international agreement on the variant > re-usable domain concepts, openEHR level 3, openEHR ARCHETYPES (e.g. > medication, symptoms, imaging, diagnosis, procedure, etc....). > > My interpretation on this issue is that we have many health standards > at that level too ;-) > see above (I think you have the levels slightly confused; most people consider this to be the second level) > OK that is perhaps the reason that many presentations end up with the > tower of BABEL ;-) > > Therefore domain concepts are defined differently in HL7 and openEHR > and the same is true for any other organization that attempted to > write specifications for that level. But It is common sense I believe > for any architect/developer/analyst that worked in industry, or even > an IT database course student, to attempt solutions at a business > domain and to define, to model entities at semantic level as a > starting point. In fact if you study many of the commercial ehealth > systems and open source ehealth software you will do of course find > classes (objects) and tables that represent such entities. > yes, it's one of the reasons why there are so many problems with existing solutions. > So why is not there ONE information model at that level for many if > not all to agree on ? Because I suppose many will answer there is > great variability and here it comes the solution of many organizations > including openEHR to specify FIRST persistence level (see also > comments and discussion on one information model vs one framework in > e-health), meaning to deal with data types and then start building the > other layers. Invariant parts come first no matter how close they are > to the health domain ! > > OK let us focus on the clinical content for a moment and suppose we > start modeling this FIRST as it has already happened. Think also about > the conversion issue of legacy, old systems. > > For this argument I will choose existing clinical models, archetypes > defined at the clinical knowledge manager: > > Medication description (Dose Unit, Dose instruction, indications, > etc......) > > Symptom Features (Locations, Variation, Severity, etc.....) > > Imaging Data (Imaging procedure, anatomical site, location, etc....) > > You noticed of course that I have taken content from different > sections of a typical EHR. > > Questions > > ------------ > > 1)What about if there is an agreement for a minimal set of features to > describe all BASIC content sections that are typically present at EHR > (i.e. something close to a CCR). Or else describe the specifications > of a clinical model for a GP or general medicine. > what is being done in this regard is for a 'top 10' set of archetypes to take priority, enabling content in basic things like emergency summary and discharge summary to be largely standardised. This work is underway on CKM. > 2)Then attempt to specialize, i.e. specify a minimal set of archetypes > with the most common present features in cardiology, neurology, etc... > > What clinicians PROBABLY SHOULD DO is to define the levels of ontology > for their domain (i.e. general medical practice, specialties, > sub-specialties, etc...) based on archetypes. > > Of course I do strongly agree with openEHR approach, that at the > atomic level you have to deal with a standardized archetype (re-usable > domain concept, unit of ehealth information sharing). But I think > there has to be an assessment for those archetypes that are most > common, for those features that are met in those archetypes most > often, etc. > > 3)If that is what is going to happen, why not implementing these > standard archetypes with classes-objects at programming level, if we > agree the names of the attributes (features) ? > because this is exactly what we want to get away from; that is the road to disaster - it is the 1980s approach where everything in the domain becomes a class and/or a relational table. Unfortunately you end up with brittle software and data. The need is to avoid fixed names, fixed cardinalities, in some cases, fixed types, and instead to have far more flexibility. > So far what has been over-emphasized I think is the data types for > describing archetypes. Maybe there has to be some freedom here for the > developers or the DBMS. > > Yes we can have hundreds of relationship diagrams, hundreds of > database schemas, but if we agree on the classes (archetypes) then > work for developers will become much easier and we will have to focus > on the analysis, workflow, problems, plus that there is going to be > higher coherence between developers and clinicians. > fortunately there is a better approach that is emerging, whereby these classes/XSDs/etc can be generated from templates, in such a way that the data created can always be converted back to canonical form. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110509/a9e328bd/attachment.html>
