Templates and RM

Last week we had an interesting discussion about templates/standards, and some related issues.

Thomas had written a blog related to this discussion,

( http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation )

and in the comments he linked to this example as being an example of what a template is (or will be) in OpenEHR

https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/single_file_template/templates/openEHR-EHR-COMPOSITION.t_clinical_info_ds.v1.adls

I don't have any information about the design philosophy, that is why I come to following question, which may have an obvious answer, but I don't know it.
Maybe, if the answer to this question is documented somewhere, I would prefer the link to the documentation as a reply, so I can read more about it.

What strikes me in the example-template is that it, apparently, as a whole, remains conform the Reference Model.
This means that templates are not a way of breaking out the Reference Model, and thus, it can be impossible to use templates as a bridge to other Reference Models, for the simple reason that this Reference Model does not provide some essentials from Reference Models which are to be mimicked.

Am I right in this?
What is the reason for this?

As said, I understand that the reply to this can be long, so I am much obliged and perfectly happy with a link applicable documentation regarding the design (-philosophy).

Best Regards
Bert Verhees

Hi Bert,

the 'template' in openEHR, whether in .oet form or the new ADL2 form doesn't try to break out of the reference model that the archetypes that that template references are based on. The design idea of the template is simple: it's the essential element for building a data set / data structure (however you want to think of it), based on a set of archetypes and a given reference model. Usually a template has data points / groups from a number of archetypes.

Templates are always what is deployed in an operational system - you can't build an operational openEHR system without templates.

Now, if you want to 'break out' of the openEHR reference model, e.g. to deal with data from some other system, that isn't being mapped to openEHR data - i.e. you want to deal with this other data in its native form somehow - then you need a higher level construct than a template - since you are potentially bringing together data that a priori are not compatible.

If however, you want to transform data e.g. HL7v2/v3 messages or proprietary DB or whatever, you normally start by build an openEHR template that looks as close as you can get in its logical structure to the source data. To do the actual transform there is still going to be some low level ugly work to do, which can be achieved with any integration engine, or home-made code. At some point in the future, I hope we start seeing standardised converter scripts for standard HL7v2 messages and other well-known source formats.

hope this helps

- thomas

I sure helps, then I know what/where (not) to look for.

It are not only the well-known Reference Models, what I am looking for Integration purpose.
But some functionality in non-medical or medical related software, which is sometimes developed by third small parties. Think of hairdresser-agenda, kitchen, financial software, etc.
It is not always wanted to have an over-qualified developer who understands medical Reference Models to write a simple module for a simple specific practical purpose, maybe in PHP or something like that.

Bert

that's what TDS is for, i.e. XSD per template. It's not the only way of doing that, and different transforms from the OPT can be made, but TDS in principle is quite good - if you want some developers to just deal with say 5 major lab messages, and ignore the rest of the EHR, 5 TDS XSDs could be a useful starting point.

- thomas

It is not always wanted to have an over-qualified developer who understands medical Reference Models to write a simple module for a simple specific practical purpose, maybe in PHP or something like that.

that's what TDS is for, i.e. XSD per template. It's not the only way of doing that, and different transforms from the OPT can be made, but TDS in principle is quite good - if you want some developers to just deal with say 5 major lab messages, and ignore the rest of the EHR, 5 TDS XSDs could be a useful starting point.

Ah, brand new information for me. Sounds very promising.
I found a short description
http://www.openehr.org/programs/specification/roadmap

Where can I learn more?

Bert

well it is not documented that well yet, but it has been in use for at least 5y I would say. If you have the template designer, you can create a TDS from that - I think it is File>Export or something similar. So you need to create a template first, then generate the OPT, and then the TDS. If you need help, just post here, there are experts (just not me :wink:

- thomas

Thanks
Bert

Thomas Beale schreef op 4-11-2014 16:02:

well it is not documented that well yet, but it has been in use for at least 5y I would say. If you have the template designer, you can create a TDS from that - I think it is File>Export or something similar. So you need to create a template first, then generate the OPT, and then the TDS. If you need help, just post here, there are experts (just not me :wink:

Thomas,

I looked at it.

The problem of this approach is that you first need to create a template, and as you stated before, a template is always modeled according the Reference Model.
So an OPT/TemplateData-XSD is also according the reference model.

Of course it is possible to manipulate those files, but that is not really easy, and also error-prone.
I am also missing some important data, such as the mapping information to underlying archetypes.

I think, the best way to break out of the OpenEHR ReferenceModel, and still keep the mapping to the archetypes is the OET-XML-format.
Are there any objections against or bad experiences using the OET-format for this purpose?
But to do so, I can't get it done in the Template Designer.

It looks like the file CompositionTemplate.XSD (in subdirectory of template-designer) defines the OET-format, allthough, this is never referenced in any OET.
But there are quite some similarities.
Don't OET-files validate against this XSD? If not, what is its purpose?

Is it so that there is not really good support, (or in file-definition or in tooling coming from this community/organization), to create a mapping from the OpenEHR Reference Model, to any other model?
I think this is important to state.

This whole situation is a perfect example why I favor OpenEHR to become a standard, or at least behave like one.
This regarding to definitions and transparency. As I wrote in one comment in your standard-blog:
The process is more important then the goal.

http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation/#comment-16968

OpenEHR does not always behave like a standard, and that creates every now and then some problems and unclarities.
When an official standardization-office would guard the process, I think, this would not be possible.

Best regards
Bert Verhees

Thomas Beale schreef op 4-11-2014 16:02:

well it is not documented that well yet, but it has been in use for at least 5y I would say. If you have the template designer, you can create a TDS from that - I think it is File>Export or something similar. So you need to create a template first, then generate the OPT, and then the TDS. If you need help, just post here, there are experts (just not me :wink:

Thomas,

I looked at it.

The problem of this approach is that you first need to create a template, and as you stated before, a template is always modeled according the Reference Model.
So an OPT/TemplateData-XSD is also according the reference model.

well, if you are not starting with a template, by definition you are doing something else. So I guess you are doing something different to do with legacy data. You could use the .oet format for some other purpose, nothing to stop you doing that, but all it is is an less powerful XML cousin of the new ADL2 syntax. It may make sense to actually provide a new .oet format that is semantically identical to ADL2, I had not thought about that. However, it's still based on some reference model in each case - how do you want to 'break out' of that?

Of course it is possible to manipulate those files, but that is not really easy, and also error-prone.
I am also missing some important data, such as the mapping information to underlying archetypes.

...

This whole situation is a perfect example why I favor OpenEHR to become a standard, or at least behave like one.
This regarding to definitions and transparency. As I wrote in one comment in your standard-blog:
The process is more important then the goal.

http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation/#comment-16968

OpenEHR does not always behave like a standard, and that creates every now and then some problems and unclarities.
When an official standardization-office would guard the process, I think, this would not be possible.

I completely agree with this, but at least we don't create unusable, complex things and then force on to the world as an ISO standard, something which has happened more than once in the past, and has cost governments (and therefore taxpayers) hundreds of millions of wasted $/€/£.

In terms of becoming better at the process, we are going to a) re-organise the specifications development group and b) convert the specifications to a more manageable form. This should happen in the next few months. The main guard against anomalies is having strict guidelines on how to update and issue each entity, and then ensuring that we actually execute the guidelines.

- thomas

Bert

Welk probleem los je op zodat je deze vragen stelt?

De scherm presentaties

Bert

Welk probleem los je op zodat je deze vragen stelt?

De scherm presentaties

De vraag is generiek bedoeld, als betrokkene bij het OpenEHR-definitie-proces.
Persoonlijk vind ik, wat ik vraag, erg voor de hand liggend.

Daarbij, het kan nooit kwaad om te zien van hoe anderen in teams zoiets weldoordacht en na jaren denk-proces oplossen, je zou wellicht iets vergeten in een complexe definitie.

Bert

Hi Bert,

Sorry. I am still a bit confused about what you mean by 'breaking out
of the Reference model'.

Is this about transforming between openEHR data instances and e.g. CDA or 13606?

Can you give a concrete example of what you are trying to achieve?

Ian

Thomas Beale schreef op 4-11-2014 16:02:

well it is not documented that well yet, but it has been in use for at least 5y I would say. If you have the template designer, you can create a TDS from that - I think it is File>Export or something similar. So you need to create a template first, then generate the OPT, and then the TDS. If you need help, just post here, there are experts (just not me :wink:

Thomas,

I looked at it.

The problem of this approach is that you first need to create a template, and as you stated before, a template is always modeled according the Reference Model.
So an OPT/TemplateData-XSD is also according the reference model.

well, if you are not starting with a template, by definition you are doing something else. So I guess you are doing something different to do with legacy data. You could use the .oet format for some other purpose, nothing to stop you doing that, but all it is is an less powerful XML cousin of the new ADL2 syntax. It may make sense to actually provide a new .oet format that is semantically identical to ADL2, I had not thought about that. However, it's still based on some reference model in each case - how do you want to 'break out' of that?

It is not only about legacy data. It can also be new data-models from third parties.

As I explained, but apparently not clear, there can be purpose for a data-representation in mapping from archetypes or templates to some other (maybe simple) model which can be used without requirement the need to have compliancy to or understanding of the OpenEHR reference model.

In other sections, there are other vendors ruling. Those other sections are important. A customer will prefer easy interoperability to other sections on the market.

Example: suppose you have a financial application which has import in a specific format, I think this is a often occurring use-case.
Because OpenEHR does not define financial models, so data in the OpenEHR-reference model are to be used to support data in financial software.
To avoid to have redundant information in an organization which cannot be checked against each other and to have smooth processes, it is needed to have a mapping-definition.

There are many example-use-cases for this functionality.

Of course it is possible to manipulate those files, but that is not really easy, and also error-prone.
I am also missing some important data, such as the mapping information to underlying archetypes.

...

This whole situation is a perfect example why I favor OpenEHR to become a standard, or at least behave like one.
This regarding to definitions and transparency. As I wrote in one comment in your standard-blog:
The process is more important then the goal.

http://wolandscat.net/2014/10/25/what-is-a-standard-legislation-or-utilisation/#comment-16968

OpenEHR does not always behave like a standard, and that creates every now and then some problems and unclarities.
When an official standardization-office would guard the process, I think, this would not be possible.

I completely agree with this, but at least we don't create unusable, complex things and then force on to the world as an ISO standard, something which has happened more than once in the past, and has cost governments (and therefore taxpayers) hundreds of millions of wasted $/€/£.

Although ISO also has very useful standards, it is also possible to have other standardization organizations working on this. Oasis, ECMA
This kind of organizations have the expertise, processes and resources and status.
I think it is also a waste to let organizations and countries reinvent the wheel, and not being inter-operable because they all invented their own wheels.

In my example, there are specific financial software data-interchange standard-formats. To create compliance to such a standard, there is need for a mapping-definition. If a generic mapping definition is standardized, there can be tooling which makes it *easier* for OpenEHR-implementors to create vendor-independent mappings complying to standards and de-facto standards.

It can be done with XSLT on OpenEHR-query-results.
It involves following steps.
First create a series of AQL-queries and process the results (there we are at the mapping), then transform the result over XSLT to the wanted format.
Maybe in the processing of the results there are issues which cannot be defined in XSLT or become very complex (error-prone), they can (depending on the definition) also be handled by the mapping itself.
So, maybe processing by XSLT is much simpler if partly done implicit by the mapping-definition or it will be not necessary at all.

Against using XSLT as part of the mapping definition, it complicates the mapping-tooling

At this point we come to the *easy* development of applications around an OpenEHR system.
It is about being an open system.

If the mapping to archetypes-paths and/or template-paths is part of the mapping-definition, the mapping is also possible two ways.

IT is also about smooth data-processing at low costs.

In terms of becoming better at the process, we are going to a) re-organise the specifications development group and b) convert the specifications to a more manageable form. This should happen in the next few months. The main guard against anomalies is having strict guidelines on how to update and issue each entity, and then ensuring that we actually execute the guidelines.

That is very good. I wait and see.

Bert

Bert

Not necessarily to CDA or 13606, but I gave an example in my reply to Thomas.
Maybe use missed in one of my previous emails, but there are many examples.

An hospital is a complex organization which has all kinds of professions working, also ones which one does not think of instantly: hairdressers, priests, taxi's, financial services, teachers, kindergarten, parking, sports, swimming pool, kitchen, etc.

All these professions can have the need to access to some medical data, and maybe also need to feedback to the system.

In the philosophy of two level modeling it can be good to provide to software-providers for these professions, simple and/or targeted data-representation which does not follow the OpenEHR reference model, but can be mapped to it. Instead of two level modeling, we get three level modeling.

Bert

Example: suppose you have a financial application which has import in a specific format, I think this is a often occurring use-case.
Because OpenEHR does not define financial models, so data in the OpenEHR-reference model are to be used to support data in financial software.
To avoid to have redundant information in an organization which cannot be checked against each other and to have smooth processes, it is needed to have a mapping-definition.

wouldn't you just embed references - e.g. DV_EHR_URIs - inside your openEHR data, to point to your financial data?

Although ISO also has very useful standards, it is also possible to have other standardization organizations working on this. Oasis, ECMA
This kind of organizations have the expertise, processes and resources and status.
I think it is also a waste to let organizations and countries reinvent the wheel, and not being inter-operable because they all invented their own wheels.

I actually start to wonder if ECMA might be a place to standardise future versions of ADL...

In my example, there are specific financial software data-interchange standard-formats. To create compliance to such a standard, there is need for a mapping-definition. If a generic mapping definition is standardized, there can be tooling which makes it *easier* for OpenEHR-implementors to create vendor-independent mappings complying to standards and de-facto standards.

It can be done with XSLT on OpenEHR-query-results.
It involves following steps.
First create a series of AQL-queries and process the results (there we are at the mapping), then transform the result over XSLT to the wanted format.

so I think you are trying to export openEHR data to some other format? I'm not that clear yet on what the data target is - is it some other (non-health) data standard?

- thomas

Hi Bert,

I think 2 different things are mixed here.

*One is the modelling of the information architecture-> OpenEHR 2 levels (archetypes for IoP + templates for local implementations) are useful for that

*Another problem is the integration with other systems, whether they are based in any standard or not → in this case you need to apply transformations and mappings among the different models. A general transformation between, for example OpenEHR-HL7 CDA cannot be done in a generic way without loss of precision according to D. Kalra report (http://www.healthintersections.com.au/wp-content/uploads/2011/12/HL7-openEHR-13606-Transformability_v1.0.pdf). Therefore you will be forced to define mappings among models. You can do that with a general tool such a Pentaho, but if you want to validate the constraints specified in ADL in your generated instances you should use a software checking for these constraints. I recently did that in collaboration with Ibime using LinkEHR to transform data from the EHR legacy data into OpenEHR instances.

Regards,

Luis

I don’t know what is meant here. Sorry for that. I wasn’t thinking of mapping between HL7/CDA but in my ideas I am not excluding that. It is just far to sophisticated for what I am thinking of. See my reply to Ian for examples. Do you require from a appdesigner creating very specific apps, only sideways related to medical content, that he understands the OpenEHR ReferenceModel, or are you able to deliver very specific data-sets for very specific purposes? And if those very specific datasets are live mapped to archetype-paths, they will automatically be validated in case of feedback, or do it locally extra to avoid network-traffic. Bert

Example: suppose you have a financial application which has import in a specific format, I think this is a often occurring use-case.
Because OpenEHR does not define financial models, so data in the OpenEHR-reference model are to be used to support data in financial software.
To avoid to have redundant information in an organization which cannot be checked against each other and to have smooth processes, it is needed to have a mapping-definition.

wouldn't you just embed references - e.g. DV_EHR_URIs - inside your openEHR data, to point to your financial data?

Possible, if it fits into the financial software-infrastructure. Then you can do with an DV_EHR_URI which is in fact a path-mapping.
But there is also financial software which wants more then just a link. It wants a date, a time, a location, all separated and in specific formats.

Although ISO also has very useful standards, it is also possible to have other standardization organizations working on this. Oasis, ECMA
This kind of organizations have the expertise, processes and resources and status.
I think it is also a waste to let organizations and countries reinvent the wheel, and not being inter-operable because they all invented their own wheels.

I actually start to wonder if ECMA might be a place to standardise future versions of ADL...

I don't know if I was talking about ADL. But I am sure that you have the idea.

In my example, there are specific financial software data-interchange standard-formats. To create compliance to such a standard, there is need for a mapping-definition. If a generic mapping definition is standardized, there can be tooling which makes it *easier* for OpenEHR-implementors to create vendor-independent mappings complying to standards and de-facto standards.

It can be done with XSLT on OpenEHR-query-results.
It involves following steps.
First create a series of AQL-queries and process the results (there we are at the mapping), then transform the result over XSLT to the wanted format.

so I think you are trying to export openEHR data to some other format? I'm not that clear yet on what the data target is - is it some other (non-health) data standard?

Could be.

Thanks for your interest

Best regards
Bert

Het is ok
No worries

A bit in relation to this, for a laugh.

In the Netherlands there was a plan to roll out a system to provide clinical data to everyone who needed professional access. They did ten years in designing and spending half a billion Euro's.

The promise was to garantue to the patient a fine-grained authorization-mechanism in which the patient (if intelligent enough) could give people/professions access to the necessary parts of the data.
There would be an emergency-access-definition also.
Also detailed logging of who would have had access to data was promised.

And now the joke, they did not succeed, they failed in all promises, despite working ten years on it, despite having dozens of the best educated people working for them.
Despite CSC and Intersystems working for them.

And the patients (we, the people) were pushed in with opt-out-system. Most people did not realize their medical data were available in an national system.

A hasty changing from opt-out to opt-in was not good enough
The parliament, that part of the parliament which we call the senate, did not take it anymore, and pulled the plug.

A privacy-disaster because of the missing fine-grained authorization and the missing logging was avoided.

What was the case: If you add up all people in the Netherlands that have in one way or another need of access to some medical data, you come to 500.000 persons, on every 30 persons 1.
Many of them working for agencies in more institutions having multiple access.
It was unclear how to avoid having people having access to personal data which was not needed for their work.
Everyone would know some persons with access to medical data.

Now insurance-companies have taken up the abandoned system and try to revive it, but as I am informed, things are going terrible wrong there too.
I save that story for another occasion.

Ok, did you have a good laugh about the Dutch, feel free to do, the Dutch also feel free to laugh about other nations.
For example, about the British? How was their national NHS Information system?

And now the bit of relation to this subject.

Is it possible, to have fine grained authorization nation-wide on data-level?

Is it possible to have detailed logging checkable by the patient, having every nurse logging in, getting the patients-record and having something to type in a computer after every action, while having a very busy job.
Would such a system remain workable?
Those were the hard nuts.

Isn't it better that a taxi-driver only has "hardwired/hardcoded" access about when to drive a patient in a simple dataset? For that purpose, it is not needed to have Reference Model structures communicated
But what is needed is a live-mapping to the archetypes/templates to where data are retrieved and written back and final validation.
And thus, a mapping definition :wink:

Now I stop with this subject.

Best regards
Bert Verhees