On 06/05/2011 18:53, Athanassios I. Hatzis, PhD wrote: > > Hi Thomas, > > clinical instructions, evaluations, observations and actions is the > hard part to standardize. There are patterns to be captured but as you > know better it depends on two main factors, the clinical practice of > health professionals and the administrative processing that is > followed by health care establishments. I believe clinicians will note > that agreement on the first is the hard part while there is already > international standardization at some level regarding > administrative/business process of organizations. > > Therefore a significantly larger number of international clinicians > from each specialty has to PARTICIPATE and AGREE on clinical protocols > and standard practice used in prevention, diagnosis, therapy, > monitoring, rehabilitation and follow-up of various diseases and > management of clinical conditions !!! Do you place a HUGE QUESTION > MARK on (OPEN) business models, and financial benefits of ehealth > market to attract stakeholders, especially health professional > stakeholders ? Or in other words isn't it the case that most > clinicians are reluctant to start completing forms, and following > guidelines for many good and bad reasons without being able to see the > immediate profit/benefit they have out of this process or by using > such technological tools ;-) I think you have to face that the more > you will specialize your archetypes, templates looking on patterns, > the more disagreement is probably going to arise between the health > professionals NOT ONLY because of domain complexity reasons. >
luckily, it is not me nor even people like me (i.e. engineers/architects) who have to do this work; we just let clinical people fight it out. Sometimes they do take forever, I think I heard one story where it took 30 clinical experts months to agree on 1 data point in the 'clinical synopsis' archetype! But that I think is an exception. Even clinical people realise that some model is better than no model, and in some finite time, rather than forever. Therefore, Tony Shannon's 'top 10' are well advanced, and so are many other describing heavily used clinical information. Many of these have been put into production in various systems around the world. I think the next 2 years will see a maybe 150 reviewed & published archetypes, with another 300+ in earlier stages of development. I think in a 5 year period we will see archetypes sufficient to cover all of general medicine at sufficient depth for care and reporting. This assumes specific models for genomics and other complex things developed by relevant groups and plugged in to openEHR archetypes. > You mentioned CDA, you are aware of course about Google and CCR > effort. Simple users are not interested in the technology behind, they > are interested in the overall solution. In that case Google is trying > to create a community of users with PHR records based on this > technology. The simpler for the developers to work on, the better (CCR > is a lot simpler to understand and more specific than CDA). CCR is > also very popular in USA for data interchange between health > professionals. Microsoft has also produced EHR solutions based on CDA. > These are certainly examples of solutions beyond messaging. > CCR is great when you initially look at it and it fits your requirements. It's problem is that it is not flexible, and handling the unending flow of different requirements on clinical infomation into the future can't be done by CCR. (A minor point is that it is modelled directly in XML Schema, which creates technical problems, rather than as an object model). The work that went into CCR is excellent, and could be captured by a set of archetypes, with today's CCR being replicated by an openEHR template. In this framework, you could not only generate numerous alternate 'CCRs' (all compatible), but you get a querying approach for free, as part of the architecture. > You commented on binding, and you mentioned at a point the > "underlying semantic object it relates to". But since everyone is > using a different programming model, that semantic object is named > differently in all different ehealth RIM implementations including > your "normal manual programming mean" or other semi or fully automated > ways ! Obviously there has not been an agreement at a programming > level and consequently at database level too regarding the schema ! > well at the programming level, the argument is at least at the level of object models, which is the level of formalism appropriate to a shared reference model. There are lots of programmers using each of the main models, e.g. CDA, openEHR, 13606, RIM, etc, but there aren't that many such models that we could not still contemplate standardisation of some core features. Consider for example that the basic schema of Composition/Section/Entry/hierarchical structure/data types is followed by CDA, 13606 and openEHR. As I said before, our experience in openEHR, and I would say industry experience in many domains does not indicate that trying to map complex object models to relational schemas via O/R mappings is very successful. I know there is a lot of online literature on this, and I worked on such projects for some years in other domains, but it doesn't really work. The misleading concept in the whole approach is to think there is any need for aspects of the reference model or domains models to be in a relational database at all. But there isn't. Most people think this because they think that they are going to query the database using SQL queries based on the model. But that is a dead end as well. You just end up with SQL queries specific to your schema. The real determiners for relational schemas, and particular indexing are: performance, performance and performance. Once one escapes the mental shackles of domain-based schemas and querying, relational databases become useful again. Until then they are a millstone... > Regarding persistence most recent commercial hospital information > systems (including the CIS) are built on relational database > management systems and others that use an object oriented approach are > also using mapping from classes/objects to tables. The best example > and best approach in mapping I have tested is the CACHE database that > is also very popular in the health domain. > yes, nearly all of them are the class 3-layer domain-based schema, object logic layer and GUI on top. In these systems, the object model is inevitably driven by the relational schema, which is the reference model of the system. I would go so far as to say that this architecture has no future. Current systems implemented like this suffer terrible from inflexibility and unmaintainability. They are in a way the reason why there is so much activity in health informatics. Approaches that are going to work have to be far more subtle to provide the needed flexibility. (BTW Cache, is not quite comparable to some other other RDBMS based products). > Therefore yes, I am already in the relational modeling path for > clinical data using the HL7 RIM model that is also using well > established patterns in object oriented programming such as > actor-participant (Coad). Your arguments have not convinced me > regarding RIM. You may see how straightforward is to create a RIM > based RDBMS in three stages, if you read presentations of Abdul-Malik > Shakir on this topic. > I have been familiar with the RIM since 1999, and spent many years going to meetings when it was being designed. The limitations of the RIM are too long to go into here, but if you want I can provide some information privately. > Whether you store XML data, ASCII data, binary data, or single values > on the database I suppose it is a matter of design on the interface > and the database schema this is where one has to be flexible to allow > different kind of data representations to be stored. For example store > the address as structured or unstructured type. That way I suppose I > cannot see why it will suffer terribly from inflexibility as you > mentioned in your comments. > I would suggest that if you are thinking at the level of 'address' as being a table in a RDBMS, you will need to deal with the multiplcity of different kinds of addresses used in the world. It is not too hard to do, if you are cunning, actually, but it is fairly annoying. It is the more complex clinical, investigations, admin, etc data that will get you if you try to model them relationally. The main problem is that if you even manage to do it, you get stuck with what the relational schema says, and allowing for different actual data at runtime starts being quite difficult. > Anyway I am not a fan of theories but as you said I would like to > follow or see some evidence of success in any approach that bring > together developers and clinicians. > > that is certainly a reasonable request, and I have to admit that we are being a bit slow to assemble the parts of the technology that are working in the real world here on the openEHR.org site. - thomas beale -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110506/6e849574/attachment.html>
