Hi Rene,
I am pretty well in agreement with most of your points and am following the
discusions onthe RIMBAA list with equal interest, as the themes are very
much in common. As Grahame Grieve has been saying, complexity in this space
is a given, and we can really only move it around. I suppose the challenge
is to present each aspect of complexity to the community best able to handle
it. Don't ask clinical people to resolve technical complexity and vice
versa. Actively manage the tensions between broad semantic consensus and
local business requirements.
> The key difference between RIMBAA and openEHR, is that we have largely
> managed to isolate the clinical complexity from this technical layer, so
> that the very real difficulties that we face as clinicians can be argued
> between us, without requiring continual schema updates.
>>This is probably true to a larger degree than it is in the HL7 space; it
>>probably doesn't however lessen the burden of the software developer.
Except in so far as the software developer can more easily isolate himself
from the clinical arguments which are a mixture of clinical and informatics
issues. What are the clinical requirements and what are the best ways to
handle the resulting informatics problems? The software developer does not
have to care particularly what is delivered by this clinical layer.
> I think as well that you are still seeing the complexity of EHR
> development from a technical developer perspective, and I sense that you
> are underestimating the conflict and confusion that will arise when you
> try to meet the needs of varying specialities and domains.
>>That's part of the problem: if a model is solely created by clinical
>>experts, but it isn't implementable in software, it is useless; if it's
>>created by software experts, and not by clinical experts, it's also
>>useless. Mostly we end up with some sort of compromise. Reference models
>>serve as the lingua-franca between clinical and IT experts..
The point of openEHR models (archetypes/templates/termsets) is that they are
always fully plug-in implementable but I would agree if you used 'health
informatics experts' instead of 'software experts'. A bunch of clinicians
can easily produce an implementable solution that, for instance, has zero
interoperability, but actually so would a lot of 'software experts'.
So 'reference models' in part serve as the lingua franca between the
informatician and the software developer, archetypes and templates are the
lingua franca of between the domain experts and the informaticians. The
problem that GreenCDA and the openEHR TDS/TDO equivalents are IMO largely
about isolating the RM complexities from developers who have neither the
time or energy to immerse themselves in these complex beasts.
I do understand the frustration of new entrants to this area. I originally
came to openEHR exactly as you suggest 'looking for a library' of common
clinical components. I initiallly went away disappointed and very confused
but gradually the significance of the two (actually at least three) layer
modelling approach began to make sense. There is still a very long way to
go, particularly in getting to grips with the post-coordinated terminologies
but I think both our communities are broadly on the right track and it is
great to know that there is a useful exchange of ideas.
Regards,
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
On 6 May 2011 13:43, Rene Spronk (Ringholm) <rene.spronk at ringholm.com>wrote:
> Hi Ian,
>
> Speaking in my role as an HL7 RIMBAA representative for a minute:
>
> OpenEHR nor HL7 have specified, and they probably won't in any normative
> fashion, how one deals with implementation issues such as persistence
> (database models) or UIs. To me this totally makes sense - if we had one
> reference model for healthcare it would be of value for a much longer
> stretch of time than the lifetime (or: popularity) of one particular
> technology or development framework.
>
> Obviously it is frustrating for a software developer who doesn't have
> significant resources (which one needs to cover the complexity of the
> healthcare processes and models we're talking about) that there is no
> predefined library which one could use. There is currently a lengthy
> discussion on the HL7 RIMBAA list on how we could ease the life of a
> software developer, i.e. how can we facilitate the use of off-the-shelf
> MDA tools (and UI tools for that matter). But that's probably as far as
> one should go. The heart of the matter is the one-model-for-healthcare.
>
> > The key difference between RIMBAA and openEHR, is that we have largely
> > managed to isolate the clinical complexity from this technical layer, so
> > that the very real difficulties that we face as clinicians can be argued
> > between us, without requiring continual schema updates.
>
> This is probably true to a larger degree than it is in the HL7 space; it
> probably doesn't however lessen the burden of the software developer.
>
> > I think as well that you are still seeing the complexity of EHR
> > development from a technical developer perspective, and I sense that you
> > are underestimating the conflict and confusion that will arise when you
> > try to meet the needs of varying specialities and domains.
>
> That's part of the problem: if a model is solely created by clinical
> experts, but it isn't implementable in software, it is useless; if it's
> created by software experts, and not by clinical experts, it's also
> useless. Mostly we end up with some sort of compromise. Reference models
> serve as the lingua-franca between clinical and IT experts..
>
> > Interesting discussion,
>
> Indeed.
>
> TTYL,
>
> -Rene
>
>
> >
> > Ian
> >
> >
> >
> > Dr Ian McNicoll
> > office +44 (0)1536 414 994
> > +44 (0)2032 392 970
> > fax +44 (0)1536 516317
> > mobile +44 (0)775 209 7859
> > skype ianmcnicoll
> > ian.mcnicoll at oceaninformatics.com <mailto:
> ian.mcnicoll at oceaninformatics.com>
> >
> > Clinical Modelling Consultant, Ocean Informatics, UK
> > openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> > <http://www.openehr.org/knowledge>
> > Honorary Senior Research Associate, CHIME, UCL
> > BCS Primary Health Care www.phcsg.org <http://www.phcsg.org>
> >
> >
> >
> > On 6 May 2011 11:42, Athanassios I. Hatzis, PhD <hatzis at healis.gr
> > <mailto:hatzis at healis.gr>> 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.
> >
> > The big challenge in my opinion is that there has not been an OPEN
> > IMPLEMENTATION of a generic framework to cover all these layers.
> >
> > 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). 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. 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. 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.
> >
> > 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.
> >
> > 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....
> >
> > 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 ???!!!
> >
> > 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.
> >
> > *From:*openehr-clinical-bounces at openehr.org
> > <mailto:openehr-clinical-bounces at openehr.org>
> > [mailto:openehr-clinical-bounces at openehr.org
> > <mailto:openehr-clinical-bounces at openehr.org>] *On Behalf Of *Thomas
> > Beale
> > *Sent:* Thursday, May 05, 2011 7:21 PM
> > *To:* Openehr-Technical; For openEHR clinical discussions
> > *Subject:* on the possibility of 'one information model' in e-health
> >
> >
> > this is an often debated question, and after coming across (for the
> > 100th time) just such a debate recently online, I thought it might
> > be interesting to try to get to the bottom of the question in some
> > way. The basic idea posted here
> > <http://wolandscat.net/2011/05/05/no-single-information-model/>. It
> > is of course not scientific work, but I would be interested in the
> > views of others on this concept.
> >
> > - thomas beale
> >
> >
> > _______________________________________________
> > openEHR-clinical mailing list
> > openEHR-clinical at openehr.org <mailto:openEHR-clinical at openehr.org>
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
> >
> >
> >
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> --
> ------------------------------------------------------------
> Rene Spronk Cell: +31 (0)655 363 446
> Senior Consultant Fax: +31 (0)318 548 090
> Ringholm bv The Netherlands
> http://www.ringholm.com mailto:Rene.Spronk at ringholm.com
> twitter:@Ringholm skype:rene_ringholm
> Ringholm is registered at the Amsterdam KvK reg.# 30155695
> ------------------------------------------------------------
> Ringholm bv - Making Standards Work - Courses and consulting
> _______________________________________________
> 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/20110506/5dac52f5/attachment.html>
