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 > > 1.Physical/persistence layer > > 2.Conceptual/Application/Object layer > > 3.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/c27213f1/attachment.html>
