One model vs One framework in e-health .....

Clinical (archive)
1

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.

2

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.

3

Hi Athanassios,

I probably should let other more technically-orientated people comment but I sense that you have not really understood the openEHR approach.

To adapt your own premise, the openEHR approach is to isolate the clinical complexity of an EHR, which is of a very different nature to the technical complexity of an EHR. Furthermore, the use of templates isolates the complexity of aligning with local requirements (including some GUI issues) from wider semantic interoperability issues.

The reason that openEHR says nothing about the database schema, is that it is irrelevant - all querying is done via a service layer or AQL. So there are a variety of approaches to persistence, depending on the overall requirement. Needless to say, implementing a enterprise-quality openEHR persistence layer with adequate scalability, performance and an AQL interpreter is non-trivial. This is one of the reasons why an open-source version has not yet emerged - you are facing exactly the same problem. Whether openEHR, RIMBAA or your own efforts, this kind of activity needs very significant back-end engineering.

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. Having now taken a full paediatrics application, through clinical requirements to modelling in openEHR archetypes and templates, into generated Java object models and partial GUI generation, then rich data retrieval via AQL, I have seen this working first hand. 70% of the archetypes came from the CKM repository with only minimal localisation.

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.

Interesting discussion,

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@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

4

Regarding Derek’s comments,

I would ask whether from the health professional point of view especially that of clinicians, e-health standards (terminology, devices, measurements, etc) is a technical ‘thing’ ?

I would also ask developers when they specify the data domain of attributes on HL7 RIM model classes and the relationships whether they fall into a technical implementation level of detail ?

In other words, where do you draw the line between domain knowledge (conceptual level) and the specifications of the model. The way I see it, the more you try to agree and describe in great detail these specifications or design a base to start generalizing the more you start dealing with technical implementation…

By the way, MS Word (Office Open XML STANDARD) is indeed a great example since you referred to that. It is Microsoft’s IMPLEMENTATION of an XML-based file format to represent word processing, spreadsheets, presentation documents. There are numerous solutions based on office open XML formats to support electronic health records. There is another very popular open document format (an OASIS STANDARD) for open office applications which is a different IMPLEMENTATION developed by Sun Microsystems for the same task (document representation). Both of these STANDARDS-IMPLEMENTATIONS are used nowadays in a large scale from users and developers !

Conclusion: If ‘technical’ people have only arrived at specifications of these standard and they have not implemented it, I doubt whether they would have been so popular around the world.

Athanassios

5

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

6

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.

7

Hi Ian,

you have certainly managed to isolate the clinical complexity from this technical layer up to a certain point and this is great. You offer clinicians software tools to design clinical care, administrative forms and prototypes using familiar terminology. But database schema is NOT irrelevant because it is the physical location of your data that are collected from your forms, that is the final/original destination. Moreover a framework that is handling the database schema, the mapping of conceptual schema, and the management of objects at programming level is very popular in modern software development environments.

In your case, you are storing clinical content, business logic, vocabulary terminology and user interface fields among other things in your ADL archetypes, templates in order to be standalone, in order to be transferable. I can appreciate that and the fact that there can be similar poorer approaches that other followed with tools such as Infopath to store/retrieve/exchange XML data. But as a developer/architect I am not aware and I cannot comment on the complexities you face when you need to read the structure, data content and relate them with other data collected from other sources (databases, documents, etc), or interoperate with other systems and clinical document formats that require a different serialization or store the data from multiple openEHR forms. I believe that you have to provide more examples apart from openEHR Java and Opereffa projects of simple processes (data entry, data storage, data retrieval, data reporting, data serialization (CDA,CCR), data view, etc) that are based on openEHR and implemented in popular DBMS, RAD environments and other open software tools.

If you have the clinicians on your side then perhaps it is time to take more independent/freelance/company developers on your side too. Make it more popular if you can :wink:

Thanks for your comments on my reply

Athanassios

8

Hi Ian,

you have certainly managed to isolate the clinical complexity from this technical layer up to a certain point and this is great. You offer clinicians software tools to design clinical care, administrative forms and prototypes using familiar terminology.

9

Greetings,
Minor point about one of the projects; Opereffa, and what it is trying to do.
To serve the community spirit of the openEHR foundation, I've put a
lot of functionality into Opereffa, which would not be necessary for
the real purpose it was built for: my PhD work.
Due to well known, and repeatedly expressed issues regarding
resources, I can only provide examples of tackling key issues in
Opereffa, but what is out there already provides food for thought for
a lot of things. It has an Eclipse plugin to generate UI from ADL
files, it has a persistence layer that uses Hibernate and postgresql
with some db side tricks etc. It includes integration to an open
source terminology server to save snomed ct items along with
archetypes. I'm not claiming these are mature or best implementations
of the explored concepts, but they are still useful starting points
for anyone interested in the domain.

I don't think any of the projects or Thomas (personally or on behalf
of openEHR foundation) "has to" provide more examples for anything,
for no person/institution on the planet can tackle the task of
implementing every major use case around openEHR, just to prove that
the design can deliver what it claims, or for any other reason.

Finally, my humble suggestion will repeat the comment from Thomas
Beale: don't get trapped into wide spread definitions of "modern
software development", since modern tools of a huge community may
disappoint you when it comes to handling implementation requirements
of openEHR. Most tools/frameworks will give you a fast route to
implementation by cutting corners, but if you may end up with
inserts/reads of 8-10 second.Focus on the concepts of implementation,
not the specifics.

regards
S

10

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@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

11

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 :wink: 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

12

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 :wink: 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.

13

Hi Thomas,

“No data is stored in archetypes or templates”. You mean no data entry is stored I suppose because you store semantics for generating a UI form (i.e. name of the fields on the form, descriptions, term bindings, language, etc). The view of the template as HTML tree or the archetype interface tab do demonstrate the appearance of a user interface based on the values the fields can accept. Are you mixing schema (data definitions) with data content here (e.g. term bindings) ? Normally they try to keep separate the two e.g. XSD, XML instance…

About database schema

The way I view it is that it can be designed to capture XML data, etc… see reply on the other email I sent. The difference is that you see RDBMS as only “a dumb but high performance data blob manager”. And of course term bindings, domain constraints, descriptions can be very well part of the database schema.

But you mentioned changes in the schema, well isn’t there going to be some agreement on higher lever conceptual entities (archetypes), meaning that they will be standardized up to a certain level (e.g. symptom) ? Why can’t you do the same with a class at the conceptual level (application object oriented programming level) ? If not aren’t you experiencing the versioning problem of archetype, or what about in some cases many different archetypes for the same entity ! Or what about business logic when you use these higher lever conceptual entities, e.g. address, person name, etc. and you change their structure ? Moreover how about specialization of certain entities, clearly one might decide to go at a greater detail of describing features depending on the application.

Regarding clarification on your software projects, I would have demonstrated the simplest case of openEHR data instances and how they are related to openEHR archetypes. The minimal software application to create an openEHR data form for entering data, the data instance that is produced, how to view it, and the related archetype that is used. If there is such an isolated example please do point me at the right direction so that I can study the code provided there is also explanation on how to build the application.

Thank you

Athanassios