Re: data element type from the RM

2019-10-09 Thread Pablo Pazos
That is not a RM attribute, is the class. In XML the xsi:type is needed
because for generic types it is not possible to tell the internal structure
without specifying the type. That type is the class in the RM.

On Wed, Oct 9, 2019 at 6:27 AM Georg Fette 
wrote:

> Hello,
> Which is the field that stores the RM-model-type of data elements ? When
> I use the ocean instance generator the json contains a field called
> "@xsi:type", which contains this information. Where in the RM-model
> itself is this type-field defined ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


data element type from the RM

2019-10-09 Thread Georg Fette

Hello,
Which is the field that stores the RM-model-type of data elements ? When 
I use the ocean instance generator the json contains a field called 
"@xsi:type", which contains this information. Where in the RM-model 
itself is this type-field defined ?

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


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


Re: definition of custom fields in archetypes

2019-10-09 Thread Ian McNicoll
Hi Georg,

Yes that is absolutely correct. The archetypes act as a constraint on the
RM so must always be compliant with the RM, and whatever underlying
archetype class is selected. Same applies to templates. Practically
speaking this does still give us a huge amount of flexibility, especially
as we can add cluster archetypes in Slots, which is very useful when trying
to align with legacy system data.

Ian

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



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Wed, 9 Oct 2019 at 08:30, Georg Fette 
wrote:

> Hallo,
> I have a question about the degree of freedom in defining archetypes:
> Archetypes are not composed but rather specified by constraining the
> base classes from the reference model. Hence no new/custom field members
> can be definied in the definition of a new archetype but only the field
> members already existing in the base classes have to be used. So there
> will never be a path like
>
> a/myField/myProperty/value
>
> but always just something like
>
> a/data/events/items/value
>
> The same applies for the definition of templates.
> Is this correct ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> 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


definition of custom fields in archetypes

2019-10-09 Thread Georg Fette

Hallo,
I have a question about the degree of freedom in defining archetypes:
Archetypes are not composed but rather specified by constraining the 
base classes from the reference model. Hence no new/custom field members 
can be definied in the definition of a new archetype but only the field 
members already existing in the base classes have to be used. So there 
will never be a path like


a/myField/myProperty/value

but always just something like

a/data/events/items/value

The same applies for the definition of templates.
Is this correct ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


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