Re: Missing support for ISM_TRANSITION/transition in Archetype Editor and Template Designer

On 28 Nov 2015, at 00:36, Ivar Yrke wrote: > > Are there any plans to include transition support in these tools? Is there > anything we are overlooking in our approach? Hi Ivar, Until two years ago the Archetype Editor used to have a Transitions option from the Pathway Specification. It had

Re: Party-actor-folder relationships in hierarchy

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 E

Re: Party-actor-folder relationships in hierarchy

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 participant

Re: Party-actor-folder relationships in hierarchy

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

RE: Party-actor-folder relationships in hierarchy

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 t

Missing support for ISM_TRANSITION/transition in Archetype Editor and Template Designer

Hi We are currently working on an implementation of some process support. We are in general using archetypes for our modelling and we have found Instruction/Action to be well suited for our current need. Actions will tell the current state of each activity and based on this state new steps will

Re: Party-actor-folder relationships in hierarchy

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 stru

Re: Party-actor-folder relationships in hierarchy

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 h

Re: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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.

RE: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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. - thomas On 27/11/2015 09:02, Bert Verh

Re: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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?

Re: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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

Re: Party-actor-folder relationships in hierarchy

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