Re: Party-actor-folder relationships in hierarchy

[Ian McNicoll]

So perhaps someone could consider adding demographic support? The source is
at  https://github.com/openEHR/adl-designer.

ian



Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 28 November 2015 at 20:15, Bert Verhees  wrote:

> On 28-11-15 18:29, pazospa...@hotmail.com wrote:
>
> Did anyone tried the marand's online editor with the demographic model?
> Opinions?
>
>
> I believe it does not support demographic archetypes, if this link is the
> right one
>
> http://ehrscape.*marand*.si/designer/*archetype-editor*.html
>
> ___
> 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: Party-actor-folder relationships in hierarchy

[Ian McNicoll]

Thanks Peter,

Yes. I did make a start on this a few years back but got bogged down in not
being families with the ui aspects by which time the LinkEhr editor was
handling Demographics archetypes nicely.

I think this another opportunity to remind everyone that openEHR is a
community that relies almost entirely on volunteer efforts to build and
maintain the specs, software and clinical content models. Historically
companies like Ocean have put a lot of effort into building tools which are
open source but inevitably the direction and effort will mirror the
requirements of their customers. Since the archetype editor is open source,
others who see a need for demographics support are free to add this. I will
be very happy to put my initial efforts up on a fork if others want to take
it forward.

I am sure we would all sign up to a future where this kind of critical
tooling work was underpinned by solid funding by we simply do not have that
luxury right now.

Ian
On Fri, 27 Nov 2015 at 21:42, Peter Gummer <
peter.gum...@oceaninformatics.com> wrote:

> On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
> >
> > Anyway, the Ocean Archetype-Editor (does it support demographics now?)
> is not the OpenEHR specification, it is just an implementation.
>
>
> Hi Bert,
>
> No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes and
> improvements to the EHR support have always been higher priority in the
> past, according to the tool's users.
>
> Ian McNicoll did make some progress on demographic support a few years ago
> and he said it was looking like it wouldn’t be too difficult, but I guess
> other priorities must have intervened.
>
> Peter
> ___
> 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: Party-actor-folder relationships in hierarchy

[Bert Verhees]

I understand,  Peter and Ian, maybe I will build one within a few months, I
have planned it, if nothing urgent comes between. It is not very
complicated to do.

Bert
Op 28 nov. 2015 12:44 schreef "Ian McNicoll" :

> Thanks Peter,
>
> Yes. I did make a start on this a few years back but got bogged down in
> not being families with the ui aspects by which time the LinkEhr editor was
> handling Demographics archetypes nicely.
>
> I think this another opportunity to remind everyone that openEHR is a
> community that relies almost entirely on volunteer efforts to build and
> maintain the specs, software and clinical content models. Historically
> companies like Ocean have put a lot of effort into building tools which are
> open source but inevitably the direction and effort will mirror the
> requirements of their customers. Since the archetype editor is open source,
> others who see a need for demographics support are free to add this. I will
> be very happy to put my initial efforts up on a fork if others want to take
> it forward.
>
> I am sure we would all sign up to a future where this kind of critical
> tooling work was underpinned by solid funding by we simply do not have that
> luxury right now.
>
> Ian
> On Fri, 27 Nov 2015 at 21:42, Peter Gummer <
> peter.gum...@oceaninformatics.com> wrote:
>
>> On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
>> >
>> > Anyway, the Ocean Archetype-Editor (does it support demographics now?)
>> is not the OpenEHR specification, it is just an implementation.
>>
>>
>> Hi Bert,
>>
>> No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes
>> and improvements to the EHR support have always been higher priority in the
>> past, according to the tool's users.
>>
>> Ian McNicoll did make some progress on demographic support a few years
>> ago and he said it was looking like it wouldn’t be too difficult, but I
>> guess other priorities must have intervened.
>>
>> Peter
>> ___
>> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Party-actor-folder relationships in hierarchy

[pazospablo]

Did anyone tried the marand's online editor with the demographic model? 
Opinions?
Sent from my LG Mobile


-- Original message--From: Ian McNicollDate: Sat, Nov 28, 2015 8:44 
AMTo: For openEHR technical discussions;Subject:Re: Party-actor-folder 
relationships in hierarchyThanks Peter,

Yes. I did make a start on this a few years back but got bogged down in not  
being families with the ui aspects by which time the LinkEhr editor was 
handling Demographics archetypes nicely. 

I think this another opportunity to remind everyone that openEHR is a community 
that relies almost entirely on volunteer efforts to build and maintain the 
specs, software and clinical content models. Historically companies like Ocean 
have put a lot of effort into building tools which are open source but 
inevitably the direction and effort will mirror the requirements of their 
customers. Since the archetype editor is open source, others who see a need for 
demographics support are free to add this. I will be very happy to put my 
initial efforts up on a fork if others want to take it forward. 

I am sure we would all sign up to a future where this kind of critical tooling 
work was underpinned by solid funding by we simply do not have that luxury 
right now. 

Ian 
On Fri, 27 Nov 2015 at 21:42, Peter Gummer  
wrote:
On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
>
> Anyway, the Ocean Archetype-Editor (does it support demographics now?) is not 
> the OpenEHR specification, it is just an implementation.


Hi Bert,

No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes and 
improvements to the EHR support have always been higher priority in the past, 
according to the tool's users.

Ian McNicoll did make some progress on demographic support a few years ago and 
he said it was looking like it wouldn’t be too difficult, but I guess other 
priorities must have intervened.

Peter
___
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: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 28-11-15 18:29, pazospa...@hotmail.com wrote:


Did anyone tried the marand's online editor with the demographic 
model? Opinions?



I would not advise to use an online archetype-editor, if you want your 
archetypes and templates to be private IP.


It is good for students and newcomers who want to test some ideas, or 
for companies which go open source anyway, but for people wanting to 
build a private medical business and have their medical business ideas 
expressed in archetypes and templates, the idea of an online editor in 
hands of a competing commercial company is not always a comfortable idea.


I experienced more people, not necessary on this list, feel the same.

Bert

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 28-11-15 18:29, pazospa...@hotmail.com wrote:


Did anyone tried the marand's online editor with the demographic 
model? Opinions?



I believe it does not support demographic archetypes, if this link is 
the right one


http://ehrscape./marand/.si/designer//archetype-editor/.html
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

Thank you, Thomas

Now I understand that I:

1) can store list of actors (organizations, users, roles etc) in some external 
storage
2) shall avoid to store whatever demographic information in an EHR storage - 
except for PARTY identifiers (issued by some external system)
3) can connect participants in both systems by their IDs

> A couple of words of advice: normally, EHR and demographics 'databases' would 
> be separated for security and operational reasons. EHRs are not normally 
> 'inside' any demographic entities. This section in the openEHR Architectural 
> Overview may be helpful; also this one.
>
> If you are cohosting what are logically separate EHR repositories on a cloud 
> service, openEHR does not say anything much about how to organise them, 
> although you should consider carefully implementing an 'EHR / subject 
> cross-reference' service as briefly described here.
>
> You also need to consider how to implement RBAC, and 'legitimate 
> relationship' so that only the right people can see the right EHRs.
>
> - thomas
-- 
Regards, Dmitry

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

Re: Party-actor-folder relationships in hierarchy

[Thomas Beale]

A couple of words of advice: normally, EHR and demographics 'databases' 
would be separated for security and operational reasons. EHRs are not 
normally 'inside' any demographic entities. This section 
in 
the openEHR Architectural Overview may be helpful; also this one 
.


If you are cohosting what are logically separate EHR repositories on a 
cloud service, openEHR does not say anything much about how to organise 
them, although you should consider carefully implementing an 'EHR / 
subject cross-reference' service as briefly described here 
.


You also need to consider how to implement RBAC, and 'legitimate 
relationship' so that only the right people can see the right EHRs.


- thomas

On 26/11/2015 22:36, Dmitry Baranov wrote:

Hi, I have a lot of practical questions to ask :)

Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:

- Database
   [C] ACME company (1.1.1.1)
 [S] EHR System 1 (1.1.1.1.1)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items

 [S] EHR System 2 (1.1.1.1.2)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items



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

RE: Party-actor-folder relationships in hierarchy

[pablo pazos]

Hi Dmitry, OBJECT_ID can point to the uid inherited from LOCATABLE, but as you 
can see in the model 
(http://openehr.org/releases/1.0.2/architecture/rm/common_im.pdf page 13), uid 
is optional. I wouldn't like to have my references rely on an optional 
attribute. I didn't designed the model, but that seems reasonable to me.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> From: barano...@yandex.ru
> To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
> Subject: Re: Party-actor-folder relationships in hierarchy
> Date: Fri, 27 Nov 2015 11:11:06 +0300
> 
> > Hi Dmitry,
> >
> > Consider that the folder structure is defined for each EHR, and can vary 
> > vary between ehrs inside the same company.
> > I would use LINK to link the org to the ehr folder struct.
> 
> (ORGANIZATION as LOCATABLE).links[0] points to a folder/versioned folder 
> through URI? 
> 
> Thank you Pablo, good idea. Hard to guarantee referential integrity, but...
> Why is it no class to link two entities using theirs OBJECT_ID? :)
> 
> -- 
> Regards, Dmitry
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Party-actor-folder relationships in hierarchy

[Peter Gummer]

On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
> 
> Anyway, the Ocean Archetype-Editor (does it support demographics now?) is not 
> the OpenEHR specification, it is just an implementation.


Hi Bert,

No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes and 
improvements to the EHR support have always been higher priority in the past, 
according to the tool's users.

Ian McNicoll did make some progress on demographic support a few years ago and 
he said it was looking like it wouldn’t be too difficult, but I guess other 
priorities must have intervened.

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

RE: Party-actor-folder relationships in hierarchy

[Sebastian Garde]

...or if it is for an archetype, you can raise a Change Request directly for 
that archetype on CKM, e.g. for the Patient name archetype here: 
http://openehr.org/ckm/#showArchetype_1013.1.477_CHANGEREQUESTS

Regards
Sebastian
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Freitag, 27. November 2015 10:28
To: openehr-technical@lists.openehr.org
Subject: Re: Party-actor-folder relationships in hierarchy


If people want specific changes to the specifications, please raise a Problem 
Report in the usual 
place<https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-132?filter=allopenissues>.
 Otherwise we don't know what the specific shortcomings are.

- thomas
On 27/11/2015 09:02, Bert Verhees wrote:
On 27-11-15 09:56, Dmitry Baranov wrote:

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, by the way

That is a point, why is it not like that in OpenEHR or EN13606?

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 27-11-15 10:27, Thomas Beale wrote:


If people want specific changes to the specifications, please raise a 
Problem Report in the usual place 
. 
Otherwise we don't know what the specific shortcomings are.


I would do that, now it comes to mind, but first I wanted to discuss it, 
because the different approach to demographics through the years, also 
in 13606, made me unsure about their legitimacy as ultrastructure.


I am happy to read that this will be changed in  RM 1.0.3, so reporting 
it would not be necessary now, I guess.


Thanks for your reply

Bert


- thomas

On 27/11/2015 09:02, Bert Verhees wrote:

On 27-11-15 09:56, Dmitry Baranov wrote:

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, 
by the way


That is a point, why is it not like that in OpenEHR or EN13606?

___
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


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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 27-11-15 10:34, Bert Verhees wrote:

as ultrastructure.

as ultrastructure.???

Must be "information-structure" (sorry)

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 27-11-15 10:33, Sebastian Garde wrote:
…or if it is for an archetype, you can raise a Change Request directly 
for that archetype on CKM,

I just did it, thanks for the tip

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

Re: Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, by the way

> In Spanish/Portuguese orientated countries they treat lastnames
> different, so the archetypes were not really good usable in other countries.
> But it remained like this for years.
> You can still see its roots in Portuguese, and the name-handling is not
> well adjusted *).


-- 
Regards, Dmitry

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 27-11-15 09:56, Dmitry Baranov wrote:

I agree that demographic details can be expressed via archetypes.
Actors/Participation/Names etc are elaborated well in HL7 CDA spec, by the way


That is a point, why is it not like that in OpenEHR or EN13606?

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

Re: Party-actor-folder relationships in hierarchy

[Thomas Beale]

Hi Bert,

there is no 'policy' about treating the Demographics specification as 
'inferior'. The practical point about demographics is that it is often 
not implemented because many clinical IT environments  already have an 
MPI, so an openEHR EHR system typically implements the 
PARTY_PROXY.external_ref pointers 
from 
the EHR data instead.


But some environments need an openEHR demographic service, and I predict 
more will, even when they have an MPI, because the MPI data is not 
versioned or extensible.


Release 1.0.3 of the ITS component will have XSDs for everything. This 
release is likely to be out by the end of the year or very soon afterward.


- thomas

On 27/11/2015 08:33, Bert Verhees wrote:

I think it is very easy to solve.

The premise is that several legal entities are sharing patients, and 
also share an EHR system, and you want to distinguish which treatment 
is given by which legal institution.


It is easy, build your system so, that all compositions are also 
placed in folders pointing to the legal institutions which gave the 
treatment.
As you maybe know, a composition can be in several folders 
simultaneously.


So you can have a folder-system representing legal institutions that 
share the EHR-system, and folder systems on medical reasons.


In this way it is easy to organize authorizations related to the legal 
entities, and also other queries



I discovered the demography.xsd just yesterday, accidentally, on LiU 
github :)
For some reason it is missing here - 
http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/


That is something funny, demographics are something which are treated 
as a stepchild, not only in OpenEHR, but also in EN13606. In EN13606, 
demographics can't even be archetype.
In OpenEHR, I remember a message on the list, some years ago, I 
thought written by Sam Heard, that it should be replaced by non 
semantical generic structures, which also exist in OpenEHR.


But fact is indeed that there is always something with it.

In LinkEHR-archetype-editor they have a demographics.xsd, you can 
download it when you download their editor.  In LinkEHR they also have 
a demographics.xsd for EN13606, although this should not be 
archetypable at all.


I would be interested what people think about this way demographics 
are treated as a kind of inferior information-structure.


I think we need an answer from the OpenEHR foundation as it must be a 
defined policy to do it this way.


Bert



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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

That is something funny, demographics are something which are treated 
as a stepchild, not only in OpenEHR, ..


It is even so that in CKM for long time where no demographics archetypes 
at all. Until a moment, some years ago, in 2009, Sergio Miranda Freire 
posted them, a Brazilian version.
In Spanish/Portuguese orientated countries they treat lastnames 
different, so the archetypes were not really good usable in other countries.

But it remained like this for years.
You can still see its roots in Portuguese, and the name-handling is not 
well adjusted *).


Look at the history, it has been like that since 2010.
The question is, why is that?

Not for accusing or something stupid, but I want to know why this is.
Can someone explain this?


*)
To avoid a distracting discussion I explain it here:
In the archetype is:
ELEMENT[at0003] occurrences matches {0..*} matches {  -- Family Name
 value matches {
 DV_TEXT matches {*}
}
}
ELEMENT[at0004] occurrences matches {0..*} matches 
{  -- Name Title

  value matches {
  DV_TEXT matches {*}
 }
}
ELEMENT[at0005] occurrences matches {0..*} matches 
{  -- Name Suffix

  value matches {
  DV_TEXT matches {*}
 }
}

Because in Spanish speaking countries people often use their mothers 
name as second last-name. In non Spanish speaking countries this never done.
So, the archetype is right to give opportunity to have more 
family-names, but the archetype fails in connecting name-suffixes to 
family-names.


It should have been like this (every last-name can have a name-suffix 
and maybe also a name-title:

CLUSTER occurrences matches {0..*} matches {-- Family Name
ELEMENT[at0003] occurrences matches {1} matches {  -- Family Name
 value matches {
 DV_TEXT matches {*}
}
}
ELEMENT[at0004] occurrences matches {0..*} matches 
{  -- Name Title

  value matches {
  DV_TEXT matches {*}
 }
}
ELEMENT[at0005] occurrences matches {1} matches {  
-- Name Suffix

  value matches {
  DV_TEXT matches {*}
 }
}
}




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

Re: Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

> Hi Dmitry,
>
> Consider that the folder structure is defined for each EHR, and can vary vary 
> between ehrs inside the same company.
> I would use LINK to link the org to the ehr folder struct.

(ORGANIZATION as LOCATABLE).links[0] points to a folder/versioned folder 
through URI? 

Thank you Pablo, good idea. Hard to guarantee referential integrity, but...
Why is it no class to link two entities using theirs OBJECT_ID? :)

-- 
Regards, Dmitry

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

I think it is very easy to solve.

The premise is that several legal entities are sharing patients, and 
also share an EHR system, and you want to distinguish which treatment is 
given by which legal institution.


It is easy, build your system so, that all compositions are also placed 
in folders pointing to the legal institutions which gave the treatment.

As you maybe know, a composition can be in several folders simultaneously.

So you can have a folder-system representing legal institutions that 
share the EHR-system, and folder systems on medical reasons.


In this way it is easy to organize authorizations related to the legal 
entities, and also other queries




I discovered the demography.xsd just yesterday, accidentally, on LiU github :)
For some reason it is missing here - 
http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/

That is something funny, demographics are something which are treated as 
a stepchild, not only in OpenEHR, but also in EN13606. In EN13606, 
demographics can't even be archetype.
In OpenEHR, I remember a message on the list, some years ago, I thought 
written by Sam Heard, that it should be replaced by non semantical 
generic structures, which also exist in OpenEHR.


But fact is indeed that there is always something with it.

In LinkEHR-archetype-editor they have a demographics.xsd, you can 
download it when you download their editor.  In LinkEHR they also have a 
demographics.xsd for EN13606, although this should not be archetypable 
at all.


I would be interested what people think about this way demographics are 
treated as a kind of inferior information-structure.


I think we need an answer from the OpenEHR foundation as it must be a 
defined policy to do it this way.


Bert

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 27-11-15 10:23, Thomas Beale wrote:
there is no 'policy' about treating the Demographics specification as 
'inferior'.

I think I need to explain how and why I thought that.

I found the message which caused my recollection that demographic 
information structures were regarded as inferior structures.

It was related to the OpenEHR Archetype Editor
My memory was not 100% correct regarding to this. But it had some point, 
see following messages.


Sam said that demographics were not part of the EHR, and so there was no 
need for the archetype-editor to support them.


http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004423.html

In this message he also indicates that in the EHR can generic 
cluster-structures be used to store names and addresses.


http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004437.html

Anyway, the Ocean Archetype-Editor (does it support demographics now?) 
is not the OpenEHR specification, it is just an implementation.


Sorry for my misunderstanding. It lived in my head for six years, and 
the message of Dimitry brought it to conscious level again.


;-)

No harm done, I hope

Bert


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

Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

Hi, I have a lot of practical questions to ask :)

Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:

- Database
  [C] ACME company (1.1.1.1)
[S] EHR System 1 (1.1.1.1.1)
 - Root folder 1
   - Folders
   - Items
 - Root folder 2
   - Folders
   - Items

[S] EHR System 2 (1.1.1.1.2)
 - Root folder 1
   - Folders
   - Items
 - Root folder 2
   - Folders
   - Items

  [C] Good Health Company (1.1.1.2)
[S] EHR System 3 (1.1.1.2.1)
 - Root folder 1
   - Folders
   - Items
 - Root folder 2
   - Folders
   - Items

[S] EHR System 4 (1.1.1.2.2)
 - Root folder 1
   - Folders
   - Items
 - Root folder 2
   - Folders
   - Items


The question is: how could I implement such a hierarchy using pure 1.0.1/1.0.2 
classes not using custom object model extensions? 

As far as I understand, a company can be described either by PARTY_IDENTIFIED 
or ORGANIZATION (by the way, where is Demographic.xsd in official releases?) 
and identified by OID. 
How could I describe a EHR system? In which role is it (probably AGENT)? 
And how do I link a FOLDER to a PARTY/PARTY_IDENTIFIED? 
Thanks in advance



-- 
Regards, Dmitry

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

Re: Party-actor-folder relationships in hierarchy

[Bert Verhees]

My two cents,

I believe OpenEHR is patient-centric, and a patient can have treatment 
in more healthcare-centra.


So the patient should be on the root of an EHR, and the 
healthcare-organisation should somewhere appropriate being linked to a 
specific treatment/composition, received in that organization.


Bert

On 26-11-15 23:36, Dmitry Baranov wrote:

Hi, I have a lot of practical questions to ask :)

Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:

- Database
   [C] ACME company (1.1.1.1)
 [S] EHR System 1 (1.1.1.1.1)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items

 [S] EHR System 2 (1.1.1.1.2)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items

   [C] Good Health Company (1.1.1.2)
 [S] EHR System 3 (1.1.1.2.1)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items

 [S] EHR System 4 (1.1.1.2.2)
  - Root folder 1
- Folders
- Items
  - Root folder 2
- Folders
- Items


The question is: how could I implement such a hierarchy using pure 1.0.1/1.0.2 
classes not using custom object model extensions?

As far as I understand, a company can be described either by PARTY_IDENTIFIED 
or ORGANIZATION (by the way, where is Demographic.xsd in official releases?) 
and identified by OID.
How could I describe a EHR system? In which role is it (probably AGENT)?
And how do I link a FOLDER to a PARTY/PARTY_IDENTIFIED?
Thanks in advance






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

Re: Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

OK Bert, let's say that an EHR system manages a graph of objects and my idea is 
just a representation of such a graph.

PARTY_IDENTIFIED (Patient) - OBJECT_ID (Patient) - COMPOSITION - OBSERVATION - 
FOLDER - PARTY_IDENTIFIED (Organizaion)

If you like :)

> I believe OpenEHR is patient-centric, and a patient can have treatment
> in more healthcare-centra.
>
> So the patient should be on the root of an EHR, and the
> healthcare-organisation should somewhere appropriate being linked to a
> specific treatment/composition, received in that organization.

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

Re: Party-actor-folder relationships in hierarchy

[pazospablo]

Hi Dmitry,
Consider that the folder structure is defined for each EHR, and can vary vary 
between ehrs inside the same company.I would use LINK to link the org to the 
ehr folder struct.

Sent from my LG Mobile


-- Original message--From: Dmitry BaranovDate: Thu, Nov 26, 2015 7:37 
PMTo: For openEHR technical discussions;Subject:Party-actor-folder 
relationships in hierarchyHi, I have a lot of practical questions to ask 
:)Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:- 
Database  [C] ACME company (1.1.1.1)[S] EHR System 1 (1.1.1.1.1) - Root 
folder 1   - Folders   - Items - Root folder 2   - Folders  
 - Items[S] EHR System 2 (1.1.1.1.2) - Root folder 1   - Folders
   - Items - Root folder 2   - Folders   - Items  [C] Good Health 
Company (1.1.1.2)[S] EHR System 3 (1.1.1.2.1) - Root folder 1   - 
Folders   - Items - Root folder 2   - Folders   - Items[S] 
EHR System 4 (1.1.1.2.2) - Root folder 1   - Folders   - Items 
- Root folder 2   - Folders   - ItemsThe question is: how could I 
implement such a hierarchy using pure 1.0.1/1.0.2 classes not using custom 
object model extensions? As far as I understand, a company can be described 
either by PARTY_IDENTIFIED or ORGANIZATION (by the way, where is 
Demographic.xsd in official releases?) and identified by OID. How could I 
describe a EHR system? In which role is it (probably AGENT)? And how do I link 
a FOLDER to a PARTY/PARTY_IDENTIFIED? Thanks in advance-- Regards, 
Dmitry___openEHR-technical mailing 
listopenEHR-technical@lists.openehr.orghttp://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: Party-actor-folder relationships in hierarchy

[Bert Verhees]

On 26-11-15 23:47, Dmitry Baranov wrote:

OK Bert, let's say that an EHR system manages a graph of objects and my idea is 
just a representation of such a graph.

PARTY_IDENTIFIED (Patient) - OBJECT_ID (Patient) - COMPOSITION - OBSERVATION - 
FOLDER - PARTY_IDENTIFIED (Organizaion)

If you like :)


I don't get your question in the way you ask it. Let me explain it my 
way, maybe it becomes clear then.


The root of an patient-EMD is the EHR (with rootfolder), and there is 
the patient linked to.
If an EHR system is shared by more organizations, there share also 
patients, I guess. Else I don't get the point from sharing. There is no 
root where all patients/EHRs are together, so there is no organization-root.

As said, it is patient centric.

So a patient retrieves treatments, in the organizations, in the 
compositions and the accompanying audit-activity is notated by whom that 
specific treatment was given.


Now about the folders, there is some documentation about how to use 
them, I forgot which document, but you can think of grouping 
compositions which have something specific in common, for example 
diabetics-related.


Beside treatments, a patient can have longer term professional 
relationships with healthcare professionals, you can arrange that with 
party-relationships and roles. Those information exists outside the EHR, 
but is connected the the patients and healthcare professionals. See in 
the demographic reference-model where you can find attributes to store 
this information, in the PARTY class (base of 
person(patient/healthcare-professional) and organization, I think.


I must say I do it all out of my head, I know the reference model, but I 
do not know it exactly in all details.


But ask if it is not clear, maybe I know the answer, or someone else 
knows it better.


Bert





I believe OpenEHR is patient-centric, and a patient can have treatment
in more healthcare-centra.

So the patient should be on the root of an EHR, and the
healthcare-organisation should somewhere appropriate being linked to a
specific treatment/composition, received in that organization.

___
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: Party-actor-folder relationships in hierarchy

[Dmitry Baranov]

> The root of an patient-EMD is the EHR (with rootfolder), and there is
> the patient linked to.
> If an EHR system is shared by more organizations, there share also
> patients, I guess. Else I don't get the point from sharing. 

1. It often occurs that few medical institutions share same building, same 
territory and same database server (as for example a hospital, an out-patient 
clinic and a laboratory), but they are different legal persons.
2. It is easier to administer and support

> There is no root where all patients/EHRs are together, so there is no 
> organization-root.
> As said, it is patient centric.

EHR management system is patient-centric from the physician's point of view, 
but it is definitely organization-centric from the DBA/sysadmin/software 
developer point of view, I believe. For example, a clinician can act as an 
in-patient clinic surgeon in the morning and as traumatologist in the 
out-patient clinic in the nighttime. Such a functional role is related to a 
surgeon logon context, and logon context is definitely bound to an 
organization. 

Logically splitted database may share patient information between 
organizations, or may not, it doesn't matter

> Beside treatments, a patient can have longer term professional
> relationships with healthcare professionals, you can arrange that with
> party-relationships and roles. Those information exists outside the EHR,
> but is connected the the patients and healthcare professionals. See in
> the demographic reference-model where you can find attributes to store
> this information, in the PARTY class (base of
> person(patient/healthcare-professional) and organization, I think.

I discovered the demography.xsd just yesterday, accidentally, on LiU github :) 
For some reason it is missing here - 
http://www.openehr.org/releases/1.0.2/reference-models/openEHR/XSD/

-- 
Regards, Dmitry

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