lessons from Intermountain Health, and starting work on openEHR 2.x

[Heather Leslie]

Hi everyone,

At the last two ISO meetings the revision of ISO 13606, under leadership of
Dipak Kalra, was discussed: 

. All five parts of ISO 13606 are being revised simultaneously and
have passed NWIP ballot in the last couple of weeks.

. At the recent Vancouver ISO meeting WG1 confirmed that the scope
of each of the five parts should not be changed for the purposes of this ISO
revision - it will remain for EHR communication only. However there are
plans to align ISO 13606 with other ISO standards and HL7 standards
including CDA, plus include learnings from other initiatives including
openEHR (especially for part 1) and CIMI (for part 2). 

. Extension of 13606 to include data storage/repository requirements
has been discussed but if it proceeds will be managed as a separate piece of
work at some point in the future.

Next steps:

. Confirm experts

. Request Member bodies to launch information gathering exercise -
what national and regional eHealth programmes and vendors/vendor
associations are using 13606

Regards

Heather

 

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Gerard Freriks
Sent: Friday, 5 October 2012 8:14 PM
To: For openEHR technical discussions
Cc: openehr-clinical at lists.openehr.org
Subject: Re: lessons from Intermountain Health, and starting work on openEHR
2.x

 

See below. 

 

On 4 Oct 2012, at 18:07, Thomas Beale wrote:





On 03/10/2012 23:26, Gerard Freriks wrote:

I just care about getting one model 

 

In the case of 13606 one good model that describes a generic interface for
EHR communication, also, for communication with other proprietary EHR
solutions.

In the case of openEHR one good model that describes one particular
implementation of an EHR-system.

 

This difference is something the EN1366 Association cares about.

 


well except that the above is a misunderstanding of openEHR, so if the 13606
association works on that basis they will miss the opportunity to get
harmonisation. 

 

Whatever openEHR aspires to be, it is clear that the scope of 13606 is EHR
Communication in general.

It has been made clear that, in the renewal process of the 13606 EHR
Communication standard, EHR-system implementation specifics are out of
bounds.

The scope of 13606 will not be extended to match the scope of openEHR.

 

 





openEHR is a model for an open EHR (it's in the name ;-), and includes three
kinds of semantics:

*   core semantics that apply for any use of health information -
messages, EHR systems, documents etc
*   semantics that describe accessing EHR information in repositories -
any repository

Accessing data in repositories is definitely out of scope for 13606 in this
round of updating.

*   semantics that describe EHR information in an Extract from one
system to another - any kind of system

If openEHR is serious about its scope, to be a general receiver of health
data, then its Reference Model must become much more generic than it is now,

The 13606 Reference Model is very generic just to serve this important
requirement that it must be able to deal with all systems. 

 





These are used to specify the interfaces of EHR systems, EHR gateways (that
sit next to existing EMR systems), and EHR Extracts. The openEHR
architecture describes the externally shareable information semantics, not
the internal implementation. The implementations are the business of
vendors, and are all different. In other words, openEHR is an
interoperability description of the system - how the information and
services look from the outside.

Insofar as 13606 has been used (uptake by industry vendors appears very low
as far as we can tell),

 

Hm?

 





it has been used to build either EHR systems or gateways, rarely messages,
which is what it designed for. This seems a fair indication that what the
sector wants is a specification for the interoperability interface of the
systems and gateways required to even connect a healthcare enterprise to the
outside world - and additionally, a specification for making EHR Extracts in
these systems.



 

13606 based interfacing systems have proven to be capable of extracting data
from any feeder system, transform it into the 13606 format, and into any
other structured format.

And do this in matter of days.

We do not need openEHR to do that.

 






A specification only for EHR Extracts is not that useful, what the sector
clearly wants are specifications of the interoperability interface of
systems, as well as messages they might create. That's the opportunity here
for us working on these standards.



 

All this is within the scope of 13606.

It is misleading to suggest that the scope of 13606 is just messaging. EHR
Extracts are about interoperability of data objects in general.

 






13606 needs to be updated a priori, and has lessons from use waiting to be
implemented; openEHR has lessons from the last 5 years of use which

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 05/10/2012 11:13, Gerard Freriks wrote:
> See below.
>
> On 4 Oct 2012, at 18:07, Thomas Beale wrote:
>
>> On 03/10/2012 23:26, Gerard Freriks wrote:
 I just care about getting one model 
>>>
>>> In the case of 13606_one good model_that describes a generic 
>>> interface for EHR communication, also, for communication with other 
>>> proprietary EHR solutions.
>>> In the case of openEHR_one good model_that describes one particular 
>>> implementation of an EHR-system.
>>>
>>> This difference is something the EN1366 Association cares about.
>>> *
>>> *
>>
>> well except that the above is a misunderstanding of openEHR, so if 
>> the 13606 association works on that basis they will miss the 
>> opportunity to get harmonisation. 
>
> Whatever openEHR aspires to be, it is clear that the scope of 13606 is 
> EHR Communication in general.
> It has been made clear that, in the renewal process of the 13606 EHR 
> Communication standard, EHR-system implementation specifics are out of 
> bounds.
> The scope of 13606 will not be extended to match the scope of openEHR.

No-one is suggesting it will - it is a subset of the three elements I 
mentioned below. It would probably be more useful if it were extended, 
but I understand that in the Vancouver ISO meeting it was decided 
otherwise. So for specifying gateways & EHR data sources, industry will 
need openEHR. If we can make it a clean superset of 13606, then that 
will help greatly.

>
>
>
>> openEHR is a model for an open EHR (it's in the name ;-), and 
>> includes three kinds of semantics:
>>
>>   * core semantics that apply for any use of health information -
>> messages, EHR systems, documents etc
>>   * semantics that describe accessing EHR information in repositories
>> - any repository
>>
> Accessing data in repositories is definitely out of scope for 13606 in 
> this round of updating.
>>
>>   * semantics that describe EHR information in an Extract from one
>> system to another - any kind of system
>>
> If openEHR is serious about its scope, to be a general receiver of 
> health data, then its Reference Model must become much more generic 
> than it is now,
> The 13606 Reference Model is very generic just to serve this important 
> requirement that it must be able to deal with all systems.

It's already very generic. It doesn't need to be more generic in any 
substantive way, although it needs:

  * the simplification of the ITEM_STRUCTURE part, which is already more
or less worked out
  * an easier way to use plain ENTRY as a concrete type, also worked out
in principle.

Being simpler than that isn't useful to implementers. If some 
implementers only want to use the 13606 subset, that's fine.


>
>
>
>> it has been used to build either EHR systems or gateways, rarely 
>> messages, which is what it designed for. This seems a fair indication 
>> that what the sector wants is a specification for the 
>> interoperability interface of the systems and gateways required to 
>> even connect a healthcare enterprise to the outside world - and 
>> additionally, a specification for making EHR Extracts in these systems.
>
> 13606 based interfacing systems have proven to be capable of 
> extracting data from any feeder system, transform it into the 13606 
> format, and into any other structured format.
> And do this in matter of days.
> We do not need openEHR to do that.

Then it has solved everything, and we can stop work...

>
>>
>> A specification only for EHR Extracts is not that useful, what the 
>> sector clearly wants are specifications of the interoperability 
>> interface of systems, as well as messages they might create. That's 
>> the opportunity here for us working on these standards.
>
> All this is within the scope of 13606.
> It is misleading to suggest that the scope of 13606 is just messaging. 
> EHR Extracts are about interoperability of data objects in general.

well, speaking as someone who has both worked on 13606 for 5 years, and 
also used it, I know in exactly what it defines: an EHR Extract message 
(part 1), and an Extract service interface (part 5). EHR Extracts are 
what they are: an extract from an EHR / EMR / other similar kind of 
patient record system.

The scope of 13606 is exactly about those Extracts (part 1), defining 
their possible content (part 2) and moving the extracts around (part 5) 
securely (part 4). That's exactly what it should be, I don't know anyone 
else who has a problem with that.

>
>
>>
>> 13606 needs to be updated a priori, and has lessons from use waiting 
>> to be implemented; openEHR has lessons from the last 5 years of use 
>> which will lead to changes, so there is scope for change and 
>> harmonisation. I think the community here, and also the stakeholders 
>> are interested in practical proposals for a new set of standards that 
>> actually address needs.
>
> I'm happy to announce that there is a wealth of implementation 
> experience not only in the world of openEHR.
> There is a w

lessons from Intermountain Health, and starting work on openEHR 2.x

[Koray Atalag]

Hi Peter, we heard you loud and clear...

Not going into detailed discussions I think we have a great methodology to 
express clinical content - Archetypes. Of course they come with a RM, and I 
would want to think that it is only at the RM that 13606 and openEHR differ 
(due to nuances in scoping). As we target the Archetypes to include every 
possible data item configuration for a clinical concept naturally the RM has to 
be granular enough to accommodate detailed peculiarities. So if the sole 
difference between 13606 and openEHR is that of genericity/specifity one would 
assume ALL stuff expressed in 13606 be represented in openEHR. Conversely there 
will have to be inevitable loss in fidelity of information passed from one 
system to another using 13606 (at least between two openEHR systems). The story 
is different for non-openEHR systems though - in most cases the fidelity 
provided by 13606 might be more than enough for passing info from one to 
another.

I hope that the two formalisms don't go separate ways so that the difference 
become more than just that of scope (and associated RM changes)- This we should 
avoid. But just for the sake of simplicity I don't think the world needs more 
than one, essentially same, standard. Unfortunately things don't work this way 
so best we can do is to ensure Archetype development be consistent between the 
two formalisms where semantic equivalence should be sought. Nailing the RM 
relationships will be critical. I wonder if with small tweaks in openEHR RM by 
enabling generic class use we can actually solve the problem which 13606 is 
addressing. In that case de jure SDOs can take a snapshot at appropriate points 
in time from openEHR, for the sake of meeting their process requirements, and 
this would be a great step towards unity. But unfortunately the moment you 
model the same clinical concept using generic 13606 ENTRY vs. OBSERVATION or 
other in openEHR there is no way a machine to safely interpret as same.

I think this is also a modelling issue - so if one modeller can represent a 
clinical concept using a generic type and the other with a specialised one, 
that means  the latter might either have a more stringent requirement or the 
former doing it wrong. Firmly I don't think there is any difference in terms of 
information requirements whether the purpose is information exchange or 
building a fully-fledged EHR system. It is the party (person or machine) who 
uses this information and acts upon that sets the information requirements - 
you can't possibly send information over the wire which does not meet those 
requirements. So I would assume any 13606 modeller to take into account the 
same requirements too. I often find it difficult to understand how information 
exchange is seen different from how that information is represented and 
processed inside. This is one in terms of content - format and detail might 
different.

Lastly if there is a need to pass on a simplified version of clinical 
information over the wire the Archetype editor can set genericity at that level 
so that the model meets both needs.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Linhardt Peter
Sent: Monday, 8 October 2012 5:38 a.m.
To: For openEHR technical discussions
Subject: lessons from Intermountain Health, and starting work on openEHR 2.x

Gentlemen

Current situation, where CEN 13606 deals on en hadn with communication only, 
but pays no attention to the EHR data storage, retrieval and OpenEHR concept on 
other hand leads to some very serious problems in the countries, trying to 
build eHealth system, based on the future proof concept.
Leads to the confusion, regarding the archetypes and the proper tool for their 
creation, maintenance and interchange, and in the end of day to the lack of 
interoperability of basic stones of clinic and demographic information
Leads to the enormous space for private clinical data concepts, leading to the 
growing costs of building and maintaining interface between the CEN 136060 
health messages and EHR data of providers and national system and creates 
obsstackels for international interoperability
Situation in creation of national helath information system in Slovakia suffers 
just due the split of ideology on side of OpenEHR and insolved parts of CEN 13 
606
And country health sector will pay great costs, when this split ones upon the 
time will be solved and CEN will be able to provide for national helath system 
complex
Acceptable solution from creation of heaalth reportt by physician, storage in 
health care data silo, communication between all providers inside of coutnry 
and on international level upt to creatin of national EHR data warehouse.

I hope, Europe/globaly we can agree on single approach for a standard for 
clinical content, fully supporting  generic semantic interoperability, to agree 
on standard for artefact in order to he

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On Thu, Sep 13, 2012 at 11:15 AM, David Moner  wrote:

> 2012/9/13 Erik Sundvall 
>
>> It would be great if e.g most of the future ISO 13606 version could be a
>> true subset of openEHR instead of the current confusing situation.
>
>
> This is something I discussed with Thomas some time ago, it would be one
> of the best harmonisation solutions, but probably with a slightly different
> interpretation. Since 13606 has more generic classes (eg. the generic ENTRY
> can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead
> of 13606 being a subset of openEHR I think that openEHR should be a
> specialized model of 13606.


I don't care if one is called a specialisation of the other, or a subset
the other way around :-) as long as it all works properly in software.

Would thoughts along the lines of
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+-+CIMI+version+1 work
for the ISO 13606 use cases you are thinking of? Or do you need something
like the yellow boxes in "Candidate C" at..
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=37978115#openEHR2.xRMproposals-lowerinformationmodel-CandidateCsimplificationandclassrenamingforeasierexplanationandimplementation


The main issue is probably on which class the "data" attribute fits if we
want the openEHR entry types to specialize the 13606 entry class - in e.g.
OBSERVATIONS you may not want to use the same attribute name for another
datatype.

In "Candidate C" the CARE_ENTRY could share the same "interface" as ENTRY
but it is not a direct specialization of ENTRY in implementation languages
without multiple inheritance (like Java).

Another option would of course be to call the current data-field of
OBSERVATION something else than data and make a call for the data field on
an observation return some kind of summary/conversion adhering to 13606
structures (in a way inspired by the as_hierarchy in the DATA_STRUCTURE
class, see 3.2.1 in
http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf
)


> Obviously this would require a deep analysis and changes of the models,
> but that could be the idea.


Yep, deeper analysis of the thoughts above would also be neccesary.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Linhardt Peter]

Gentlemen

Current situation, where CEN 13606 deals on en hadn with communication only, 
but pays no attention to the EHR data storage, retrieval and OpenEHR concept on 
other hand leads to some very serious problems in the countries, trying to 
build eHealth system, based on the future proof concept.
Leads to the confusion, regarding the archetypes and the proper tool for their 
creation, maintenance and interchange, and in the end of day to the lack of 
interoperability of basic stones of clinic and demographic information
Leads to the enormous space for private clinical data concepts, leading to the 
growing costs of building and maintaining interface between the CEN 136060 
health messages and EHR data of providers and national system and creates 
obsstackels for international interoperability
Situation in creation of national helath information system in Slovakia suffers 
just due the split of ideology on side of OpenEHR and insolved parts of CEN 13 
606
And country health sector will pay great costs, when this split ones upon the 
time will be solved and CEN will be able to provide for national helath system 
complex
Acceptable solution from creation of heaalth reportt by physician, storage in 
health care data silo, communication between all providers inside of coutnry 
and on international level upt to creatin of national EHR data warehouse.

I hope, Europe/globaly we can agree on single approach for a standard for 
clinical content, fully supporting  generic semantic interoperability, to agree 
on standard for artefact in order to heve interoperability among archetypes, 
created/edited in different editors and due archatype based concept of data 
creation, storage and transport get rid of endless maping, interfacing and data 
mess.

Peter Linhardt
National archetype centre at Slovak university of technology
Bratislava, Slovakia

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Gerard Freriks
Sent: Thursday, October 04, 2012 8:21 AM
To: For openEHR clinical discussions
Cc: For openEHR technical discussions
Subject: Re: lessons from Intermountain Health, and starting work on openEHR 2.x

Dear Koray,

We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote.
The scope of 13606 is about EHR communication.
That of openEHR is about the implementation in an EHR system.

At present a standard is missing about defining clinical content.
It would be nice, certainly, when both 13606 and openEHR can share that 
standard for clinical content.
In several places the EN13606 Association, whose scope is wider than the 
European context, is actively working towards that goal.
This single approach for a standard for clinical content is very important when 
we want generic semantic interoperability.
This is the reason why components for a potential standard on archetype 
production are developed inside the Association.
A standard that defines the intersections with: coding systems, ontologies, 
other CEN/ISO standards like System of Concepts for Continuity of Care and the 
Health Information Services Architecture.
All resulting in one basic generic pattern, for all artefacts, that by 
specialisation is able to be used for all kinds of archetypes.
A basis pattern that in more detail allows the definition of more nuances than 
the archetypes we know, so far.
A basic pattern that brings features closer to actual use such as negation, 
semantic ordinals (with inclusion and exclusion criteria), better integration 
with clinical workflow, ontological reasoning over structure and codes, etc.

The EN13606 Association of implementors of the 13606 standard has considerable 
experience in the production of applications based on this standard.
When I look into future needs and developments around the use of coding systems 
and ontologies, I see state of the art developments among the members of the 
Association.

W3C is a good example. indeed.
As far as I know W3C does not prescribes how to implement their standards in 
systems.
This is the responsibility of the industry in all circumstances.


Gerard Freriks
+31 620347088
gfrer at luna.nl<mailto:gfrer at luna.nl>




On 4 Oct 2012, at 02:02, Koray Atalag wrote:


Hi Gerard,
I think getting the content model is absolutely right - no one can argue
But with due respect I disagree with you about the difference. I seriously 
think standards defining clinical content should converge (not even harmonise).
I had the privilege of spending some time with Ed Hammond in NZ and was 
convinced that this is what is needed. Mappings are different and certainly a 
blackhole.
That said EN13606 Association's mission and role is paramount in terms of 
contextualising "exchange" within the European context.

We chose to use openEHR for defining the Interoperability standards in New 
Zealand as we are very mindful of the fact that this formalism has been defined 
and carried on for many years by this group; an

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

See below.
On 4 Oct 2012, at 18:07, Thomas Beale wrote:

> On 03/10/2012 23:26, Gerard Freriks wrote:
>>> I just care about getting one model 
>> 
>> In the case of 13606 one good model that describes a generic interface for 
>> EHR communication, also, for communication with other proprietary EHR 
>> solutions.
>> In the case of openEHR one good model that describes one particular 
>> implementation of an EHR-system.
>> 
>> This difference is something the EN1366 Association cares about.
>> 
> 
> well except that the above is a misunderstanding of openEHR, so if the 13606 
> association works on that basis they will miss the opportunity to get 
> harmonisation.

Whatever openEHR aspires to be, it is clear that the scope of 13606 is EHR 
Communication in general.
It has been made clear that, in the renewal process of the 13606 EHR 
Communication standard, EHR-system implementation specifics are out of bounds.
The scope of 13606 will not be extended to match the scope of openEHR.



> openEHR is a model for an open EHR (it's in the name ;-), and includes three 
> kinds of semantics:
> core semantics that apply for any use of health information - messages, EHR 
> systems, documents etc
> semantics that describe accessing EHR information in repositories - any 
> repository
Accessing data in repositories is definitely out of scope for 13606 in this 
round of updating.
> semantics that describe EHR information in an Extract from one system to 
> another - any kind of system
If openEHR is serious about its scope, to be a general receiver of health data, 
then its Reference Model must become much more generic than it is now,
The 13606 Reference Model is very generic just to serve this important 
requirement that it must be able to deal with all systems. 


> These are used to specify the interfaces of EHR systems, EHR gateways (that 
> sit next to existing EMR systems), and EHR Extracts. The openEHR architecture 
> describes the externally shareable information semantics, not the internal 
> implementation. The implementations are the business of vendors, and are all 
> different. In other words, openEHR is an interoperability description of the 
> system - how the information and services look from the outside.
> 
> Insofar as 13606 has been used (uptake by industry vendors appears very low 
> as far as we can tell),

Hm?


> it has been used to build either EHR systems or gateways, rarely messages, 
> which is what it designed for. This seems a fair indication that what the 
> sector wants is a specification for the interoperability interface of the 
> systems and gateways required to even connect a healthcare enterprise to the 
> outside world - and additionally, a specification for making EHR Extracts in 
> these systems.

13606 based interfacing systems have proven to be capable of extracting data 
from any feeder system, transform it into the 13606 format, and into any other 
structured format.
And do this in matter of days.
We do not need openEHR to do that.


> 
> A specification only for EHR Extracts is not that useful, what the sector 
> clearly wants are specifications of the interoperability interface of 
> systems, as well as messages they might create. That's the opportunity here 
> for us working on these standards.

All this is within the scope of 13606.
It is misleading to suggest that the scope of 13606 is just messaging. EHR 
Extracts are about interoperability of data objects in general.


> 
> 13606 needs to be updated a priori, and has lessons from use waiting to be 
> implemented; openEHR has lessons from the last 5 years of use which will lead 
> to changes, so there is scope for change and harmonisation. I think the 
> community here, and also the stakeholders are interested in practical 
> proposals for a new set of standards that actually address needs.

I'm happy to announce that there is a wealth of implementation experience not 
only in the world of openEHR.
There is a wealth of experiences in deploying the 13606 EHR communication 
standard in hospitals, research, regions.
Sometimes in relation with HL7 CDA artefacts, sometimes to create applications 
for data entry, sometime integrated with ontological applications.

In the meantime I sincerely hope that harmonisation is possible without making 
too many unneeded remarks about potential partners.


> 
> - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 03/10/2012 23:26, Gerard Freriks wrote:
>> I just care about getting one model 
>
> In the case of 13606 _one good model _that describes a generic 
> interface for EHR communication, also, for communication with other 
> proprietary EHR solutions.
> In the case of openEHR _one good model_ that describes one particular 
> implementation of an EHR-system.
>
> This difference is something the EN1366 Association cares about.
> *
> *

well except that the above is a misunderstanding of openEHR, so if the 
13606 association works on that basis they will miss the opportunity to 
get harmonisation. openEHR is a model for an open EHR (it's in the name 
;-), and includes three kinds of semantics:

  * core semantics that apply for any use of health information -
messages, EHR systems, documents etc
  * semantics that describe accessing EHR information in repositories -
any repository
  * semantics that describe EHR information in an Extract from one
system to another - any kind of system

These are used to specify the interfaces of EHR systems, EHR gateways 
(that sit next to existing EMR systems), and EHR Extracts. The openEHR 
architecture describes the externally shareable information semantics, 
not the internal implementation. The implementations are the business of 
vendors, and are all different. In other words, openEHR is an 
interoperability description of the system - how the information and 
services look from the outside.

Insofar as 13606 has been used (uptake by industry vendors appears very 
low as far as we can tell), it has been used to build either EHR systems 
or gateways, rarely messages, which is what it designed for. This seems 
a fair indication that what the sector wants is a specification for the 
interoperability interface of the systems and gateways required to even 
connect a healthcare enterprise to the outside world - and additionally, 
a specification for making EHR Extracts in these systems.

A specification only for EHR Extracts is not that useful, what the 
sector clearly wants are specifications of the interoperability 
interface of systems, as well as messages they might create. That's the 
opportunity here for us working on these standards.

13606 needs to be updated a priori, and has lessons from use waiting to 
be implemented; openEHR has lessons from the last 5 years of use which 
will lead to changes, so there is scope for change and harmonisation. I 
think the community here, and also the stakeholders are interested in 
practical proposals for a new set of standards that actually address needs.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[pablo pazos]

+1 I think you're about to hit the right spot, it seems to be very near to THE 
solution for interoperability & reuse at a model level.
Learning from the Internet approach (the biggest example of interoperability in 
the world, that actualy works) the multi-component or multi-layered idea seems 
the right idea: having a common core for layer 1, a bussiness layer with EHRs, 
... seems just right.
Another big advantage of this approach is the gradual implementation 
capability: I can implement & certify a layer 1 implementation, then implement 
layer 2, ...
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Wed, 3 Oct 2012 23:19:28 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: lessons from Intermountain Health, and starting work on openEHR
2.x


  

  
  
On 03/10/2012 23:02, Thomas Beale
  wrote:


although - it will probably come out to have multiple entry points.
The 13606 model is about what makes sense in EHR Extract messages.
We built and implemented a more recent version of that, using
lessons from 13606 - the openEHR EHR Extract. There are undoubtedly
a lot of lessons from 13606 Extract use out there (there must be
because nearly everyone implements the standard by changing, so that
says something!).



However, other parts of openEHR are concerned with the logical
semantics of in situ EHRs, not just messages travelling between
systems. So I think there could be a common core, an EHR part and an
EHR Extract part. Having one standard for that would be hugely
useful for industry.



- thomas  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/1284c27b/attachment-0001.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

Dear Koray,

We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote.
The scope of 13606 is about EHR communication.
That of openEHR is about the implementation in an EHR system.

At present a standard is missing about defining clinical content.
It would be nice, certainly, when both 13606 and openEHR can share that 
standard for clinical content.
In several places the EN13606 Association, whose scope is wider than the 
European context, is actively working towards that goal.
This single approach for a standard for clinical content is very important when 
we want generic semantic interoperability.
This is the reason why components for a potential standard on archetype 
production are developed inside the Association.
A standard that defines the intersections with: coding systems, ontologies, 
other CEN/ISO standards like System of Concepts for Continuity of Care and the 
Health Information Services Architecture.
All resulting in one basic generic pattern, for all artefacts, that by 
specialisation is able to be used for all kinds of archetypes.
A basis pattern that in more detail allows the definition of more nuances than 
the archetypes we know, so far.
A basic pattern that brings features closer to actual use such as negation, 
semantic ordinals (with inclusion and exclusion criteria), better integration 
with clinical workflow, ontological reasoning over structure and codes, etc.

The EN13606 Association of implementors of the 13606 standard has considerable 
experience in the production of applications based on this standard.
When I look into future needs and developments around the use of coding systems 
and ontologies, I see state of the art developments among the members of the 
Association.

W3C is a good example. indeed.
As far as I know W3C does not prescribes how to implement their standards in 
systems.
This is the responsibility of the industry in all circumstances.


Gerard Freriks
+31 620347088
gfrer at luna.nl




On 4 Oct 2012, at 02:02, Koray Atalag wrote:

> Hi Gerard,
> I think getting the content model is absolutely right ? no one can argue
> But with due respect I disagree with you about the difference. I seriously 
> think standards defining clinical content should converge (not even 
> harmonise).
> I had the privilege of spending some time with Ed Hammond in NZ and was 
> convinced that this is what is needed. Mappings are different and certainly a 
> blackhole.
> That said EN13606 Association?s mission and role is paramount in terms of 
> contextualising ?exchange? within the European context.
>  
> We chose to use openEHR for defining the Interoperability standards in New 
> Zealand as we are very mindful of the fact that this formalism has been 
> defined and carried on for many years by this group; and it IS naturally the 
> leading edge with proven track in implementation (one of which is my own 
> work). I think W3C is a good example of how important it is to have a single 
> approach in contrast to the situation in health IT. These might sound a bit 
> strong but it is what I believe. I acknowledge lack of organisational 
> capacity and skills in past though.
>  
> Cheers,
>  
> -koray
>  

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

> I just care about getting one model 

In the case of 13606 one good model that describes a generic interface for EHR 
communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular 
implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M:  +31 620347088
E: gerard.freriks at EN13606.org
W:  http:www.en13606.org

On 4 Oct 2012, at 00:02, Thomas Beale wrote:

> On 13/09/2012 10:15, David Moner wrote:
>> Hi,
>> 
>> 2012/9/13 Erik Sundvall 
>> It would be great if e.g most of the future ISO 13606 version could be a 
>> true subset of openEHR instead of the current confusing situation. 
>> 
>> This is something I discussed with Thomas some time ago, it would be one of 
>> the best harmonisation solutions, but probably with a slightly different 
>> interpretation. Since 13606 has more generic classes (eg. the generic ENTRY 
>> can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead 
>> of 13606 being a subset of openEHR I think that openEHR should be a 
>> specialized model of 13606. Obviously this would require a deep analysis and 
>> changes of the models, but that could be the idea.
> 
> I don't care about the linguistics of subset / specialisation etc, I just 
> care about getting one model 
> 
> - thomas




Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Koray Atalag]

Hi Gerard,
I think getting the content model is absolutely right - no one can argue
But with due respect I disagree with you about the difference. I seriously 
think standards defining clinical content should converge (not even harmonise).
I had the privilege of spending some time with Ed Hammond in NZ and was 
convinced that this is what is needed. Mappings are different and certainly a 
blackhole.
That said EN13606 Association's mission and role is paramount in terms of 
contextualising "exchange" within the European context.

We chose to use openEHR for defining the Interoperability standards in New 
Zealand as we are very mindful of the fact that this formalism has been defined 
and carried on for many years by this group; and it IS naturally the leading 
edge with proven track in implementation (one of which is my own work). I think 
W3C is a good example of how important it is to have a single approach in 
contrast to the situation in health IT. These might sound a bit strong but it 
is what I believe. I acknowledge lack of organisational capacity and skills in 
past though.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Gerard Freriks
Sent: Thursday, 4 October 2012 11:26 a.m.
To: For openEHR clinical discussions
Cc: Openehr-Technical
Subject: Re: lessons from Intermountain Health, and starting work on openEHR 2.x

I just care about getting one model

In the case of 13606 one good model that describes a generic interface for EHR 
communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular 
implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M:+31 620347088
E: g<mailto:gfrer at luna.nl>erard.freriks at 
EN13606.org<mailto:erard.freriks at EN13606.org>
W:   http:www.en13606.org

On 4 Oct 2012, at 00:02, Thomas Beale wrote:


On 13/09/2012 10:15, David Moner wrote:
Hi,
2012/9/13 Erik Sundvall mailto:erik.sundvall at 
liu.se>>
It would be great if e.g most of the future ISO 13606 version could be a true 
subset of openEHR instead of the current confusing situation.

This is something I discussed with Thomas some time ago, it would be one of the 
best harmonisation solutions, but probably with a slightly different 
interpretation. Since 13606 has more generic classes (eg. the generic ENTRY can 
represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 
13606 being a subset of openEHR I think that openEHR should be a specialized 
model of 13606. Obviously this would require a deep analysis and changes of the 
models, but that could be the idea.

I don't care about the linguistics of subset / specialisation etc, I just care 
about getting one model

- thomas




Gerard Freriks
+31 620347088
gfrer at luna.nl<mailto:gfrer at luna.nl>




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/48970968/attachment-0001.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 03/10/2012 23:02, Thomas Beale wrote:
> On 13/09/2012 10:15, David Moner wrote:
>> Hi,
>>
>> 2012/9/13 Erik Sundvall > >
>>
>> It would be great if e.g most of the future ISO 13606 version
>> could be a true subset of openEHR instead of the current
>> confusing situation. 
>>
>>
>> This is something I discussed with Thomas some time ago, it would be 
>> one of the best harmonisation solutions, but probably with a slightly 
>> different interpretation. Since 13606 has more generic classes (eg. 
>> the generic ENTRY can represent all of OBSERVATION, EVALUATION, 
>> INSTRUCTION, ACTION), instead of 13606 being a subset of openEHR I 
>> think that openEHR should be a specialized model of 13606. Obviously 
>> this would require a deep analysis and changes of the models, but 
>> that could be the idea.
>
> I don't care about the linguistics of subset / specialisation etc, I 
> just care about getting one model
>
> - thomas*
> *

although - it will probably come out to have multiple entry points. The 
13606 model is about what makes sense in EHR Extract messages. We built 
and implemented a more recent version of that, using lessons from 13606 
- the openEHR EHR Extract. There are undoubtedly a lot of lessons from 
13606 Extract use out there (there must be because nearly everyone 
implements the standard by changing, so that says something!).

However, other parts of openEHR are concerned with the logical semantics 
of in situ EHRs, not just messages travelling between systems. So I 
think there could be a common core, an EHR part and an EHR Extract part. 
Having one standard for that would be hugely useful for industry.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 13/09/2012 10:15, David Moner wrote:
> Hi,
>
> 2012/9/13 Erik Sundvall  >
>
> It would be great if e.g most of the future ISO 13606 version
> could be a true subset of openEHR instead of the current confusing
> situation. 
>
>
> This is something I discussed with Thomas some time ago, it would be 
> one of the best harmonisation solutions, but probably with a slightly 
> different interpretation. Since 13606 has more generic classes (eg. 
> the generic ENTRY can represent all of OBSERVATION, EVALUATION, 
> INSTRUCTION, ACTION), instead of 13606 being a subset of openEHR I 
> think that openEHR should be a specialized model of 13606. Obviously 
> this would require a deep analysis and changes of the models, but that 
> could be the idea.

I don't care about the linguistics of subset / specialisation etc, I 
just care about getting one model

- thomas


*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[pablo pazos]

+1 I think you're about to hit the right spot, it seems to be very near to THE 
solution for interoperability & reuse at a model level.
Learning from the Internet approach (the biggest example of interoperability in 
the world, that actualy works) the multi-component or multi-layered idea seems 
the right idea: having a common core for layer 1, a bussiness layer with EHRs, 
... seems just right.
Another big advantage of this approach is the gradual implementation 
capability: I can implement & certify a layer 1 implementation, then implement 
layer 2, ...

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Wed, 3 Oct 2012 23:19:28 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: lessons from Intermountain Health, and starting work on openEHR
2.x


  

  
  
On 03/10/2012 23:02, Thomas Beale
  wrote:



  
  On 13/09/2012 10:15, David Moner
wrote:

  
  Hi,



2012/9/13 Erik Sundvall 

   It would
be great if e.g most of the future ISO 13606 version could
be a true subset of openEHR instead of the current confusing
situation. 



This is something I discussed with Thomas some time ago, it
would be one of the best harmonisation solutions, but probably
with a slightly different interpretation. Since 13606 has more
generic classes (eg. the generic ENTRY can represent all of
OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 13606
being a subset of openEHR I think that openEHR should be a
specialized model of 13606. Obviously this would require a deep
analysis and changes of the models, but that could be the idea.
  
  

  I don't care about the linguistics of subset / specialisation etc,
  I just care about getting one model 

  

  - thomas




although - it will probably come out to have multiple entry points.
The 13606 model is about what makes sense in EHR Extract messages.
We built and implemented a more recent version of that, using
lessons from 13606 - the openEHR EHR Extract. There are undoubtedly
a lot of lessons from 13606 Extract use out there (there must be
because nearly everyone implements the standard by changing, so that
says something!).



However, other parts of openEHR are concerned with the logical
semantics of in situ EHRs, not just messages travelling between
systems. So I think there could be a common core, an EHR part and an
EHR Extract part. Having one standard for that would be hugely
useful for industry.



- thomas



  


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121003/6a07e5fc/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 13/09/2012 05:15, David Moner wrote:
> Hi,
>
> 2012/9/13 Erik Sundvall  >
>
> It would be great if e.g most of the future ISO 13606 version
> could be a true subset of openEHR instead of the current confusing
> situation. 
>
>
> This is something I discussed with Thomas some time ago, it would be 
> one of the best harmonisation solutions, but probably with a slightly 
> different interpretation. Since 13606 has more generic classes (eg. 
> the generic ENTRY can represent all of OBSERVATION, EVALUATION, 
> INSTRUCTION, ACTION), instead of 13606 being a subset of openEHR I 
> think that openEHR should be a specialized model of 13606. Obviously 
> this would require a deep analysis and changes of the models, but that 
> could be the idea.
>
> *
> *

yep. I have a few more ideas on this not yet posted, to try and reduce 
gaps. Will do so in the next week or so.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 13/09/2012 03:48, Erik Sundvall wrote:
> Hi!
>
> On 12/09/2012 17:43, Heath Frankel wrote:
> > We need a depreciation scheme that allows us to say that something
> > is no longer recommended for use in a particular release and removed
> > in a subsequent release. This gives implementations time to migrate to
> > the new recommendation. It also means we can get some experience
> > with what the new recommendation is before we remove the deprecated
> > approach.
>
> Yes, what about using that approach (deprecation scheme etc) for a 
> "stable" or "production grade" series of versions - v 1.0.3, v 1.1 and 
> so on...
> ...and at the same time start working on an "experimental" 2.x series.

yep, this is just a question of agreeing what release id goes with what 
changes, in the Specification Programme.

>
> This is how it is often done in big open source projects (with a lot 
> bigger user base than openEHR has). Critical systems, in 
> production use, seldom jump over to the new 2.x series while it is 
> young, they wait for it to mature. BUT they have been able to follow 
> and comment on the 2.x development all along the way so that they can 
> be prepared without constraining the options by insisting on full 
> backwards compatibility. The 1.x branch could also slowly make changes 
> to prepare for a simplified future transition to 2.x including adding 
> transformation tools.
>
> If we want 13606, CIMI and openEHR modelling to merge somewhere in 
> 2.x, the we can not express too much protectionism from openEHRs side. 
> (I think I have heard people complaining about HL7 protectionism on 
> these lists...) Truly good changes (simplifications, increased 
> archetyping flexibility etc) should not be stopped by 
> protectionism, but of course things should be well tested in 
> implementation before new specifications are finalized. It would be 
> great if e.g most of the future ISO 13606 version could be a true 
> subset of openEHR instead of the current confusing situation.

I think the key will be to decide what openEHR 2.x is actually for. From 
my point of view, it's primary goal is to actually work for implementing 
real systems, as it does now. That means that all proposed changes have 
to be carefully analysed for consequences in software - not just in 
existing systems (i.e. what will break) but any system or 
implementation. I.e. do the specs lead to good quality software and 
data? Which requires implementability, reduction of errors etc etc.

So although we do want to get a harmonised standard with 13606 and 
others, the primary goal needs to remain 'what works', not what looks 
pretty in a UML diagram or whatever else. openEHR needs to be a standard 
for the real world.

We have already posted some possible simplifications which should 
improve things without reducing software implementability and power.

>
> In the openEHR 1.x to 2.x case perhaps we will understand each other 
> better if we discuss concrete examples rather than expressing 
> unspecified fears from both "sides", I'll start one below. Feel free 
> to add other examples (a concrete example of proposed data type 
> changes for example).
>
> When you look at 
> http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model,
>  do 
> you then think that the discussed changes at e.g. ENTRY and 
> ITEM_STRUCTURE level will reduce bloat and misunderstandings, at the 
> same time as it increases flexibility and understanding? Would that be 
> truly good for openEHR archetyping and implementation?

these are key questions, but I want to see us stay on the 
'implementability' mission as a key driver as well. Some of the above 
proposals are very nice (I really like the one I wrote ;-)

>
> Ian, an experienced archetype developer, has been asking for this 
> increased flexibility, see: 
> http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974.
>  
> (I think Sam also mentioned similar thoughts on the lists earlier.) I 
> had guessed that those proposed changes are big and breaking enough to 
> go for 2.x rather than a "soft deprecation" 1.x series, what is the 
> opinion of those of you that have big systems running? Do they fit in 
> a 1.x series upgrade path?

I don't think that analysis has been done yet; there are two kinds of 
implementation concern:

  * impact on existing systems and data - a concern of current vendors &
data healthcare owners - i.e. concerns 'starting from where we are now'
  * consequences for new software - i.e. if we were starting again; this
is the point of view of new vendors and adopters


>
> I thought anything that breaks paths would likely be considered a 
> "big" change. (In the example above, the transition path including 
> automated data conversion is pretty clear though.) It is probably 
> better to break these paths in an experimental 2.x series now rather 
> than waiting five+ years

lessons from Intermountain Health, and starting work on openEHR 2.x

[David Moner]

Hi,

2012/9/13 Erik Sundvall 

> It would be great if e.g most of the future ISO 13606 version could be a
> true subset of openEHR instead of the current confusing situation.


This is something I discussed with Thomas some time ago, it would be one of
the best harmonisation solutions, but probably with a slightly different
interpretation. Since 13606 has more generic classes (eg. the generic ENTRY
can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead
of 13606 being a subset of openEHR I think that openEHR should be a
specialized model of 13606. Obviously this would require a deep analysis
and changes of the models, but that could be the idea.

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On 12/09/2012 17:43, Heath Frankel wrote:
> We need a depreciation scheme that allows us to say that something
> is no longer recommended for use in a particular release and removed
> in a subsequent release. This gives implementations time to migrate to
> the new recommendation. It also means we can get some experience
> with what the new recommendation is before we remove the deprecated
> approach.

Yes, what about using that approach (deprecation scheme etc) for a "stable"
or "production grade" series of versions - v 1.0.3, v 1.1 and so on...
...and at the same time start working on an "experimental" 2.x series.

This is how it is often done in big open source projects (with a lot bigger
user base than openEHR has). Critical systems, in production use, seldom
jump over to the new 2.x series while it is young, they wait for it to
mature. BUT they have been able to follow and comment on the 2.x
development all along the way so that they can be prepared without
constraining the options by insisting on full backwards compatibility. The
1.x branch could also slowly make changes to prepare for a simplified
future transition to 2.x including adding transformation tools.

If we want 13606, CIMI and openEHR modelling to merge somewhere in 2.x, the
we can not express too much protectionism from openEHRs side. (I think I
have heard people complaining about HL7 protectionism on these lists...)
Truly good changes (simplifications, increased archetyping flexibility etc)
should not be stopped by protectionism, but of course things should be well
tested in implementation before new specifications are finalized. It would
be great if e.g most of the future ISO 13606 version could be a true subset
of openEHR instead of the current confusing situation.

In the openEHR 1.x to 2.x case perhaps we will understand each other better
if we discuss concrete examples rather than expressing unspecified fears
from both "sides", I'll start one below. Feel free to add other examples (a
concrete example of proposed data type changes for example).

When you look at
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model,
do
you then think that the discussed changes at e.g. ENTRY and ITEM_STRUCTURE
level will reduce bloat and misunderstandings, at the same time as it
increases flexibility and understanding? Would that be truly good for
openEHR archetyping and implementation?

Ian, an experienced archetype developer, has been asking for this
increased flexibility, see:
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974.
(I think Sam also mentioned similar thoughts on the lists earlier.) I had
guessed that those proposed changes are big and breaking enough to go for
2.x rather than a "soft deprecation" 1.x series, what is the opinion of
those of you that have big systems running? Do they fit in a 1.x series
upgrade path?

I thought anything that breaks paths would likely be considered a "big"
change. (In the example above, the transition path including automated data
conversion is pretty clear though.) It is probably better to break these
paths in an experimental 2.x series now rather than waiting five+ years and
try to squeeze it in to 1.8 or something. :-)

> HL7 [...] look what happened when they offered a major upgrade. [...]
> The big issue was the effort for vendors to transition existing systems

I think that might be a somewhat unfair comparison:
1. The proposed openEHR 2.0 changes I have seen so far are not deviating
from the basic design principles and design patterns in openEHR. The basic
approach does _NOT_ change the same way as HL7 did between v2 and v3.
2. The number of vendors using openEHR now is _a lot_ smaller than the ones
that used HL7 v2
3. The number of vendors we want to join the openEHR approach in the future
is _a lot bigger_ than the ones that have existing openEHR-based production
systems.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 12/09/2012 17:43, Heath Frankel wrote:
>
>
> We need a depreciation scheme that allows us to say that something is 
> no longer recommended for use in a particular release and removed in a 
> subsequent release. This gives implementations time to migrate to the 
> new recommendation. It also means we can get some experience with what 
> the new recommendation is before we remove the deprecated approach.
> Please be careful about backward compatibility of our RM, its core to 
> our foundation.
> Heath
>
> *
> *

One key approach that we can use for adding breaking fixes to classes is 
to actually add a new class. For example, a new version of 
ARCHETYPE_SLOT is needed in the AOM. The way I would propose to do this 
is not to 'fix' the existing ARCHETYPE_SLOT,  but to add a new class 
ARCHETYPE_SLOT2 or SEMANTIC_SLOT or whatever, and enhance existing 
compilers to handle the new one, and to know how convert between both. 
This is just an example - there are probably similar instances of 
breaking changes in the RM.

Many change requests I am aware of would not break existing data. The 
main ones we need to be careful with are structural changes to Entry 
classes and to the Participations model.

We need of course to analyse all the proposed changes carefully, but by 
now we have a reasonable number of implementers, and they will need to 
be present on the new specifications editorial committee to help assess 
impact of any given change. So... we just need to do good engineering 
thinking on this.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Sam Heard]

Hi Tom

I absolutely agree with your summary. Technically I think making use of 
obsolescence is the appropriate way to go in software. No competent 
vendor will put out an operating system, compiler or software that 
breaks existing tools without doing the work for them.

The point I am making is that there are now health records out there so 
we need to be absolutely clear that existing health records will work 
with changes. If we want to use upgrade scripts these need to be handled 
between releases so that the old and new work at the same time for a 
while and ensure we have planned obsolescence over a period of software 
cycles (say 3-5 years).

Cheers, Sam

On 6/09/2012 11:56 PM, Thomas Beale wrote:
>
> Personally I think the best way to look at this is as follows:
>
>   * specifications will evolve, and they may include breaking changes.
> As a community we should stick to the usual rules (semver.org)
> whereby we identify releases containing breaking changes with a
> new major version
>   * all releases should be published with the list of changes with
> respect to the previous release ('release notes') and a system
> impact statement as follows:
>   o impact of the changes on *existing software*, including tools
> and re-usable libraries
>   o impact of the changes on existing *archetypes and templates*
>   o impact of these changes on *existing data*, and if
> appropriate, migration / transformation algorithms for the
> data to convert to the new form
>   o impact of the changes on *existing queries*, and how they
> should be upgraded if appropriate
>
> Of course we will try our best to minimise such changes. But none of 
> us here are perfect, so we will never totally succeed at that. For the 
> last two items, there would preferably be software tools / scripts etc 
> available to do the work. Overall, the above should ensure existing 
> systems can be made to interoperate with newer systems. Obviously 
> since in openEHR we are somewhat obsessive about reference model 
> stability, we can hope that the impacts will not be great, and in fact 
> will be very acceptable in comparison to most changes in comparable 
> published standards or industry products.
>
> The implication is always there that someone starting an 
> implementation from scratch later on will build a better system. 
> That's life, and it's how the world makes progress. Someone with an 
> older system might have the annoyance of correcting existing queries 
> or whatever, but on the other hand, they will always be ahead in 
> database optimisation, application framework building and other 
> matters. That's life.
>
> I don't believe we can legislate on what organisations actually choose 
> to do with the specifications - in the end it will be up to them. Our 
> job is to make sure adopters can make /informed/ decisions. Our real 
> goal is to show how using the output of openEHR can actually lead to 
> better health outcomes for society.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

On 06/09/2012 15:44, Sam Heard wrote:
> Hi Tom
>
> I absolutely agree with your summary. Technically I think making use 
> of obsolescence is the appropriate way to go in software. No competent 
> vendor will put out an operating system, compiler or software that 
> breaks existing tools without doing the work for them.
>
> The point I am making is that there are now health records out there 
> so we need to be absolutely clear that existing health records will 
> work with changes. If we want to use upgrade scripts these need to be 
> handled between releases so that the old and new work at the same time 
> for a while and ensure we have planned obsolescence over a period of 
> software cycles (say 3-5 years).*
> *

yep. That's called release management ;-)

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On Thu, Sep 6, 2012 at 12:47 AM, Sam Heard
 wrote:
> I will be pushing the backward compatibility angle very hard indeed - this
> can be a pain for those who want to progress.

Don't push too hard on "backward compatibility" without a clear
definition of what you mean by it and what you want to apply it to. A
fresh re-start (based on implementation experience by openEHR, 13606,
other CIMI actors etc) can make future systems a lot better than if
they have to be constrained by the "wrong" kind of backward
compatibility philosophy (e.g. "add but never remove"-bloatware). :-)

The openEHR RM includes an attribute with RM version in stored
records, so in one way a storage system can be lifelong and
backwards-preserving even if the RM changes, but queries etc will need
to be rewritten to fit several model versions if you have a mix.

What you could focus on is the "_understand_ any issues for current
systems", of course, but make sure that "understand" does not mean
_constrain_ the future options for change and simplification.
Demanding a list of "this old construct could be converted to this new
construct this way" and "this construct is _not_ algorithmically
convertible" is constructive and educating. But forbidding breaking
changes is not constructive, so I hope (and think) that is not what
you meant.

Going from 1.x to 2.x in software usually _does_ include many breaking
changes. If an non-breaking update/refresh is also needed, then a
1.0.3 or 1.4 version of the openEHR specifications could be produced
in parallel - but don't put the wrong constraints on 2.0!

> I personally guarantee there
> will be no official publication of openEHR 2.0 or ADL 1.5 until we
> absolutely understand any issues for current systems.

Can a chairman really personally guarantee any decisions in a
democratic organization? If you are the CEO or owner of a commercial
company you may have some veto rights in that company, but in the
kinds of democratic organisations I am used to, the chairman does not
have a veto right. What kind of organisation do you want openEHR to
be?

> This does not spring
> from a technical concern - rather our community's commitment to life long
> health records. These are after all the asset of the most value in the
> health care enterprise. There are now 60,000 people with openEHR records in
> one Australian repository, some with as many as 2000 compositions.

That system won't break just because new specifications are published.
System upgrades are not mandatory and do not have to be rushed.

If breaking specification changes are not allowed now when there are
relatively few records, archetypes and implementations, how would it
sound later when there are many more archetypes, implementations and
millions of records? Would breaking changes ever be allowed? Better to
break things early than late, if necessary, when aiming for somewhat
global adoption...

Resisting change favors old implementors with existing systems, but
simplifying/strengthening models and thus future implementation (and
maintenance), makes life easier for new actors wanting to enter the
openEHR scene. So there is probably no neutral ground ;-)

What an interesting dilemma to deal with :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733



> On 5/09/2012 10:49 AM, Thomas Beale wrote:
>> for those interested, I have been spending this month with Dr Stan Huff's
>> group at Intermountain Health in Salt lake City. I have at least a dozen
>> potential change requests / issues for openEHR. Mostly small, but important
>> in their way. That has come from the evidence of their systems, and our
>> performing a cross-review during this month. The comparison has shown that
>> we (i.e. openEHR and Intermountain) have essentially the same multi-level
>> modelling system, with different details. Plus I have learned a lot in terms
>> of their design philosophy and thinking.
>>
>> Essentially we can think of these as distilled wisdom/lessons from various
>> incarnations of Stan's leading edge 3M/ASN.1 environment over 15 years, up
>> to the most recent, the Qualibria system using 'CDL' (the ADL equivalent).
>>
>> I'll put these into the openEHR Jira SPEC-PR issue tracker for everyone to
>> see over the next couple of weeks, plus on the mailing lists for more
>> general things I have learned here.
>>
>> The new openEHR Spec programme should get up and running in the next few
>> weeks, which will mean that people here who want to nominate for working on
>> the various specs (i.e. working toward openEHR v2.0) should have a think
>> about doing that. The governance details are mostly worked out, so it just
>> needs people.
>>
>> I know some people feel that the specs have not been changing for too long
>> (myself included) but on the other hand, they have stood up amazingly well
>> over the last few years, and we have a huge amount of industry knowledge
>> accumulated, most of which I think is capture

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

Personally I think the best way to look at this is as follows:

  * specifications will evolve, and they may include breaking changes.
As a community we should stick to the usual rules (semver.org)
whereby we identify releases containing breaking changes with a new
major version
  * all releases should be published with the list of changes with
respect to the previous release ('release notes') and a system
impact statement as follows:
  o impact of the changes on *existing software*, including tools
and re-usable libraries
  o impact of the changes on existing *archetypes and templates*
  o impact of these changes on *existing data*, and if appropriate,
migration / transformation algorithms for the data to convert to
the new form
  o impact of the changes on *existing queries*, and how they should
be upgraded if appropriate

Of course we will try our best to minimise such changes. But none of us 
here are perfect, so we will never totally succeed at that. For the last 
two items, there would preferably be software tools / scripts etc 
available to do the work. Overall, the above should ensure existing 
systems can be made to interoperate with newer systems. Obviously since 
in openEHR we are somewhat obsessive about reference model stability, we 
can hope that the impacts will not be great, and in fact will be very 
acceptable in comparison to most changes in comparable published 
standards or industry products.

The implication is always there that someone starting an implementation 
from scratch later on will build a better system. That's life, and it's 
how the world makes progress. Someone with an older system might have 
the annoyance of correcting existing queries or whatever, but on the 
other hand, they will always be ahead in database optimisation, 
application framework building and other matters. That's life.

I don't believe we can legislate on what organisations actually choose 
to do with the specifications - in the end it will be up to them. Our 
job is to make sure adopters can make /informed/ decisions. Our real 
goal is to show how using the output of openEHR can actually lead to 
better health outcomes for society.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

lessons from Intermountain Health, and starting work on openEHR 2.x

[pablo pazos]

Hi Thomas, great news! and looking forward to help on the specs.
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

> Date: Tue, 4 Sep 2012 19:19:07 -0600
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org; openehr-clinical at 
> lists.openehr.org
> Subject: lessons from Intermountain Health, and starting work on openEHR 2.x
> 
> 
> for those interested, I have been spending this month with Dr Stan 
> Huff's group at Intermountain Health in Salt lake City. I have at least 
> a dozen potential change requests / issues for openEHR. Mostly small, 
> but important in their way. That has come from the evidence of their 
> systems, and our performing a cross-review during this month. The 
> comparison has shown that we (i.e. openEHR and Intermountain) have 
> essentially the same multi-level modelling system, with different 
> details. Plus I have learned a lot in terms of their design philosophy 
> and thinking.
> 
> Essentially we can think of these as distilled wisdom/lessons from 
> various incarnations of Stan's leading edge 3M/ASN.1 environment over 15 
> years, up to the most recent, the Qualibria system using 'CDL' (the ADL 
> equivalent).
> 
> I'll put these into the openEHR Jira SPEC-PR issue tracker for everyone 
> to see over the next couple of weeks, plus on the mailing lists for more 
> general things I have learned here.
> 
> The new openEHR Spec programme should get up and running in the next few 
> weeks, which will mean that people here who want to nominate for working 
> on the various specs (i.e. working toward openEHR v2.0) should have a 
> think about doing that. The governance details are mostly worked out, so 
> it just needs people.
> 
> I know some people feel that the specs have not been changing for too 
> long (myself included) but on the other hand, they have stood up 
> amazingly well over the last few years, and we have a huge amount of 
> industry knowledge accumulated, most of which I think is captured on the 
> PR issue tracker, and at least on the mailing lists. Also, we have a 
> pretty decent ADL/AOM 1.5 spec, which needs community review. AQL has 
> also been implemented a number of times and heavily used now, and has 
> held up very well. There are things to change there, based on its use in 
> industry.
> 
> So, soon we can start on getting a new version of openEHR... it will be 
> a great opportunity I think, to include the clinical and technical 
> lessons available to us in the next generation platform. The community 
> here is wide-ranging and has a huge amount of knowledge... time to use it!
> 
> - thomas
> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120904/d185a666/attachment-0001.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Thomas Beale]

for those interested, I have been spending this month with Dr Stan 
Huff's group at Intermountain Health in Salt lake City. I have at least 
a dozen potential change requests / issues for openEHR. Mostly small, 
but important in their way. That has come from the evidence of their 
systems, and our performing a cross-review during this month. The 
comparison has shown that we (i.e. openEHR and Intermountain) have 
essentially the same multi-level modelling system, with different 
details. Plus I have learned a lot in terms of their design philosophy 
and thinking.

Essentially we can think of these as distilled wisdom/lessons from 
various incarnations of Stan's leading edge 3M/ASN.1 environment over 15 
years, up to the most recent, the Qualibria system using 'CDL' (the ADL 
equivalent).

I'll put these into the openEHR Jira SPEC-PR issue tracker for everyone 
to see over the next couple of weeks, plus on the mailing lists for more 
general things I have learned here.

The new openEHR Spec programme should get up and running in the next few 
weeks, which will mean that people here who want to nominate for working 
on the various specs (i.e. working toward openEHR v2.0) should have a 
think about doing that. The governance details are mostly worked out, so 
it just needs people.

I know some people feel that the specs have not been changing for too 
long (myself included) but on the other hand, they have stood up 
amazingly well over the last few years, and we have a huge amount of 
industry knowledge accumulated, most of which I think is captured on the 
PR issue tracker, and at least on the mailing lists. Also, we have a 
pretty decent ADL/AOM 1.5 spec, which needs community review. AQL has 
also been implemented a number of times and heavily used now, and has 
held up very well. There are things to change there, based on its use in 
industry.

So, soon we can start on getting a new version of openEHR... it will be 
a great opportunity I think, to include the clinical and technical 
lessons available to us in the next generation platform. The community 
here is wide-ranging and has a huge amount of knowledge... time to use it!

- thomas