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. 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. 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 ! 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. 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. 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. 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. A big thanks to all for your comments and the stand you are offering me to say my opinion and learn from your experience on your list. Athanassios From: [email protected] [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, May 06, 2011 3:56 PM To: openehr-clinical at openehr.org Cc: Openehr-Technical Subject: Re: One model vs One framework in e-health ..... Thanks for the feedback Athanassios, one thing to preface my remarks below: hopefully it is clear that this is just a blog post containing a single idea - that 'patterns' are the key semantic element of any information model that might be a candidate for 'standardisation'. On 06/05/2011 11:42, Athanassios I. Hatzis, PhD wrote: Hi Thomas, I will agree with you, yes there has to be a generic health information model but in my opinion it has to span over all three main layers of software architecture Physical/persistence layer Conceptual/Application/Object layer User interface layer/Serialized representation (XML,etc....) RIMBAA technology matrix describes in the best way the different paths one can follow to solve parts of the generic problem. I would say that this matrix describes what most efforts in the sector are doing now. Using the HL7 RIM as the information model limits the result to HL7v3 messages; what is needed here is a more expressive (and non message-specific) information model at the base. My post was essentially about the patterns that are needed in this base information model. With the right patterns, clinical content only has to be defined once for artefacts such as messages, documents, services, APIs, UI, etc to be generated. It is hard to see how the HL7 RIM would enable anything beyond messages, and I guess CDA documents, if we stick to the idea that a CDA is really just a special RMIM. The big challenge in my opinion is that there has not been an OPEN IMPLEMENTATION of a generic framework to cover all these layers. Well, the openEHR Java and Opereffa projects are building this. I have studied a bit the underlying structure of openEHR archetypes/templates, where you are linking/binding user interface fields with clinical/admin entries of the conceptual layer in one serialized object (ADL). By the way I am not convinced that there has to be strong binding between user interface and the conceptual layer (RIM). it depends on what you mean by 'binding'. What is needed is a way of connecting a given UI widget, e.g. some text entry field with the underlying semantic object it relates to, e.g. 'current systolic BP'. This has so far been done by normal manual programming means. What various projects are moving toward in openEHR is a) automatically generating and/or checking this binding and b) potentially automatically generating GUI components, based on 'GUI hints' or rules. But clearly you are leaving out the mapping of data captured from the forms (templates) to the company that is going to provide the database management system in order to store permanently the user data. Not sure what you mean here. The data captured via the use of templates is just openEHR, RM-compliant data. You can store it how you want, but most systems store it as some kind of indexed blobs, with more esoteric approaches coming online. This is relatively trivial. So in general there is no complex 'mapping' of openEHR data to its persisted form. Noone uses any kind of 3NF on clinical data in openEHR, nor would it be sensible to do so, indeed it is not sensible in any complex, information-rich domain such as health. Of course the aggregation of user data is also important in that case and I cannot see any open approach that is taken from your side to cover or support that process. the main tool is AQL-based querying <http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language> : a query language based on domain content models that allows both single EHR and population queries to be expressed in a portable form. Obviously I can also realize that there has to be a business model and profit out of that story and if everything is open and free then many might go out of business. Anyway, let me continue a bit on ONE GENERIC e-health FRAMEWORK. One reason I started the MEDILIG approach is because I realized that there has not been an extensive, generic, easy to follow, standalone, OPEN ER schema in e-health to cover the persistence layer am I wrong ? Developers do need to work with an open database schema because that schema is closely related to the conceptual/object model for programming purposes, business logic is shared between the two as developers do know. I suspect you need to look a lot harder at how persistence in modern systems designed for complex data. Classic textbook 3NF approaches on the domain data models won't work (to be sure, 3NF may be applied at some level, typically in some kind of blob management. However, there are newer database architectures that don't even do this). If you are going down the relational modelling path for clinical data, I am afraid to say you are heading in the direction of many of the current products that suffer terribly from inflexibility for precisely this reason... Question: Has anyone thought to IMPLEMENT an open conceptual framework and generate from there a generic ehealth database model because that is what I am exactly trying to implement using the programming environment of Microsoft Entity framework and the RIM model of HL7. In fact this way I am turning MEDILIG to an entity framework standardized through HL7 RIM and HL7 vocabularies. my first suggestion is that, unless your work is specifically concerned with HL7v3 RIM-based messages, to use a different information model. The RIM is very difficult to use, and yet lacks a lot of basic semantics that enable typical clinical and related information to be easily represented. Secondly I would suggest that if you are actually implemented persistence yourself, go for an indexed document or blob store approach. This will be orders of magnitude simpler than any classical relational-based approach. One may realize the consequences of such an implementation. Developers can built user interfaces of any kind, produce serializations, do mappings from any forms created with other software tools, and make it easier to connect or redesign legacy ehealth applications and databases. Or at least that is the way I envisage it to happen.... these are certainly of the partly-realised and unrealised ambitions in this domain for the last 15+ years .... doing the above is not simple. One idea I have is that the framework can be specialized according to each specialty and therefore you can make it even easier for a developer to approach and implement a specific solution for an individual, a clinic, a lab, etc.... What I DO NOT have is capital, resources or even an employer interested in such a business plan, where I can understand it up to a point ???!!! all I can suggest is to be more involved in one of the efforts that has a good architecture and some evidence of success in its approach. Best luck to all Athanassios PS1: Apologies to the non-technical audience for getting a bit into technical details ;=) PS2: The approach I am suggesting is taking the developer at the center of the solution and attempts to standardize concepts, terms, properties, etc around him. One the other hand the user interface design should take the clinician/health professional at the center and try to standardize the software world around him. You have already achieved that at a great level I believe. Then the two worlds have to be linked/mapped. these two points are very good: the reason to put the developer at the centre is it means that the technology, from an implementer's point of view, has to be 'implementer-friendly', i.e. doesn't require developers to have PhDs in health informatics. openEHR is now pursuing this route in a serious way. Tools to enable clinicians etc to have a direct influence on the design of the UI are also very important; solving this is not simple, but the archetype/template/ref-set approach in openEHR is bearing fruit, especially in some of the national programmes. - thomas beale -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110506/b985f62d/attachment.html>
