Re: e-health services landscape - initial proposal, open forum

[Bert Verhees]

I do not see my message appear on the archive. Maybe it has to do with 
formatting, I saw to late that there was quite some formatting in my 
previous message. I try replying without formatting.

Sorry if it will appear twice on the list.

I miss lifestyle and sport-services which are not explicitly problem 
related. Maybe others have other suggestions, but I like to focus on 
these. I think that is the near future, and not already planning them in 
will be a missed chance. The meaning of the term Healthcare will change 
to its true meaning. Care related to Health, not only illness. Lifestyle 
data will be important, already now insurance companies are registering 
if customers smoke or do sport, and which sport. Some people write down 
everything they eat.


People use their smartphone to communicate and exchange information. 
Interestingly, an increasing number of people collect health data on 
their smartphone such as information about their mood, activity level, 
nutrition or vital signs including blood pressure or blood glucose 
levels. Medical research could greatly benefit from these ‘real life’ 
data. I think OpenEhr must be prepared for this to come, give it room, 
embrace it.


The same counts for archetypes, there are no archetypes on CKM which are 
fit to register these kind of things.


I had this discussion already a few times on OpenEhr mailinglists, I 
only got laughters as reply, that is why I hesitate to discuss it here, 
but with this, I give it one more chance, just for fun, not expecting 
any serious result.


On 23-10-18 16:58, Thomas Beale wrote:


Every so often I get bored of what I am doing and start trying to draw 
one of those 'services roadmap' kind of diagrams. These often pretty 
pictures appear in slide presentations, in standards, whitepapers etc, 
but are not often used as a tool to help map out the road ahead. We do 
however need some sort of vision of the future for staking out new 
services. I like my latest version enough that I thought it would be 
worth putting up publicly to get reactions and input.


Please comment and/or add content to the wiki page 
.




- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl 
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: e-health services landscape - initial proposal, open forum

[Bert Verhees]

I miss lifestyle and sport-services which are not explicitly problem 
related. Maybe others have other suggestions, but I like to focus on 
these. I think that is the near future, and not already planning them in 
will be a missed chance. The meaning of the term Healthcare will change 
to its true meaning. Care related to Health, not only illness. Lifestyle 
data will be important, already now insurance companies are registering 
if customers smoke or do sport, and which sport. Some people write down 
everything they eat.


People use their smartphone to communicate and exchange information. 
Interestingly, an increasing number of people collect health data on 
their smartphone such as information about their mood, activity 
level, nutrition or vital signs including blood pressure or blood 
glucose levels. Medical research could greatly benefit from these ‘real 
life’ data. I think OpenEhr must be prepared for this to come, give it 
room, embrace it.


The same counts for archetypes, there are no archetypes on CKM which are 
fit to register these kind of things.


I had this discussion already a few times on OpenEhr mailinglists, I 
only got laughters as reply, that is why I hesitate to discuss it here, 
but with this, I give it one more chance, just for fun, not expecting 
any serious result.



On 23-10-18 16:58, Thomas Beale wrote:


Every so often I get bored of what I am doing and start trying to draw 
one of those 'services roadmap' kind of diagrams. These often pretty 
pictures appear in slide presentations, in standards, whitepapers etc, 
but are not often used as a tool to help map out the road ahead. We do 
however need some sort of vision of the future for staking out new 
services. I like my latest version enough that I thought it would be 
worth putting up publicly to get reactions and input.


Please comment and/or add content to the wiki page 
.




- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl 
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

e-health services landscape - initial proposal, open forum

[Thomas Beale]

Every so often I get bored of what I am doing and start trying to draw 
one of those 'services roadmap' kind of diagrams. These often pretty 
pictures appear in slide presentations, in standards, whitepapers etc, 
but are not often used as a tool to help map out the road ahead. We do 
however need some sort of vision of the future for staking out new 
services. I like my latest version enough that I thought it would be 
worth putting up publicly to get reactions and input.


Please comment and/or add content to the wiki page 
.




- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Diego Boscá]

This could work in some cases, but if I recall correctly that name is
language dependent (i.e. Only one of the archetype translations is used) ,
which would make this difficult to implement in archetypes that have
several languages as you wouldn't be able to easily tell what label is
really there

El mar., 23 oct. 2018 15:25, Sam Heard 
escribió:

> Hi Tom
> If we are using the same archetype for the sender info and receiver data
> then I can see only two sensible options from a design perspective:
> 1) There are two slots...named receiver and sender.
> 2) the designer did not know what might be in here so the person filling
> the slot in the template or the data named them differently.
>
> In many situations it will be critical to differentiated sender and
> receiver unambiguously so a cluster could be a sensible solution. Otherwise
> transfering the name of a slot to the name of the archetype in the slot?
>
> Cheers Sam
>
>
>  Original message 
> From: Thomas Beale 
> Date: 23/10/18 9:50 pm (GMT+10:00)
> To: openehr-technical@lists.openehr.org
> Subject: Re: AW: Unique paths for slots problem if slots are filled with
> same archetype
>
> I'm becoming convinced that we need to make a technical change to allow
> the slot id be stored in the data, as suggested on the discussion thread
> already.
>
> So my suggestion for modellers is: assume it will get solved, and do your
> modelling in the natural / preferred way (i.e. don't introduce hacks like
> extra CLUSTERs), and we'll work out an ADL-level solution.
>
> It would help if you can add any detailed info to the description of the PR
> that Sebastian just created
> .
>
> - thomas
>
>
>
> On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:
>
> Hi all! I hope the SEC will discuss and hopefully solve this issue in the
> upcoming meeting in Oslo. This is fairly serious from a modelling POV, as
> there are some archetypes that are based on the (in my opinion fair)
> assumption that it’s possible to tell two instances of the same CLUSTER in
> two parallel SLOTs apart. An example is “Communication capability”
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not
> having to change the modelling to circumvent the technical issue, if
> possible. 😊
>
>
>
> Regards,
>
> *Silje*
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Sam Heard]

Hi Tom
If we are using the same archetype for the sender info and receiver data then I 
can see only two sensible options from a design perspective:
1) There are two slots...named receiver and sender.
2) the designer did not know what might be in here so the person filling the 
slot in the template or the data named them differently.

In many situations it will be critical to differentiated sender and receiver 
unambiguously so a cluster could be a sensible solution. Otherwise transfering 
the name of a slot to the name of the archetype in the slot?

Cheers Sam


 Original message 
From: Thomas Beale 
Date: 23/10/18 9:50 pm (GMT+10:00)
To: openehr-technical@lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same 
archetype


I'm becoming convinced that we need to make a technical change to allow the 
slot id be stored in the data, as suggested on the discussion thread already.

So my suggestion for modellers is: assume it will get solved, and do your 
modelling in the natural / preferred way (i.e. don't introduce hacks like extra 
CLUSTERs), and we'll work out an ADL-level solution.

It would help if you can add any detailed info to the description of the PR 
that Sebastian just created.

- thomas


On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:
Hi all! I hope the SEC will discuss and hopefully solve this issue in the 
upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there 
are some archetypes that are based on the (in my opinion fair) assumption that 
it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs 
apart. An example is “Communication capability” 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having 
to change the modelling to circumvent the technical issue, if possible. 😊

Regards,
Silje

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

I'm becoming convinced that we need to make a technical change to allow 
the slot id be stored in the data, as suggested on the discussion thread 
already.


So my suggestion for modellers is: assume it will get solved, and do 
your modelling in the natural / preferred way (i.e. don't introduce 
hacks like extra CLUSTERs), and we'll work out an ADL-level solution.


It would help if you can add any detailed info to the description of the 
PR that Sebastian just created 
.


- thomas



On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:


Hi all! I hope the SEC will discuss and hopefully solve this issue in 
the upcoming meeting in Oslo. This is fairly serious from a modelling 
POV, as there are some archetypes that are based on the (in my opinion 
fair) assumption that it’s possible to tell two instances of the same 
CLUSTER in two parallel SLOTs apart. An example is “Communication 
capability” https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. 
We’d prefer not having to change the modelling to circumvent the 
technical issue, if possible. 😊


Regards,

*Silje*



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: AW: Unique paths for slots problem if slots are filled with same archetype

[Bakke, Silje Ljosland]

Hi all! I hope the SEC will discuss and hopefully solve this issue in the 
upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there 
are some archetypes that are based on the (in my opinion fair) assumption that 
it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs 
apart. An example is “Communication capability” 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having 
to change the modelling to circumvent the technical issue, if possible. 😊

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, October 23, 2018 11:21 AM
To: openehr-technical@lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same 
archetype




On 23/10/2018 10:09, Sebastian Garde wrote:
So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?


that would also require adding the slot node id, but I wonder how useful this 
particular query really could be... we never thought of it in 10 years of using 
AQL AFAIK...

- thomas
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

On 23/10/2018 10:09, Sebastian Garde wrote:


So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.


I am not fussed whether it is prepended or appended, I can see tiny 
advantages for both.


The more interesting question to me is whether this is optional and 
only added when really needed or required.


There is this edge case, but I also wonder if a reasonable query on 
data would be to ask for anything inside a specific slot, no matter 
what it is filled with (as e.g. mandated by Template A vs Template B). 
This does not really seem to be (generally) possible - even if there 
are not two identical archetypes in different slots?




that would also require adding the slot node id, but I wonder how useful 
this particular query really could be... we never thought of it in 10 
years of using AQL AFAIK...


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

AW: Unique paths for slots problem if slots are filled with same archetype

[Sebastian Garde]

So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?

Sebastian

Von: openEHR-technical  Im Auftrag 
von Thomas Beale
Gesendet: Montag, 22. Oktober 2018 19:00
An: openehr-technical@lists.openehr.org
Betreff: Re: Unique paths for slots problem if slots are filled with same 
archetype


I need to study this problem a bit more, but having read the posts here, I 
think the solution would potentially to allow the optional addition of a 
'::at' appended to an archetype id at a root point. This means that all 
current systems and data remain valid. It is better if it is appended rather 
than prepended because it means the string id always starts with the archetype 
id (= the case today) and may have something on the end, and that would only be 
the case for this fairly rare use case. It would also be a fairly simple code 
upgrade to existing systems.

So I would agree with Diego's syntax below, but say that it is optional, and 
only required when needed, which appears to be this one edge case. If we can 
convince ourselves of this, this is a pretty easy change to the relevant 
template tools and also ADL2.

thoughts?

- thomas

On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management to be 
compatible with existing tooling, in our typical slot solving methodology 
(non-template mode) the original archetype slot node_id ends in the new object 
node_id. Information about which slot was solved in this node ended in a new 
attribute in the term definitions (we called that attribute 'DCM', but you get 
the idea). We modified the AOM model to have references to both current 
archetype and solved archetype in order to avoid node_id collisions in 
archetype definition time.


I think we have talked before about the need of splitting the archetype_node_id 
attribute into node_id / archetype_id, which I think would solve these 
problems. Another solution would be to include always the node id in the node 
id, even if you are using it to store the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org