Questions about the necessity of ITEM_SINGLE

[Pablo Pazos Gutierrez]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi everyone,

I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework).

Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it.

Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).

Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().

Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility.


What do you think?

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

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Rong Chen-2]

Hi Pablo,

I agree with your analysis here especially the last one regarding
evolution of archetypes.

Regards,
Rong

On 3 October 2011 16:23, pablo pazos <pazospablo@...> wrote:

> Hi everyone,
>
> I've been studying how to simplify the ITEM_STRUCTURE model to enhance the
> persistence performance of our Open EHR-Gen project
> (http://code.google.com/p/open-ehr-gen-framework).
>
> Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE
> in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> arguments and hear your comments about it.
>
> Semantic argument: As I understand ITEM_SINGLE, the semantics of this class
> are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean
> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>
> Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as
> an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> interface of each class can be the same, like: getItems(), setItems(), the
> ITEM_SINGLE breaks that with getItem() and setItem().
>
> Evolution argument: If I have an archetype with an ITEM_SINGLE, but the
> concept modeled with this archetype needs to change adding more nodes to the
> archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but
> if the archetype is modeled with an ITEM_TREE, I can add any nodes without
> changing the ITEM_STRUCTURE type. I think this way is more simple to create
> new archetypes with backwards compatibility.
>
>
> What do you think?
>
> --
> 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
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Heather Leslie-2]

I model using ITEM_TREE as default in every archetype, except where we might need a table structure.

So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does.

Heather

>-----Original Message-----
>From: openehr-clinical-bounces@... [mailto:openehr-clinical-
>bounces@...] On Behalf Of Rong Chen
>Sent: Tuesday, 4 October 2011 6:29 AM
>To: For openEHR clinical discussions
>Cc: openehr technical
>Subject: Re: Questions about the necessity of ITEM_SINGLE
>
>Hi Pablo,
>
>I agree with your analysis here especially the last one regarding evolution of
>archetypes.
>
>Regards,
>Rong
>
>On 3 October 2011 16:23, pablo pazos <pazospablo@...> wrote:
>> Hi everyone,
>>
>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
>> the persistence performance of our Open EHR-Gen project
>> (http://code.google.com/p/open-ehr-gen-framework).
>>
>> Now I'm reaching a point in which I doubt about the necessity of
>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
>> expose some arguments and hear your comments about it.
>>
>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
>> I mean
>> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>>
>> Practical argument: in practice, an ITEM_SINGLE is like using an
>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
>> TABLEs, the interface of each class can be the same, like: getItems(),
>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
>>
>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
>> the concept modeled with this archetype needs to change adding more
>> nodes to the archetype, I need to change the ITEM_SINGLE to another
>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
>> can add any nodes without changing the ITEM_STRUCTURE type. I think
>> this way is more simple to create new archetypes with backwards
>compatibility.
>>
>>
>> What do you think?
>>
>> --
>> 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
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical@...
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>
>
>_______________________________________________
>openEHR-clinical mailing list
>openEHR-clinical@...
>http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Sebastian Garde-2]

Yes - and if you want to go one further, ITEM_LIST is nothing more than
a special case of ITEM_TREE as well.
Modelling this explicitly hasn't been extremely useful I believe,
especially if weighed against your evolution argument.

Sebastian

Am 04.10.2011 01:42, schrieb Heather Leslie:

> I model using ITEM_TREE as default in every archetype, except where we might need a table structure.
>
> So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does.
>
> Heather
>
>> -----Original Message-----
>> From: openehr-clinical-bounces@... [mailto:openehr-clinical-
>> bounces@...] On Behalf Of Rong Chen
>> Sent: Tuesday, 4 October 2011 6:29 AM
>> To: For openEHR clinical discussions
>> Cc: openehr technical
>> Subject: Re: Questions about the necessity of ITEM_SINGLE
>>
>> Hi Pablo,
>>
>> I agree with your analysis here especially the last one regarding evolution of
>> archetypes.
>>
>> Regards,
>> Rong
>>
>> On 3 October 2011 16:23, pablo pazos<pazospablo@...>  wrote:
>>> Hi everyone,
>>>
>>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
>>> the persistence performance of our Open EHR-Gen project
>>> (http://code.google.com/p/open-ehr-gen-framework).
>>>
>>> Now I'm reaching a point in which I doubt about the necessity of
>>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
>>> expose some arguments and hear your comments about it.
>>>
>>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
>>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
>>> I mean
>>> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>>>
>>> Practical argument: in practice, an ITEM_SINGLE is like using an
>>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
>>> TABLEs, the interface of each class can be the same, like: getItems(),
>>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
>>>
>>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
>>> the concept modeled with this archetype needs to change adding more
>>> nodes to the archetype, I need to change the ITEM_SINGLE to another
>>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
>>> can add any nodes without changing the ITEM_STRUCTURE type. I think
>>> this way is more simple to create new archetypes with backwards
>> compatibility.
>>>
>>> What do you think?
>>>
>>> --
>>> 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

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[David Moner]

I think Thomas has already mentioned that here there is a good possibility of harmonization with EN13606. At the end it seems that we only need  single ELEMENTs and a container with list or table semantics.

2011/10/4 Sebastian Garde <sebastian.garde@...>

Yes - and if you want to go one further, ITEM_LIST is nothing more than
a special case of ITEM_TREE as well.
Modelling this explicitly hasn't been extremely useful I believe,
especially if weighed against your evolution argument.

Sebastian

Am 04.10.2011 01:42, schrieb Heather Leslie:

> I model using ITEM_TREE as default in every archetype, except where we might need a table structure.
>
> So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does.
>
> Heather
>
>> -----Original Message-----
>> From: openehr-clinical-bounces@... [mailto:...
>> bounces@...] On Behalf Of Rong Chen
>> Sent: Tuesday, 4 October 2011 6:29 AM
>> To: For openEHR clinical discussions
>> Cc: openehr technical
>> Subject: Re: Questions about the necessity of ITEM_SINGLE
>>
>> Hi Pablo,
>>
>> I agree with your analysis here especially the last one regarding evolution of
>> archetypes.
>>
>> Regards,
>> Rong
>>
>> On 3 October 2011 16:23, pablo pazos<pazospablo@...>  wrote:
>>> Hi everyone,
>>>
>>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
>>> the persistence performance of our Open EHR-Gen project
>>> (http://code.google.com/p/open-ehr-gen-framework).
>>>
>>> Now I'm reaching a point in which I doubt about the necessity of
>>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
>>> expose some arguments and hear your comments about it.
>>>
>>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
>>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
>>> I mean
>>> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>>>
>>> Practical argument: in practice, an ITEM_SINGLE is like using an
>>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
>>> TABLEs, the interface of each class can be the same, like: getItems(),
>>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
>>>
>>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
>>> the concept modeled with this archetype needs to change adding more
>>> nodes to the archetype, I need to change the ITEM_SINGLE to another
>>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
>>> can add any nodes without changing the ITEM_STRUCTURE type. I think
>>> this way is more simple to create new archetypes with backwards
>> compatibility.
>>>
>>> What do you think?
>>>
>>> --
>>> 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

_______________________________________________

openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

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

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Thomas Beale-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 03/10/2011 15:23, pablo pazos wrote:

Hi everyone,

I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework).

Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it.

Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).

Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().

if you have a look at the RM specification for ITEM_STRUCTURE (p13-), you will see that the interfaces are quite different across all the classes - the ITEM_TABLE type has table-specific accessor functions, and the LIST type has an interface specific to a list. But... see below...

Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility.


What do you think?

this seems to be the conclusion of people creating archetypes as well. It has turned out over the years that archetype modellers are far less able to stick to any particular data structure than one might have thought. I don't think the statically declared RM type is the main issue in archetype authoring - it is the archetype paths that really matter... but if neither were to change over time, that certainly makes things easier. The two data types we thought would be used quite often were ITEM_LIST and ITEM_TABLE. It appears that these types have been used pretty rarely, although that might just reflect which parts of medicine have been modelled.

Sam and no doubt others have proposed simplifications to the ITEM_STRUCTURE part of the model, and I would have no problem with simplifying it. However.... there are already openEHR operational systems in existence and a lot of tools and archetypes, so we can't simply make breaking changes to the release 1.x reference model - and - ITEM_STRUCTURE appears in a lot of places in the model. I have not made a proper analysis, but a general approach to simplifying things would probably involve adding an attribute to ITEM_STRUCTURE to indicate which kind of logical structure it was meant to be (as in the 13606 model ITEM.item_category attribute), and then always using an ITEM_TREE in archetypes. This would still enable the types ITEM_TABLE and ITEM_LIST to be implemented in software and to be able to 'adopt' the data of an ITEM_TREE containing the appropriate logical marker.

Other more radical approaches will probably break the current RM and would need an alternative openEHR 2.x RM.

- thomas


_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Pablo Pazos Gutierrez]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi!

Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.


Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists.



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

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Thomas Beale-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 04/10/2011 16:18, pablo pazos wrote:

Hi!

Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.


Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists.

yep there is - post a problem report issue here.

- thomas


_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Erik Sundvall-2]

Hi!

Perhaps the following image with UML redesign useful as input for a
2.0 development fork:
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
The accompanying mail describing it is at
http://www.openehr.org/mailarchives/openehr-technical/msg05285.html

I have right now submitted parts of that mail as a formal change request at:
http://www.openehr.org/issues/browse/SPECPR-73
Feel free to add all your own thoughts from this discussion to that issue.

The argument that there are systems with 1.X data is of course valid
for refreshing 1.X one more time, but a 2.X version of the RM should
not wait too long since we'd like to have as much as possible of
future patient data to be in 2.X form.

Does anybody have an approximate number indicating how many patient
records are now in 1.X systems? Do you believe those system owners
with real patient data could be able to convert data to a 2.X based
systems, I guess there aren't too many vendors involved...

Best regards,
Erik Sundvall
erik.sundvall@... http://www.imt.liu.se/~erisu/  Tel: [phone]

P.s. There was no way of specifying in jira that it could relate to a
2.0 release

On Tue, Oct 4, 2011 at 10:32, Thomas Beale
<thomas.beale@...> wrote:

> On 03/10/2011 15:23, pablo pazos wrote:
>
> Hi everyone,
>
> I've been studying how to simplify the ITEM_STRUCTURE model to enhance the
> persistence performance of our Open EHR-Gen project
> (http://code.google.com/p/open-ehr-gen-framework).
>
> Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE
> in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> arguments and hear your comments about it.
>
> Semantic argument: As I understand ITEM_SINGLE, the semantics of this class
> are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean
> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>
> Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as
> an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> interface of each class can be the same, like: getItems(), setItems(), the
> ITEM_SINGLE breaks that with getItem() and setItem().
>
> if you have a look at the RM specification for ITEM_STRUCTURE (p13-), you
> will see that the interfaces are quite different across all the classes -
> the ITEM_TABLE type has table-specific accessor functions, and the LIST type
> has an interface specific to a list. But... see below...
>
>
> Evolution argument: If I have an archetype with an ITEM_SINGLE, but the
> concept modeled with this archetype needs to change adding more nodes to the
> archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but
> if the archetype is modeled with an ITEM_TREE, I can add any nodes without
> changing the ITEM_STRUCTURE type. I think this way is more simple to create
> new archetypes with backwards compatibility.
>
>
> What do you think?
>
> this seems to be the conclusion of people creating archetypes as well. It
> has turned out over the years that archetype modellers are far less able to
> stick to any particular data structure than one might have thought. I don't
> think the statically declared RM type is the main issue in archetype
> authoring - it is the archetype paths that really matter... but if neither
> were to change over time, that certainly makes things easier. The two data
> types we thought would be used quite often were ITEM_LIST and ITEM_TABLE. It
> appears that these types have been used pretty rarely, although that might
> just reflect which parts of medicine have been modelled.
>
> Sam and no doubt others have proposed simplifications to the ITEM_STRUCTURE
> part of the model, and I would have no problem with simplifying it.
> However.... there are already openEHR operational systems in existence and a
> lot of tools and archetypes, so we can't simply make breaking changes to the
> release 1.x reference model - and - ITEM_STRUCTURE appears in a lot of
> places in the model. I have not made a proper analysis, but a general
> approach to simplifying things would probably involve adding an attribute to
> ITEM_STRUCTURE to indicate which kind of logical structure it was meant to
> be (as in the 13606 model ITEM.item_category attribute), and then always
> using an ITEM_TREE in archetypes. This would still enable the types
> ITEM_TABLE and ITEM_LIST to be implemented in software and to be able to
> 'adopt' the data of an ITEM_TREE containing the appropriate logical marker.
>
> Other more radical approaches will probably break the current RM and would
> need an alternative openEHR 2.x RM.
>
> - thomas
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Pablo Pazos Gutierrez]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Done: http://www.openehr.org/issues/browse/SPECPR-74

--
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 Oct 2011 17:07:27 +0100
From: thomas.beale@...
To: openehr-clinical@...
Subject: Re: Questions about the necessity of ITEM_SINGLE

On 04/10/2011 16:18, pablo pazos wrote:

Hi!

Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.


Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists.

yep there is - post a problem report issue here.

- thomas


_______________________________________________ openEHR-clinical mailing list openEHR-clinical@... http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Sam Heard-3]

Hi Eric,

The serialisation in XML Schema should provide the basis for transformation
I would have thought. If there is a standard transformation then we can
share data based on a previous reference model.

Is that sensible?

Cheers, Sam

> -----Original Message-----
> From: openehr-technical-bounces@... [mailto:openehr-technical-
> bounces@...] On Behalf Of Erik Sundvall
> Sent: Wednesday, 5 October 2011 6:58 PM
> To: For openEHR clinical discussions; For openEHR technical discussions
> Subject: Re: Questions about the necessity of ITEM_SINGLE
>
> Hi!
>
> Perhaps the following image with UML redesign useful as input for a
> 2.0 development fork:
> http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
> The accompanying mail describing it is at
> http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
>
> I have right now submitted parts of that mail as a formal change
> request at:
> http://www.openehr.org/issues/browse/SPECPR-73
> Feel free to add all your own thoughts from this discussion to that
> issue.
>
> The argument that there are systems with 1.X data is of course valid
> for refreshing 1.X one more time, but a 2.X version of the RM should
> not wait too long since we'd like to have as much as possible of
> future patient data to be in 2.X form.
>
> Does anybody have an approximate number indicating how many patient
> records are now in 1.X systems? Do you believe those system owners
> with real patient data could be able to convert data to a 2.X based
> systems, I guess there aren't too many vendors involved...
>
> Best regards,
> Erik Sundvall
> erik.sundvall@... http://www.imt.liu.se/~erisu/  Tel: [phone]
>
> P.s. There was no way of specifying in jira that it could relate to a
> 2.0 release
>
> On Tue, Oct 4, 2011 at 10:32, Thomas Beale
> <thomas.beale@...> wrote:
> > On 03/10/2011 15:23, pablo pazos wrote:
> >
> > Hi everyone,
> >
> > I've been studying how to simplify the ITEM_STRUCTURE model to
> enhance the
> > persistence performance of our Open EHR-Gen project
> > (http://code.google.com/p/open-ehr-gen-framework).
> >
> > Now I'm reaching a point in which I doubt about the necessity of
> ITEM_SINGLE
> > in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> > arguments and hear your comments about it.
> >
> > Semantic argument: As I understand ITEM_SINGLE, the semantics of this
> class
> > are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I
> mean
> > that: the semantics of ITEM_SINGLE is just a matter of cardinality
> (=1).
> >
> > Practical argument: in practice, an ITEM_SINGLE is like using an
> ELEMENT as
> > an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> > interface of each class can be the same, like: getItems(),
> setItems(), the
> > ITEM_SINGLE breaks that with getItem() and setItem().
> >
> > if you have a look at the RM specification for ITEM_STRUCTURE (p13-),
> you
> > will see that the interfaces are quite different across all the
> classes -
> > the ITEM_TABLE type has table-specific accessor functions, and the
> LIST type
> > has an interface specific to a list. But... see below...
> >
> >
> > Evolution argument: If I have an archetype with an ITEM_SINGLE, but
> the
> > concept modeled with this archetype needs to change adding more nodes
> to the
> > archetype, I need to change the ITEM_SINGLE to another
> ITEM_STRUCTURE, but
> > if the archetype is modeled with an ITEM_TREE, I can add any nodes
> without
> > changing the ITEM_STRUCTURE type. I think this way is more simple to
> create
> > new archetypes with backwards compatibility.
> >
> >
> > What do you think?
> >
> > this seems to be the conclusion of people creating archetypes as
> well. It
> > has turned out over the years that archetype modellers are far less
> able to
> > stick to any particular data structure than one might have thought. I
> don't
> > think the statically declared RM type is the main issue in archetype
> > authoring - it is the archetype paths that really matter... but if
> neither
> > were to change over time, that certainly makes things easier. The two
> data
> > types we thought would be used quite often were ITEM_LIST and
> ITEM_TABLE. It
> > appears that these types have been used pretty rarely, although that
> might
> > just reflect which parts of medicine have been modelled.
> >
> > Sam and no doubt others have proposed simplifications to the
> ITEM_STRUCTURE
> > part of the model, and I would have no problem with simplifying it.
> > However.... there are already openEHR operational systems in
> existence and a
> > lot of tools and archetypes, so we can't simply make breaking changes
> to the
> > release 1.x reference model - and - ITEM_STRUCTURE appears in a lot
> of
> > places in the model. I have not made a proper analysis, but a general
> > approach to simplifying things would probably involve adding an
> attribute to
> > ITEM_STRUCTURE to indicate which kind of logical structure it was
> meant to
> > be (as in the 13606 model ITEM.item_category attribute), and then
> always
> > using an ITEM_TREE in archetypes. This would still enable the types
> > ITEM_TABLE and ITEM_LIST to be implemented in software and to be able
> to
> > 'adopt' the data of an ITEM_TREE containing the appropriate logical
> marker.
> >
> > Other more radical approaches will probably break the current RM and
> would
> > need an alternative openEHR 2.x RM.
> >
> > - thomas
> >
> >
> > _______________________________________________
> > openEHR-clinical mailing list
> > openEHR-clinical@...
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
> >
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Sam Heard-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi

 

My (clinician’s thinking) idea was to have ITEM_STRUCTURE inherit from Cluster (it is a fancy one anyway). This would make ITEM_TREE and ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster to only allow ELEMENTS.

 

ITEM_TABLE could then have additional attributes .

 

Cheers, Sam

 

From: openehr-clinical-bounces@... [mailto:openehr-clinical-bounces@...] On Behalf Of pablo pazos
Sent: Thursday, 6 October 2011 5:22 AM
To: openehr clinical
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Done: http://www.openehr.org/issues/browse/SPECPR-74

--
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 Oct 2011 17:07:27 +0100
From: thomas.beale@...
To: openehr-clinical@...
Subject: Re: Questions about the necessity of ITEM_SINGLE

On 04/10/2011 16:18, pablo pazos wrote:

Hi!

Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.


Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists.

yep there is - post a problem report issue here.

- thomas


_______________________________________________ openEHR-clinical mailing list openEHR-clinical@... http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[Heath Frankel-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Sam,

The problem with this is that we currently use the RM inheritance to assist in these structure constraints, i.e. an ITEM_LIST only contains a CLUSTER containing only ELEMENTs.  However, if you think about it, the semantics of CLUSTER and ITEM_TREE are equivalent.  It is only the level in the model that is different.  The question is, would it be helpful to have other ITEM_STRUCTURE subtypes within an ITEM_STRUCTURE, i.e. an ITEM_TREE containing an ITEM_LIST or ITEM_TABLE.  This is certainly the case in CEN13606 with the mandatory CLUSTER.structure_type attribute.

 

I think we need to go back and ask, why are we trying to simplify ITEM_STRUCTURE?  Are we doing it to simplify the RM, archetypes or data?

 

For me the data is of interest and it is about 10 years since I first questioned Thomas about the need for ITEM_STRUCTURE.  Not only does it lengthen paths but it requires a whole level in data that is necessary and requires mandatory structural only attribute values such as node_id and name.

 

From a domain model perspective I see the value of supporting additional properties and methods on these sub-classes but in a persistence model they add no value, we just need to know which domain class to materialise.  In XML this can be done using the built-in schema type attribute and this approach would support XML-class generator libraries, whereas using the CEN 13606 model defined attribute would require an additional adapter to materialise the domain model class.  My point is, we probably need to separate the RM representation from the persistence ITS.  Even with the current RM, we could probably simplify the XML schema to collapse this level of data, although we still need a way to represent the mandatory node_id and name attributes of the ITEM_STRCTURE.  This would be easier if they were not mandatory, but that is topic for another day.

 

However, if we want a RM change with migration path, the minimal change that I can see is to make ITEM inherit from ITEM_STRUCTURE.  We could make the ITEM_SINGLE, ITEM_TREE, ITEM_TABLE and ITEM_LIST sub type of CLUSTER but the only true sub type of CLUSTER is ITEM_TREE.  In future we could merge CLUSTER and ITEM_TREE and remove ITEM_SINGLE.

 

Regards

 

Heath

 

From: openehr-clinical-bounces@... [mailto:openehr-clinical-bounces@...] On Behalf Of Sam Heard
Sent: Monday, 10 October 2011 1:40 PM
To: 'For openEHR clinical discussions'
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Hi

 

My (clinician’s thinking) idea was to have ITEM_STRUCTURE inherit from Cluster (it is a fancy one anyway). This would make ITEM_TREE and ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster to only allow ELEMENTS.

 

ITEM_TABLE could then have additional attributes .

 

Cheers, Sam

 

From: openehr-clinical-bounces@... [mailto:openehr-clinical-bounces@...] On Behalf Of pablo pazos
Sent: Thursday, 6 October 2011 5:22 AM
To: openehr clinical
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Done: http://www.openehr.org/issues/browse/SPECPR-74

--
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 Oct 2011 17:07:27 +0100
From: thomas.beale@...
To: openehr-clinical@...
Subject: Re: Questions about the necessity of ITEM_SINGLE

On 04/10/2011 16:18, pablo pazos wrote:

Hi!

Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.


Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists.

yep there is - post a problem report issue here.

- thomas


_______________________________________________ openEHR-clinical mailing list openEHR-clinical@... http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical