Re: access on items in a cluster

2019-10-30 Thread Diego Boscá
Hi Georg,

Seems like you want to validate paths vs the RM. This is doable but
probably is easier to use archetypes for that (as every valid archetype
path is also a valid rm path). Is there a reason for not using the
archetypes? I assume your AQL queries are based on some OPT your system
should be aware of.

Regards

El mié., 30 oct. 2019 a las 13:26, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> I would like to typecheck AQL queries and have some problems doing that:
> The items in a CLUSTER are of type ITEM. If I access
> myCluster/items[at0001]/value, is there any possibility to type-check
> the validity of this path without having the concrete archetype
> definition at hand? Just using the reference model isn't enough for this
> task, because ITEMs do not have a value-field.
> How can (from an object oriented point of view) the values of the ITEMs
> be accessed without knowing if it is an ELEMENT ?
> Why is there a distiguishment between ELEMENT, ITEM and CLUSTER at all ?
> If the fields "items" and "value" were already attached to the class
> ITEM it would be easier.
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: difference in expressability for archetype and template definitions

2019-10-12 Thread Diego Boscá
In ADL2 yes

El sáb., 12 oct. 2019 17:17, Georg Fette 
escribió:

> so, ADL2 is used to define both archetypes as well as templates ?
>
> --
> -
> 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


Re: difference in expressability for archetype and template definitions

2019-10-12 Thread Diego Boscá
Originally they were thought as two different artifacts to live in
different parts of the system. But as you point this is not the case.
That's why in ADL2 both archetypes and templates are describe by the sane
artifacts

In case of ADL1.4, templates que usually describe in OPT, which has
different expressability

El sáb., 12 oct. 2019 17:03, Georg Fette 
escribió:

> Hello,
> In what extends does the specification language for defining archetypes
> and the language for defining templates differ ?
> Both take existing data models (RM types and archetypes) and constrain
> them as needed.
> It is often said, that archetypes are used to recombine RM types and
> templates are used to recombine archetypes. But the slot mechanism
> within the archetype definition does as well allow archetypes
> recombination within archetypes. And the constraining that is done
> within templates could as well be done using the constraining mechanisms
> of archetype design.
> Why are two specification languages needed ? And if one has elements
> that the other is missing, why can't those elements simply be included
> in the other, to reduce the amount of specification languages ?
> 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


Re: information gain by "cardinality" ?

2019-10-11 Thread Diego Boscá
You can see cardinality as the size of the array that contains objects. For
your examples:

1) The summed max-"occurrences" may never surpass the max-"cardinality"
They might, specially as things like occurrences of 0..* or 1..* are a
thing. Nothing wrong with having a cardinality that further constraints
that.

2) the summed min-"occurrences" may never be less than the
min-"cardinality"
They also might, even if all your objects are optional (i.e. 0..1) you
could have a cardinality of [1..*] to say that you need at least one.

However, I would say that in normal cases you could just sum them and be
fine, but this duality allows for some cool tricks at validation time

Regards

El vie., 11 oct. 2019 a las 9:29, Georg Fette ()
escribió:

> Hello,
> Constrained Container RM-Types can define a "cardinality" for their
> list/array fields and the contained types can define "occurrences" for
> themselves inside the array.
> The summed max-"occurrences" may never surpass the max-"cardinality and
> the summed min-"occurrences" may never be less than the min-"cardinality".
> The min-max-"occurrences" could perhaps even be calculated from the
> "occurrences".
> What information gain does the "cardinality" provide ?
> Or what is the usecase where a given "cardinality" is needed, because
> the information is not already given by the all "occurrences" ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: data element type from the RM

2019-10-10 Thread Diego Boscá
I think short answer is that you need to be aware of the
templates/archetypes when executing the AQL. Each node in the archetype has
either an at code or a archetypeid in the archetype node id attribute,
that's how you link both.

El jue., 10 oct. 2019 a las 12:19, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> But if the class is contained within a template instance only within
> some technical background information and it is not part of the
> reference model, how can a query mechanism like AQL use this information
> during query execution ?
> How does an AQL query engine know that an archetype based on Composition
> is a Composition when this link is given in the RM-part of the
> serialized instance only within the archetype_id of the
> archetype_details ? From that it could deduced by using the background
> knowledge of the available archetype definitions that it is in fact a
> Composition. It would be easier if this would be directly included in
> the RM-part of a serialized Composition itself.
> Or is the class type something one would assume as part of the RM ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B009
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Rules in archetypes - what are the requirements?

2019-02-01 Thread Diego Boscá
I'm fine with this improvements, the only thing I feel that can be
troublesome for users is having data_bindings and computed values in a
completely different format/style


El vie., 1 feb. 2019 a las 13:01, Thomas Beale ()
escribió:

> For many years, there has been a little-used capability in ADL which
> enables basic expressions to be stated such as the following in the Apgar
> Observation archetype:
>
> *rules*
>
> *score_sum*:
> /data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude =
> /data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value +
> /data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value +
> /data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value +
> /data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value +
> /data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value
>
> where all those paths point to the various Apgar leaf data values, i.e.
> total, heart rate etc.
>
> This kind of statement is intended to assert that the total value = the
> sum of the 5 elements, as per the Apgar formula. However, it was never that
> clear that it is an assertion, not a value-setting formula, which might
> also be something we want.
>
> It's also not very readable, even if the paths were rendered with a tool,
> they are long and painful to read.
>
> Another kind of assertion was to for conditional mandation of some part of
> the data depending on some other data element (or more generally, an
> expression), e.g.
>
> *rules*
>
> /data[id2]/items[id21]/items[id15]/value[id50]/defining_code *matches
> *{[at19]} *implies exists */data[id2]/items[id21]/items[id20]
>
> Here the logical intention is to mandate that the data at the second path,
> which is about details of transfer (i.e. discharge to other care) if the
> value of the datum at the first path, which is 'type of separation' =
> at19|transfer|. Other examples are mandating data containing details of
> tobacco use if the value of the data item 'tobacco use' /= at44|non-user|.
>
> This also is not that easy to read, or clear in its intentions.
>
> More recently, as part of the development of a simple expression language
> that can be used across openEHR (archetypes, Task Planning, GDL etc), I
> proposed some key improvements to expressions in archetypes, namely:
>
>- symbolic names for paths, done by bindings
>- an explicit 'check' instruction to make the intention of assertion
>clearer
>- a defined() predicate to replace the use of 'exists'
>
> Examples of how these changes look are shown here in the working copy of
> the ADL2 spec
> <https://specifications.openehr.org/releases/AM/latest/ADL2.html#_rules_section>.
> In this form, the above Apgar example becomes:
>
> *rules*
> *check *$apgar_total_value = $apgar_heartrate_value + $
> apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value + $
> apgar_colour_value
>
> *data_bindings*
>
> content_bindings = <
> ["apgar_breathing_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">
> ["apgar_heartrate_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">
> ["apgar_muscle_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value">
> ["apgar_reflex_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value">
> ["apgar_colour_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value">
> ["apgar_total_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude">
> >
>
> And the smoking example is:
>
> *check *$is_smoker = *True **implies **defined *($smoking_details)
>
> Note that this does not address the possible requirement of being able to
> state a formula that *sets *a field, or defines a purely computed value
> at a path.
>
> We are still working on details of the expression language, variable
> binding idea and so on. I am interested in feedback on the approach shown
> in the spec, preferably provided here in the first instance.
>
> - thomas
> _______
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/0

Re: DV_PROPORTION vs DV_QUANTITY for %

2019-01-14 Thread Diego Boscá
As far as I understand in oxygen levels the denominator is not 100 but a
quantity, and that denominator may vary. I don't know how it is measured in
alcohol, but probably % of alcohol in blood assuming always the same
quantity to get the percentage?
I'm not really sure anyway :)

El lun., 14 ene. 2019 a las 13:15, Bakke, Silje Ljosland (<
silje.ljosland.ba...@nasjonalikt.no>) escribió:

> Anyone…? 
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Bakke, Silje Ljosland
> *Sent:* Tuesday, January 8, 2019 2:53 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* RE: DV_PROPORTION vs DV_QUANTITY for %
>
>
>
> I still don’t understand if we have a conclusion. And I don’t understand
> why proportion is the correct data type for O2 levels but not for alcohol
> levels.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Ian McNicoll
> *Sent:* Monday, January 7, 2019 7:13 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: DV_PROPORTION vs DV_QUANTITY for %
>
>
>
> Simple answer - loads of real data - pulse_oximetry and Oxygen levels will
> have been recorded hundreds of thousands if not millions of times in
> patient data - and Proportion *is* the correct datatype for O2 levels.
>
> 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 Mon, 7 Jan 2019 at 17:56, Thomas Beale 
> wrote:
>
> one thing to note: DV_PROPORTION is a more complex data structure. I
> would be tempted to try to determine what use has been made of this
> archetype so far - i.e. in creating real data. If no real data has been
> created, then it could in theory be changed.
>
> - thomas
>
> On 07/01/2019 12:11, Ian McNicoll wrote:
> > Hi Silje,
> >
> > As you say, I think this a case of emerging clarity (or less fog of
> > confusion!!) as the various use-cases emerge. As the primary author of
> > both these archetypes, in retrospect I would probably keep
> > inspired_oxygen as DV_PROPORTION and change pulse_oximetry to
> > DV_QUANTITY but!!! I do not see any good argument for changing these
> > now. We have to expect some degree of inconsistency, and live with it,
> > to avoid unnecessary breaking changes.
> >
>
>
> ___
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: DV_PROPORTION vs DV_QUANTITY for %

2019-01-03 Thread Diego Boscá
Also, take into account that if you use DV_PROPORTION to represent this
percent, you will always have this double quantity stored in your data,
which doesn't really add nothing of value and just will slow down your
queries.

Regards

El jue., 3 ene. 2019 10:30, Ian McNicoll  escribió:

> Hi Marcus,
>
> I think that is the intended use. It is the case that UCUM has a '%' unit
> as part of DV_QUANTITY which I think I have only ever used in the context
> of integrating a lab test where the 'proportionality' of the value is not
> really relevant i.e it is in some ways an arbitrary unit.
>
> 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 Thu, 3 Jan 2019 at 09:20, Marcus Baw  wrote:
>
>> As a relative OpenEHR outsider but a data modelling enthusiast, I would
>> agree with Silje that if this is known to be a proportion then using
>> DV_PROPORTION seems more intuitive, as this preserves the semantics of the
>> data. It also would allow confident conversion of that data into other
>> types of proportion (eg per-thousand or PPM)
>>
>> Marcus
>>
>> On Thu, 3 Jan 2019 at 08:57, Bakke, Silje Ljosland <
>> silje.ljosland.ba...@nasjonalikt.no> wrote:
>>
>>> I would have guessed it would be the other way around. If you know at
>>> design time that this value will be a percentage, use the DV_PROPORTION
>>> data type with the ‘type’ attribute set to 2 (percent, denominator fixed to
>>> 100). On the other hand if you don’t know for sure (such as for some lab
>>> results or medication strengths which could be for example mg/ml or %
>>> interchangeably), you would use DV_QUANTITY.
>>>
>>>
>>>
>>> Regards,
>>>
>>> *Silje*
>>>
>>>
>>>
>>> *From:* openEHR-clinical  *On
>>> Behalf Of *David Moner
>>> *Sent:* Thursday, January 3, 2019 9:37 AM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@lists.openehr.org>
>>> *Cc:* For openEHR clinical discussions (
>>> openehr-clini...@lists.openehr.org) 
>>> *Subject:* Re: DV_PROPORTION vs DV_QUANTITY for %
>>>
>>>
>>>
>>> I think DV_QUANTITY is the option here. Someone could argue that % is
>>> not a proper unit, but it is, both in UCUM and SNOMED CT.
>>>
>>>
>>>
>>> DV_PROPORTION should be only used when you want to maintain the
>>> numerator and denominator explicitly separated, as a fraction, which should
>>> not be the case with percentages. But it is true that the definition of the
>>> type attribute in the specification is a bit misleading: "Indicates
>>> semantic type of proportion, including percent, unitary etc."
>>>
>>>
>>>
>>> El jue., 3 ene. 2019 a las 7:59, Bakke, Silje Ljosland (<
>>> silje.ljosland.ba...@nasjonalikt.no>) escribió:
>>>
>>> Hi everyone, happy new year!
>>>
>>>
>>>
>>> We’ve just hit a question about modelling choices, how to represent
>>> percentages. We have a data type DV_PROPORTION, which can be used to
>>> represent any proportion such as a fraction or a percentage, and we have
>>> the DV_QUANTITY data type which can have % as the unit. In most existing
>>> archetypes such as the OBSERVATION.pulse_oximetry archetype, we’ve used the
>>> DV_PROPORTION data type for the percent elements, while for some reason in
>>> the draft EVALUATION.alcohol_consumption_summary archetype we’ve chosen
>>> DV_QUANTITY with the unit ‘%’ for the “Strength” element.
>>>
>>>
>>>
>>> We’ve had a look at the data types documentation (
>>> https://specifications.openehr.org/releases/RM/latest/data_types.html),
>>> and we can’t really find any guidance in the examples there. Is there any
>>> guidance about this anywhere else? Does anyone have any opinions about when
>>> to use each data type for percentages?
>>>
>>>
>>>
>>> Kind regards,
>>> *Silje Ljosland Bakke*
>>>
>>>
>>>
>>> Information Architect, RN
>>>
>>> Coordinator, National Editorial Board for Archetypes
>>> Nasjonal IKT HF, Norway
>>>
>>> Tel. +47 40203298
>>>
>>> Web: http://arketyper.no / Twitter: @arketyper_no
>>> 
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>>
>>>
>>> --
>>>
>>> David Moner Cano
>>>
>>> Web: http://www.linkedin.com/in/davidmoner
>>>
>>> Twitter: @davidmoner
>>>
>>> Skype: davidmoner
>>> ___
>>> openEHR-clinical mailing list
>>> openehr-clini...@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>>
>> 

Re: openEHR on FHIR and vice versa

2018-12-18 Thread Diego Boscá
Transformation programs generated with LinkEHR are pure XQuery, and you are
the one who decides the license of that output program. So nothing stops
you in that regard. XQuery can output json too btw

Regards

El mar., 18 dic. 2018 a las 23:04, Heath Frankel (<
heath.fran...@oceanhealthsystems.com>) escribió:

> Although I will add, and I think someone has already suggested this, at
> least we only have to do this mapping once for each FHIR resource. So as a
> openEHR/FHIR community we should aim for a set of templates, as Thomas
> indicated, a set of FHIR extensions, and a library of mappings and
> transforms.
> Sounds like LinkEHR has some capacity to do the mappings but from a
> community asset perspective we need a Implementation independent technology
> for the transform. Back in my day of doing HL7 v2 or CDA mappings, this was
> done using XSLT. I think someone mentioned a JSON equivalent? I still think
> XSLT would be a good common denominator although perhaps seen as ancient.
>
> Regards
>
> Heath
> --
> *From:* Heath Frankel
> *Sent:* Wednesday, December 19, 2018 8:23:31 AM
> *To:* For openEHR technical discussions
> *Subject:* Re: openEHR on FHIR and vice versa
>
> Thanks Pablo,
> I second that.
>
> Regards
>
> Heath
> _
> From: Pablo Pazos 
> Sent: Wednesday, December 19, 2018 3:36 am
> Subject: Re: openEHR on FHIR and vice versa
> To: For openEHR technical discussions  >
>
>
> Yes, in fact the closest we can get to automatic transformations is just
> defining the mappings between openEHR classes and the correspondent FHIR
> resources, and feed that to a system that, for a specific openEHR instance,
> provides a mapper user with constrained options of FHIR resources to choose
> from, and vice-versa, given a FHIR resource, provide the options of openEHR
> classes to map to. Then will end up mapping fields of correspondent types.
> No magic here for now :(
>
> But I believe this process can be more intelligent, if we add extra
> metadata to the definitions (like SNOMED CT annotations with concept ids
> and expressions), and we have a lot of instance samples where AI algorithms
> can run on and detect semantic matches. Still, a human needs to do some
> manual work, but maybe less with the extra help of metadata+AI.
>
> Thinking of 100% automatic generic transformations between any instance of
> two different information models is currently just science fiction IMHO :),
> or for a political correct answer: it is an open problem.
>
> On Tue, Dec 18, 2018 at 7:58 AM Ian McNicoll  wrote:
>
>> I agree Pablo and we have to remember that the number of high-quality,
>> truly interoperable FHIR profiles is going to be very small for a long
>> time.
>>
>> @Dileep V S  - we have started to put FHIR
>> bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will
>> between local FHIR profiles
>>  and local templates - see
>> https://github.com/inidus/openehr-care-connect-adaptor
>>
>> There are various attempts at automation including the Ripple QEWD Jumper
>> work https://www.youtube.com/watch?v=iaGGGgJdWvM but it will still need
>> quite a lot of manual input.
>>
>> 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 Mon, 17 Dec 2018 at 18:26, Pablo Pazos 
>> wrote:
>>
>>> I also did some mapping work FHIR -> openEHR using Mirth, but this is
>>> ad-hoc, no automatic mapping yet, for that you need to define a lot of
>>> constraints to make it work automatically. Maybe some semi-automatic tool
>>> come out in the future, assisting architects on doing such mappings, either
>>> way some kind of human intervention will be needed to define mapping
>>> criteria when there are  1 to * mapping possibilities.
>>>
>>> On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden <
>>> jan-m...@medrecord.io> wrote:
>>>
>>>> We are doing something similar at the moment. but instead of doing this
>>>> inside the archetype we are considering the use of an external mapping tool
>>>> like Mirth Connect or OpenHIM. But we are not there yet.. :-)
>>>>
>>>> Jan-Marc Verlinden
>>>> www.medrecord.io
>>>> www.medsafe.io
>>

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá
I think this patient profile works with the version on the website

https://send.firefox.com/download/5a8149637d/#iBDOPKD9ZcMkgBXpLbtXPw

El vie., 14 dic. 2018 a las 12:54, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> I just tried to import with the LinkEHR studio via the Import->FHIR
> option this StructureDefinition :
>
>
> {"resourceType":"StructureDefinition","id":"Test","name":"Test","type":"Test","baseDefinition":"
> http://hl7.org/fhir/StructureDefinition/DomainResource
> ","snapshot":{"element":[{"id":"Test","path":"Test","min":0,"max":"*"}]}}
>
> A dialog appeared, in which I could configure some import details. But
> after that nothing happed. Is there an example available, which shows
> what the FHIR import in LinkEHR is capable of ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá
I was thinking in a openEHR -> FHIR bundle, similar to what they already do
with CDA

El vie., 14 dic. 2018 a las 12:40, GF () escribió:

> The requiremetns for OpenEHR are NOT the same as those for FHIR or CIMI.
> Therefor a complete generic mapping is impossible.
> Always it will be an ad-hoc, bespoke, one.
>
> The choices FHIR made for its Resources differ from those of OpenEHR and
> CIMI archetypes.
> They do NOT share the same Reference Model.
>
> Gerard   Freriks
> +31 620 34 70 88
> ‭+31 182 22 59 46‬
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 14 Dec 2018, at 11:48, Diego Boscá  wrote:
>
> Hello Georg,
>
> The main result of that paper was supporting FHIR as a reference model to
> define archetypes (you can do that with no limitations on the currently
> available tool). There is no openEHR archetype <-> FHIR profile service
> yet, although I believe that providing a openEHR -> FHIR generical
> transformation could be feasible.
> Most of the results of this work are available as import/export functions
> in LinkEHR: Importing StructureDefinitions should work for most things (in
> fact, I have been updating this part recently and will have better support
> for STU3 in next LinkEHR version we publish). The export feature is in the
> original DSTU format though, I assume we should go further and generate
> StructureDefinitions as in STU3. For the transformation of data instances,
> as I said we use archetypes as way to express FHIR profiles and resources,
> so transforming between them is no more difficult than transforming between
> openEHR, CDA, ISO13606, ODM, etc. which you can do with the LinkEHR studio
> (FYI, the LinkEHR Studio version available on the website allows you to
> test this mapping/transformation part, the only thing you won't be able to
> do is to export the output XQuery transformation)
>
> Regards
>
> El vie., 14 dic. 2018 a las 11:19, Georg Fette (<
> georg.fe...@uni-wuerzburg.de>) escribió:
>
>> Hello,
>> I have just read the paper "Combining Archetypes with Fast Health
>> Interoperability Resources in Future-proof Health Information Systems",
>> in which the representation of openEHR archetypes as FHIR profiles is
>> presented. As I am also trying to use this approach and I wonder if
>> there are working and publicly available applications (possibly emerged
>> from the above mentioned research) that use that approach ? I am
>> especially interested in:
>> - transforming openEHR archetypes into FHIR profiles
>> (StructureDefinitions) and storing them in a FHIR server.
>> - transforming FHIR profiles into openEHR archetypes and storing them in
>> an openEHR server.
>> - transforming openEHR archetype instances into FHIR resources (Bundles)
>> and storing them in a FHIR server.
>> - transforming FHIR resources into openEHR instances and storing them in
>> an openEHR server.
>> 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
>>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
>

Re: openEHR on FHIR and vice versa

2018-12-14 Thread Diego Boscá
Hello Georg,

The main result of that paper was supporting FHIR as a reference model to
define archetypes (you can do that with no limitations on the currently
available tool). There is no openEHR archetype <-> FHIR profile service
yet, although I believe that providing a openEHR -> FHIR generical
transformation could be feasible.
Most of the results of this work are available as import/export functions
in LinkEHR: Importing StructureDefinitions should work for most things (in
fact, I have been updating this part recently and will have better support
for STU3 in next LinkEHR version we publish). The export feature is in the
original DSTU format though, I assume we should go further and generate
StructureDefinitions as in STU3. For the transformation of data instances,
as I said we use archetypes as way to express FHIR profiles and resources,
so transforming between them is no more difficult than transforming between
openEHR, CDA, ISO13606, ODM, etc. which you can do with the LinkEHR studio
(FYI, the LinkEHR Studio version available on the website allows you to
test this mapping/transformation part, the only thing you won't be able to
do is to export the output XQuery transformation)

Regards

El vie., 14 dic. 2018 a las 11:19, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> I have just read the paper "Combining Archetypes with Fast Health
> Interoperability Resources in Future-proof Health Information Systems",
> in which the representation of openEHR archetypes as FHIR profiles is
> presented. As I am also trying to use this approach and I wonder if
> there are working and publicly available applications (possibly emerged
> from the above mentioned research) that use that approach ? I am
> especially interested in:
> - transforming openEHR archetypes into FHIR profiles
> (StructureDefinitions) and storing them in a FHIR server.
> - transforming FHIR profiles into openEHR archetypes and storing them in
> an openEHR server.
> - transforming openEHR archetype instances into FHIR resources (Bundles)
> and storing them in a FHIR server.
> - transforming FHIR resources into openEHR instances and storing them in
> an openEHR server.
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Use of LinkEHR to create OPTs like we do with Template designer

2018-12-13 Thread Diego Boscá
Hi,

Latest available version on the website (2018-08-27) should have that
option available


Regards

El jue., 13 dic. 2018 a las 11:30, Dileep V S ()
escribió:

> File->new template does not seem to exist. However I could import OPT
> files. However I am still enable to insert another archetype into a slot.
> The options allow me to only create archetypes and archetype slots and not
> insert and existing archetype.
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
>
> On Thu, Dec 13, 2018 at 2:31 PM Diego Boscá  wrote:
>
>> Hi Dileep,
>>
>> You can create new templates based on archetypes (File->new template), or
>> import your OPT. I recommend that you configure the local repository to
>> access the directory, similar to how TD works
>>
>> Regards
>>
>> El jue., 13 dic. 2018 a las 9:52, Dileep V S ()
>> escribió:
>>
>>> HI,
>>>
>>> I have been using Archetype editor and Template designer so far and am
>>> experimenting with LinkEHR studio. I have managed to import, visualize and
>>> edit OpenEHR archetypes(1.4).
>>>
>>> However I am not able to understand how to combine archetypes into a
>>> template (like we do in Template designer) and export OPTs.I am importing
>>> these OPTs into an EtherCIS server. Is this possible? if yes can somebody
>>> point to the documentation for this(the documentation from LinkEGR only
>>> talks about Archetypes)
>>>
>>> regards
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo..

Re: Use of LinkEHR to create OPTs like we do with Template designer

2018-12-13 Thread Diego Boscá
Hi Dileep,

You can create new templates based on archetypes (File->new template), or
import your OPT. I recommend that you configure the local repository to
access the directory, similar to how TD works

Regards

El jue., 13 dic. 2018 a las 9:52, Dileep V S ()
escribió:

> HI,
>
> I have been using Archetype editor and Template designer so far and am
> experimenting with LinkEHR studio. I have managed to import, visualize and
> edit OpenEHR archetypes(1.4).
>
> However I am not able to understand how to combine archetypes into a
> template (like we do in Template designer) and export OPTs.I am importing
> these OPTs into an EtherCIS server. Is this possible? if yes can somebody
> point to the documentation for this(the documentation from LinkEGR only
> talks about Archetypes)
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
We plan in using Archie library when we migrate our tools for ADL2 :)

El mié., 12 dic. 2018 15:24, Thomas Beale 
escribió:

> You can always check conformance with the ADL Workbench, it will consume
> ADL1.4 and ADL2. And Archie now produces the same regression results as
> ADL WB, so it could be used as well, and in future, will probably become
> the main reference tool.
>
> - thomas
>
>
>
> ___
> 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: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
When I say official I refer to AOM. If AOM/ADL let's you say something we
try to support it. We always 'eat' what others tools produce, and have
implemented export mechanisms to be compatible with the things other tools
can handle. In this particular case you mentioned, an exported archetype
from LinkEHR can be opened in any other archetype editor directly. We also
gave support for OPT & OET import/export, and even OPTs generated this way
are virtually identical to the ones coming from the template designer.

So yes, we have tweaked the parser to support more things, but the
archetype creation is completely RM driven (archetypes created with LinkEHR
are always compliant with the RM you choose). That created archetype can be
then saved to different representations depending of your needs (ADL for
specific tools, XML, etc).

Regards

El mié., 12 dic. 2018 15:09, Bert Verhees  escribió:

> On 12-12-18 14:49, Diego Boscá wrote:
> > These are modifications on the parser, which parses more things than
> > your standard parser. In fact, the editor supports legal things in ADL
> > that other parsers don't (e.g. explicit node identifiers or
> > existence). The generated ADL is completely fine ADL. There are tools
> > that don't comply with this general ADL, and we provided an export
> > version of archetypes that produces a modified version of the ADL
> > syntax that other older and not maintained tools can parse.
> > If you want to call this subset "official archetypes" be my guest.
>
> The word "official" was used by you, I used it (in quotes) to indicate
> that we refer to the same.
>
> But it may get confusing, also because in the past there were
> discussions about LinkEhr and the Ocean archetype-editor which had
> different interpretations of the prevailing definitions. They did not
> always eat each others archetypes.
>
> I think at this point it is important to state in a simple way, then
> there will be no reason for doubt about intentions:
>
> Does the LinkEhr editor produce archetypes which are always intended to
> be completely conforming the official ADL/AOM and RM definitions?
>
> Best regards
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

El mié., 12 dic. 2018 15:09, Bert Verhees  escribió:

> On 12-12-18 14:49, Diego Boscá wrote:
> > These are modifications on the parser, which parses more things than
> > your standard parser. In fact, the editor supports legal things in ADL
> > that other parsers don't (e.g. explicit node identifiers or
> > existence). The generated ADL is completely fine ADL. There are tools
> > that don't comply with this general ADL, and we provided an export
> > version of archetypes that produces a modified version of the ADL
> > syntax that other older and not maintained tools can parse.
> > If you want to call this subset "official archetypes" be my guest.
>
> The word "official" was used by you, I used it (in quotes) to indicate
> that we refer to the same.
>
> But it may get confusing, also because in the past there were
> discussions about LinkEhr and the Ocean archetype-editor which had
> different interpretations of the prevailing definitions. They did not
> always eat each others archetypes.
>
> I think at this point it is important to state in a simple way, then
> there will be no reason for doubt about intentions:
>
> Does the LinkEhr editor produce archetypes which are always intended to
> be completely conforming the official ADL/AOM and RM definitions?
>
> Best regards
>
> Bert
>
>
>
> ___
> 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: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
These are modifications on the parser, which parses more things than your
standard parser. In fact, the editor supports legal things in ADL that
other parsers don't (e.g. explicit node identifiers or existence). The
generated ADL is completely fine ADL. There are tools that don't comply
with this general ADL, and we provided an export version of archetypes that
produces a modified version of the ADL syntax that other older and not
maintained tools can parse.
If you want to call this subset "official archetypes" be my guest.


El mié., 12 dic. 2018 a las 14:28, Bert Verhees ()
escribió:

> On 12-12-18 13:48, Diego Boscá wrote:
> > The official one, these are 'hacks' that allow you to handle
> > requirements and edge cases only present in these RM archetypes
>
> Diego, I don't want to be harsh about LinkEhr, which is a very strong
> product. But this situation raises questions. I already had this
> discussion a few times.
>
> Especially because it is not mentioned on the LinkEhr website that it
> does not support the official OpenEhr out of the box.
>
> You should have an option in the application for creating "official"
> archetypes, this to avoid confusion.
>
> I think it is very good that you fix issues you experience, but this
> way, by implementing without explicit notifying does not seem the royal
> way.
>
> It is bad, because in this way, the OpenEhr-software-ecosystem-base may
> become too narrow, and it is easy to fix by you, as you indicate to
> Georg Fette
>
> Best regards
>
> Bert
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
I don't think they are currently generated, but you can generate them if
you reimport the model and select them

El mié., 12 dic. 2018 a las 13:44, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> In the LinkEHR files the archetypes for the "EHR Infomation Model" are
> contained (ACTION, CLUSTER, etc.). Are there also somewhere archetypes
> that describe the "Data Types Information Model" (e.g. DV_QUANTITY,
> DV_MEDIA, etc.).
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
The official one, these are 'hacks' that allow you to handle requirements
and edge cases only present in these RM archetypes

El mié., 12 dic. 2018 a las 13:41, Bert Verhees ()
escribió:

> On 12-12-18 12:53, Diego Boscá wrote:
> > We used that one as a basis and generalized mostly to allow the
> > special RM 'at' codes we created. I can send you the modified grammar
> > or the parser if you want.
>
> Wouldn't that disturb interoperability processes? One could wonder:
> Which one is the right grammar, which one is the right parser?
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
When importing the schema you can chose which are your business entities
for a given RM. If you need that archetype you can reimport the model any
time you want from the schemas and select more classes as archetypable.

El mié., 12 dic. 2018 a las 13:36, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> In the Archetypes contained in the LinkEHR files I am missing the
> subclasses that are subclassed by the root archetypes. In ACTION for
> example the subclass INSTRUCTION_DETAILS is used. This is used in the
> ACTION.adl file and it is parseable but I wonder if there is an
> INSTRUCTION_DETAILS.adl file somewhere, which possibly defines something
> that is not yet defined in the ACTION.adl file. Or can be assumed that
> the subclasses wherever they are mentioned are fully desribed at the
> places where they are introduced ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
Grammar (and parser classes) are derived from the original one available in
the repo, so the same license applies.
These are edge cases we detected the original parser didn't treat well
(recursive internal references) and were also fixed.

El mié., 12 dic. 2018 a las 13:19, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> Yes, if you have a working parser for those archetypes that would be
> useful. The modified grammer would also be useful.
> What are the copyright constraints on your parser and your grammmer file ?
> I managed to get one of the archetypes parsed by lowercasing the
> language codes and removing all elements that include a recursive
> use_node statement.
> Is the inability to parse use_nodes that reference a node upwards in the
> same branch of the element a bug in version 1.0.71 ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
We used that one as a basis and generalized mostly to allow the special RM
'at' codes we created. I can send you the modified grammar or the parser if
you want.

El mié., 12 dic. 2018 a las 12:46, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> I just tried to parse the .adl files from LinkEHR and got several
> Exceptions. I currently use the adl-parser from
> org.openehr.java-libs_v_1.0.71.
> Which parser can I use to parse those archetypes ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-12 Thread Diego Boscá
They are generated from different "root" XML Schemas (demographics and
ehr), but in principle the contents should be the same. Models are
generated in a standalone way, so no assumptions are made regarding if ehr
model shares classes with demographic one (or any other model already
imported). As they are archetypes from these classes on the demographic
archetypes of CKM, the classes were selected as archetypable in the RM
import process, and thus generated. They should virtually equivalent (apart
from changes in the archetype identifier).



El mié., 12 dic. 2018 a las 12:21, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> Thank you, that is exactly what I was looking for.
> In the DEMOGRAPHICS and the EHR package there are 6 archetypes which
> have the same name but differ only in their full path name: CLUSTER,
> ELEMENT, ITEM_LIST, ITEM_SINGLE, ITEM_TABLE and ITEM_TREE. Why are they
> two versions of those archetypes with almost identical content ?
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-11 Thread Diego Boscá
But in this case the archetype you create couldn't be use for validation
purposes. I think I'm not fully understanding what you mean with this

El mar., 11 dic. 2018 a las 12:37, Thomas Beale ()
escribió:

> I think this is more or less the same as a kind of archetype with no codes
> at all, only containing RM elements.
>
> I was expecting something more like:
> CLASS [Observation_code] matches {
> attributes matches {
> ATTRIBUTE [Observation_data_code] matches {
> name matches {"data"}
> ...
> }
> ATTRIBUTE [Observation_state_code] matches {
> name matches {"state"}
> ...
> }
> }
> }
>
> or you could do it with C_OBJECT and C_ATTRIBUTE, which is a workable
> meta-model.
>
> - thomas
> On 11/12/2018 10:58, Diego Boscá wrote:
>
> As an example, this is the Observation archetype
>
> https://pastebin.com/WhehexLR
>
> El mar., 11 dic. 2018 a las 11:53, Diego Boscá ()
> escribió:
>
>> It is basically AOM, serialized as ADL files
>>
>> El mar., 11 dic. 2018 a las 11:51, Thomas Beale (<
>> thomas.be...@openehr.org>) escribió:
>>
>>> Diego,
>>>
>>> what do you use as the underlying information model in that case?
>>> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>>>
>>> - thomas
>>>
>>> On 11/12/2018 09:40, Diego Boscá wrote:
>>> > Hi Georg,
>>> >
>>> > That's exactly how we define reference models with LinkEHR. We
>>> > generated them from the XSD schemas (and more recently, from BMM). It
>>> > fits quite nicely with the archetype methodology (every archetype is
>>> > an specialization, which eases validation).
>>> > If you want to try or test them you can download LinkEHR and get them
>>> > from there.
>>> >
>>> > Regards
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> des

Re: Reference Model as Archetypes ?

2018-12-11 Thread Diego Boscá
As an example, this is the Observation archetype

https://pastebin.com/WhehexLR

El mar., 11 dic. 2018 a las 11:53, Diego Boscá ()
escribió:

> It is basically AOM, serialized as ADL files
>
> El mar., 11 dic. 2018 a las 11:51, Thomas Beale ()
> escribió:
>
>> Diego,
>>
>> what do you use as the underlying information model in that case?
>> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>>
>> - thomas
>>
>> On 11/12/2018 09:40, Diego Boscá wrote:
>> > Hi Georg,
>> >
>> > That's exactly how we define reference models with LinkEHR. We
>> > generated them from the XSD schemas (and more recently, from BMM). It
>> > fits quite nicely with the archetype methodology (every archetype is
>> > an specialization, which eases validation).
>> > If you want to try or test them you can download LinkEHR and get them
>> > from there.
>> >
>> > Regards
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o ha recibido
> esta comunicación por error, le informamos que está totalmente prohibida, y
> puede ser ilegal, cualquier divulgación, distribución o reproducción de
> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-11 Thread Diego Boscá
It is basically AOM, serialized as ADL files

El mar., 11 dic. 2018 a las 11:51, Thomas Beale ()
escribió:

> Diego,
>
> what do you use as the underlying information model in that case?
> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>
> - thomas
>
> On 11/12/2018 09:40, Diego Boscá wrote:
> > Hi Georg,
> >
> > That's exactly how we define reference models with LinkEHR. We
> > generated them from the XSD schemas (and more recently, from BMM). It
> > fits quite nicely with the archetype methodology (every archetype is
> > an specialization, which eases validation).
> > If you want to try or test them you can download LinkEHR and get them
> > from there.
> >
> > Regards
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Reference Model as Archetypes ?

2018-12-11 Thread Diego Boscá
Hi Georg,

That's exactly how we define reference models with LinkEHR. We generated
them from the XSD schemas (and more recently, from BMM). It fits quite
nicely with the archetype methodology (every archetype is an
specialization, which eases validation).
If you want to try or test them you can download LinkEHR and get them from
there.

Regards

El mar., 11 dic. 2018 a las 10:20, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> Is there somewere a machine readable definition available which
> describes the content of the openEHR Reference Model as Archetypes ?
> The Reference Model classes should be expressable as Archetypes,
> shouldn't they ? At least concerning their logical data model. The
> methods they also possibly provide can hardly be expressed using
> Archetypes.
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: ADL specification question

2018-11-29 Thread Diego Boscá
As Pieter said, default occurrences (if not stated) are 0..*
So if the attribute is ordered, this means that if the object appears, it
has to be in that specific order, in your case at0002, at0002...at0003,
at0003
Cardinality tells you how many of these are valid, so minimum 2.
Take into account that occurrences of 0..* means that a given object may
not appear, so in this case at0002, at0002 or at0003, at0003 are both valid

Regards

El jue., 29 nov. 2018 11:09, Georg Fette 
escribió:

> --
>
> Hi Diego,
> The items inside the CLUSTER look like this:
>
> CLUSTER[at0001] matches {
>   items cardinality matches {2..*; ordered} matches {
> ELEMENT[at0002] matches {
>   value matches {
> DV_COUNT matches {*}
>   }
> }
> ELEMENT[at0003] matches {
>   value matches {
> DV_TEXT matches {*}
>   }
> }
>   }
> }
>
> It could be that I not yet fully understand ADL, therefore I would need to 
> verify/falsify some assumptions I make:
>
> - Both elements (at0002, at0003) have an implicit cardinality of "1..1" ?
> - The keyword "ordered" just indicates that the items inside an instance of 
> the cluster at0001 have to maintain the order in which they were defined. The 
> order does not affect an enforced order of the types of the elements inside 
> the cluster ?
> - What is true?:
>   * The cluster at0001 may include the elements at0002 and at0003 in any 
> order an unlimited amounts of them as long as the cluster includes at least 2 
> of them. The specification inside of at0001 just gives the set of possible 
> elements that may appear as items of at0001. E.g. "at0003, at0003, at0002, 
> at0003, ..."
>   * The cluster at0001 has to include at least 2 elements in the order 
> given in the at0001 definition and the order may be repeat an unlimited 
> amount of times, e.g. "at0002, at0003, at0002, at0003, ..."
>
> Greetings
> Georg
>
> >Hello Georg,
> >
> >What (and how many) objects you have inside the items attribute?
> >Think the cardinality as the "vector" capacity, and inside you can put them
> >in order (depending on their occurrences, they may even not appear at all)
> >
> >Regards
> >
> >El jue., 29 nov. 2018 10:31, Georg Fette  >>
>
> >escribió:
>
>
> Am 29.11.2018 um 10:30 schrieb Georg Fette:
>
> Hello,
> I have an archetype with a complex object derived of CLUSTER with
> "items cardinality matches {2..*; ordered}"
> and those two items are also defined inside the complex object.
> I understand the semantics of this definition that both items always have
> to appear together inside the cluster but the package of those two items
> may appear any number of times.
> Is it allowed for instances of this archetype to have an uneven number of
> items > 2 inside this cluster, because that would still suffice the
> restriction of having 2..* children. Or do the instances always have to
> have both elements as a package that are defined as items in this cluster.
> As I am not the author of the archetype I do not completely understand how
> the definition has to be interpreted.
> 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


Re: ADL specification question

2018-11-29 Thread Diego Boscá
Hello Georg,

What (and how many) objects you have inside the items attribute?
Think the cardinality as the "vector" capacity, and inside you can put them
in order (depending on their occurrences, they may even not appear at all)

Regards

El jue., 29 nov. 2018 10:31, Georg Fette 
escribió:

> Hello,
> I have an archetype with a complex object derived of CLUSTER with
> "items cardinality matches {2..*; ordered}"
> and those two items are also defined inside the complex object.
> I understand the semantics of this definition that both items always
> have to appear together inside the cluster but the package of those two
> items may appear any number of times.
> Is it allowed for instances of this archetype to have an uneven number
> of items > 2 inside this cluster, because that would still suffice the
> restriction of having 2..* children. Or do the instances always have to
> have both elements as a package that are defined as items in this cluster.
> As I am not the author of the archetype I do not completely understand
> how the definition has to be interpreted.
> 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


Re: Parsing of Archetypes/Templates

2018-11-12 Thread Diego Boscá
Hello Georg,

Archie is meant to be used with ADL2 archetypes, if you want to parse 1.4
archetypes I think java implementation you mentioned before is your current
best option.

Regards

El lun., 12 nov. 2018 a las 13:40, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Peter,
> The Archie-Toolkit looks promising.
>
> I tried to parse one of the archetypes from the CKM (BloodPressure) and
> tried to parse the exported ADL. However, I got a Exception when trying
> this because the exported ADL does not seem to be parseable:
> line 1:24 mismatched input '1.4' expecting VERSION_ID
> line 2:1 mismatched input 'openEHR-EHR-OBSERVATION.blood_pressure.v1'
> expecting ARCHETYPE_HRID
>
> With the exported XML and the try to unmarshal the XML with the JAXBUtil
> I also did not succeed. Is there somewhere a testcase were I can see a
> working example of a parsed ADL String ?
>
> Greetings
> Georg
>
> Hello George,
>
> If you are looking for something to handle ADL 2 archetypes - the most
> recent version -, have a look at https://github.com/opener/archie . It
> is a java library that can parse archetypes, flatten and validate  them,
> create operational templates and more.
>
> Are you using the openehr reference model, or something else like fihr?
>
> Although Archie can parse and serialize archetypes in XML, archetypes
> are usually stored as ADL. This is a custom more readable format. Of
> course you can then easily convert it to XML or Json to work with them
> in other tools where you do not have an ADL parser ready.
>
> Note that for ADL 2 as far as I know there is no official XSD released
> yet, so it is possible you run into compatibility problems with XML. For
> ADL 1.4 this is not a problem.
>
> Regards,
>
> Pieter Bos
>
> Am 12.11.2018 um 09:18 schrieb Georg Fette:
> > Hello,
> > For a project we want to create a generic mechanism to transform
> > archetypes into FHIR Logical Models, so we can store, retrieve and
> > query archetype instance with FHIR tools (CQL, FHIR-REST-API-query).
> > At the moment we just want to read/write archetypes and not archetype
> > instances. We are looking for existing components to parse and process
> > archetypes. I have some questions I encountered related to these issues:
> > - I have found several projects that store openEHR-data (archetypes as
> > well as archetype instances) into different data substrates (Neo4J,
> > ARM (archetype relational mapping), EtherCIS). Although I have not yet
> > looked at the code of these projects I assume that they take an
> > archetype XML-file, parse it and thus create a runtime object of the
> > archetype. That runtime object can then be given as a parameter to a
> > persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
> > something from already existing projects I am looking for a parser
> > that creates a runtime object from an archetype-XML-String, so we can
> > write our own components that transform it into a FHIR runtime object.
> > The component we are looking for should preferably be written in Java,
> > as this is our language of choice in our project.
> > - I am not ye sure if we are looking for a method to transform
> > archetypes, templates or operational templates into FHIR related
> > structures, as I am not yet that familiar with which data structure is
> > preferably used for which kind of task. Therefore, component that,
> > instead of archetypes, parse templates or operational templates would
> > be appreciated as well.
> > 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada

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

2018-10-23 Thread 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: Unique paths for slots problem if slots are filled with same archetype

2018-10-19 Thread Diego Boscá
Discussing this with David we have another solution to this problem: one
thing you could do and would completely work without breaking anything is
to specify some kind of empty specializations of the include archetype, and
giving as the name of the specialization the node_id code. something like
this

[openEHR-EHR-INSTRUCTION.service_request-at.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information-at0141.v1]

This won't break current systems and will probably solve the original
problem

Regards

El vie., 19 oct. 2018 a las 13:10, Ian McNicoll ()
escribió:

> Hi Sebastian,
>
> This is 'known issue' but not one that we had really thought too carefully
> about. We 'solve' it right now by renaming the slotted in archetype root
> node at template level but others have already pointed out that this is
> less than ideal.
>
> Adding an intermediate cluster would solve things but feels clunky.
>
> I understand Thomas had some ideas about this re ADL2 but I like the ideas
> from Heath / Diego also.
>
> It is probably less of a practical issue than might seem the case as we
> tend not to have too many situations where the meaning needs to 'inherit'
> from the Slot name, and where those adjacent slot names differ for
> identical slot fills but agree it needs fixed.
>
> Ian
>
>
> @Diego - thanks for that input
> 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 Fri, 19 Oct 2018 at 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]
>>
>> Regards
>>
>> El vie., 19 oct. 2018 a las 10:57, Sebastian Garde (<
>> sebastian.ga...@oceaninformatics.com>) escribió:
>>
>>> Hi all,
>>>
>>>
>>>
>>> We have encountered an interesting issue with how to construct unique
>>> paths for slots when there is more than one slot on the same level, and
>>> both slots are filled with the same archetype.
>>>
>>> In this case, the resulting paths for both seem to be the same in OPT
>>> and thus in the data. (The at/id code of the slot are not part of the path
>>> for a filled slot.)
>>>
>>> Likewise, you cannot apply an annotation to only one of them, because
>>> they share the same path.
>>>
>>>
>>>
>>> This seems to be a general problem, but let me explain it in more detail
>>> using a concrete example:
>>>
>>> The problem manifests itself for example when you start using the
>>> Service Request Archetype in CKM (
>>> https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).
>>>
>>>
>>>
>>> In the archetype’s protocol (see screenshot below), there are various
>>> slots, most importantly let’s look at the *Requester* and the *Receiver*
>>> Slot.
>>>
>>> In a template (see 2nd screenshot), both slots can be filled with the
>>> same archetype, technically, and it also seems reasonable from a content
>>> point of view to use the same archetype for both slots.
>>>
>>>
>>>
>>> The problem is that this means that the paths are no longer unique –
>>> there is no way to differentiate between the Requester and Receiver
>>> information anymore as far as we can see in the OPT, and consequently in
>>> the data.
>>>
>>> Also

Re: DV_DURATION and magnitude_status?

2018-09-25 Thread Diego Boscá
After rereading what Silje needed, I think the mentioned attribute would do
the trick for her

However seems like we at SEC have work to do :)

El lun., 24 sept. 2018 a las 23:36, Pablo Pazos ()
escribió:

>
>
> On Mon, Sep 24, 2018 at 4:26 PM Thomas Beale 
> wrote:
>
>>
>>
>> On 24/09/2018 16:19, Pablo Pazos wrote:
>> > I think there was a conversation about being able to constraint the
>> > magnitude of a DV_DURATION instead of the String expression. The issue
>> > was the magnitude is a function, not an attribute of DV_DURATION.
>>
>> that is also my understanding...
>>
>
> I'm not sure if that was just a conversation or if we have a proposal from
> the SEC to make changes on that area, do you recall?
>
>
>>
>> ___
>> 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://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá
But the meaning is for this attribute is to be be used in measures like lab
result to express things that are probably barely measurable, not to
express that in modelling time the other defined constraint is meant to be
the upper (or lower) part of a range

El lun., 24 sept. 2018 a las 20:49, Ian McNicoll ()
escribió:

> Hi Diego,
>
> We have certainly had to use it in some lab test integrations. I would
> normally agree that it might be risky to carry this kind of modifier as a
> separate attribute, which could easily be missed in queries, but these are
> gnerally  imprecise values (as in Silje's use-case) or out-of-range on an
> analyser where I think the non-modified value is robably a safe proxy for
> the modified one. So, in this case I think it is safe.
>
> 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 Mon, 24 Sep 2018 at 19:30, Diego Boscá  wrote:
>
>> yeah, I can see to be useful for that, but seems weird to constraint it
>> in any way
>>
>> El lun., 24 sept. 2018 a las 20:29, Thomas Beale (<
>> thomas.be...@openehr.org>) escribió:
>>
>>> It was added to the RM years ago to support quantities in lab results,
>>> which are sometimes of the form Y etc. If I had my time again, I
>>> would have moved the date/time types out a bit so they did not inherit
>>> this attribute. Usually it is Void.
>>>
>>> - thomas
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
d

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá
yeah, I can see to be useful for that, but seems weird to constraint it in
any way

El lun., 24 sept. 2018 a las 20:29, Thomas Beale ()
escribió:

> It was added to the RM years ago to support quantities in lab results,
> which are sometimes of the form Y etc. If I had my time again, I
> would have moved the date/time types out a bit so they did not inherit
> this attribute. Usually it is Void.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá
I'm not really sure that it even means what we need in this case

El lun., 24 sept. 2018 19:35, Diego Boscá  escribió:

> I've never understood the usefulness of that attribute: Seems strange to
> populate an attribute that will end up in data with a value that could
> provoke misunderstandings
>
> El lun., 24 sept. 2018 19:23, Ian McNicoll  escribió:
>
>> Hi Diego,
>>
>> Does DV_DURATION not inherit magnitude_status as a separate attribute
>> from the RM?
>>
>>
>> https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
>>
>> Not sure it would work in archetyping constraint but in data it
>> would/should just be
>>
>> value: "P24H"
>> magnitude_status: "<"
>>
>> 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 Mon, 24 Sep 2018 at 17:08, Diego Boscá  wrote:
>>
>>> Yeah, it is supported in 1.4. However, I'm not sure that that Durations
>>> are the way to go here, as all the duration is constraint as string, which
>>> means string lists or regex in best case scenario, which IMO makes pretty
>>> difficult to represent the "<" or ">". Personally I would go with an
>>> alternative of dv_quantity, as a single one with range is impossible to be
>>> created if they don't share the same units. When validating, only one of
>>> the alternatives needs to be valid, thus complying with the "or"
>>>
>>>
>>>
>>> El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
>>> escribió:
>>>
>>>> Not sure if this is already in the RM version you use and not sure if
>>>> ADL 1.4 supports this, but can this be a DV_INTERVAL of DV_DURATION?
>>>>
>>>> Regards,
>>>>
>>>> Pieter Bos
>>>>
>>>> Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland" <
>>>> silje.ljosland.ba...@nasjonalikt.no>:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I’ve got a use case where we need to represent a time duration (of a
>>>> symptom), which can be for example <24H or >3M. Is it possible to represent
>>>> this using the DV_DURATION data type, like you can do with DV_QUANTITY and
>>>> magnitude_status? If not, what should we do?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>> Silje Ljosland Bakke
>>>>
>>>>
>>>>
>>>> Information Architect, RN
>>>>
>>>> Coordinator, National Editorial Board for Archetypes
>>>> Nasjonal IKT HF, Norway
>>>>
>>>> Tel. +47 40203298
>>>>
>>>> Web: http://arketyper.no<http://arketyper.no/> / Twitter:
>>>> @arketyper_no<https://twitter.com/arketyper_no>
>>>>
>>>>
>>>>
>>>> ___
>>>> openEHR-technical mailing list
>>>> openEHR-technical@lists.openehr.org
>>>>
>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>>
>>>
>>>
>>> --
>>>
>>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>>
>>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>>>   <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>>> <https://htmlsig.com/t/01BZTWS7>
>>>
>>> Diego Boscá Tomás / Senior developer
>>> diebo...@veratech.es
>>> yamp...@gmail.com
>>>
>>> VeraTech for Health SL
>>> +34 654604676 <+34%20654604676>
>>> www.veratech.es
>>>
>>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>>> exigidos por

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá
I've never understood the usefulness of that attribute: Seems strange to
populate an attribute that will end up in data with a value that could
provoke misunderstandings

El lun., 24 sept. 2018 19:23, Ian McNicoll  escribió:

> Hi Diego,
>
> Does DV_DURATION not inherit magnitude_status as a separate attribute from
> the RM?
>
>
> https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
>
> Not sure it would work in archetyping constraint but in data it
> would/should just be
>
> value: "P24H"
> magnitude_status: "<"
>
> 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 Mon, 24 Sep 2018 at 17:08, Diego Boscá  wrote:
>
>> Yeah, it is supported in 1.4. However, I'm not sure that that Durations
>> are the way to go here, as all the duration is constraint as string, which
>> means string lists or regex in best case scenario, which IMO makes pretty
>> difficult to represent the "<" or ">". Personally I would go with an
>> alternative of dv_quantity, as a single one with range is impossible to be
>> created if they don't share the same units. When validating, only one of
>> the alternatives needs to be valid, thus complying with the "or"
>>
>>
>>
>> El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
>> escribió:
>>
>>> Not sure if this is already in the RM version you use and not sure if
>>> ADL 1.4 supports this, but can this be a DV_INTERVAL of DV_DURATION?
>>>
>>> Regards,
>>>
>>> Pieter Bos
>>>
>>> Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland" <
>>> silje.ljosland.ba...@nasjonalikt.no>:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I’ve got a use case where we need to represent a time duration (of a
>>> symptom), which can be for example <24H or >3M. Is it possible to represent
>>> this using the DV_DURATION data type, like you can do with DV_QUANTITY and
>>> magnitude_status? If not, what should we do?
>>>
>>>
>>>
>>> Kind regards,
>>> Silje Ljosland Bakke
>>>
>>>
>>>
>>> Information Architect, RN
>>>
>>> Coordinator, National Editorial Board for Archetypes
>>> Nasjonal IKT HF, Norway
>>>
>>> Tel. +47 40203298
>>>
>>> Web: http://arketyper.no<http://arketyper.no/> / Twitter: @arketyper_no<
>>> https://twitter.com/arketyper_no>
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> ___
>> 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: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá
Yeah, it is supported in 1.4. However, I'm not sure that that Durations are
the way to go here, as all the duration is constraint as string, which
means string lists or regex in best case scenario, which IMO makes pretty
difficult to represent the "<" or ">". Personally I would go with an
alternative of dv_quantity, as a single one with range is impossible to be
created if they don't share the same units. When validating, only one of
the alternatives needs to be valid, thus complying with the "or"



El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
escribió:

> Not sure if this is already in the RM version you use and not sure if ADL
> 1.4 supports this, but can this be a DV_INTERVAL of DV_DURATION?
>
> Regards,
>
> Pieter Bos
>
> Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland" <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> Hi,
>
>
>
> I’ve got a use case where we need to represent a time duration (of a
> symptom), which can be for example <24H or >3M. Is it possible to represent
> this using the DV_DURATION data type, like you can do with DV_QUANTITY and
> magnitude_status? If not, what should we do?
>
>
>
> Kind regards,
> Silje Ljosland Bakke
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no<http://arketyper.no/> / Twitter: @arketyper_no<
> https://twitter.com/arketyper_no>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: GDPR and OpenEhr.

2018-09-04 Thread Diego Boscá
Really useful resource Ricardo!

El mar., 4 sept. 2018 a las 16:41, Ricardo Correia (<
ricardo.jc.corr...@gmail.com>) escribió:

> Dear all,
>
> I published recently an attempt to "systematyse" the relation between
> openehr and gdpr.
>
> Hope it is useful to you.
>
> Link: http://ebooks.iospress.nl/publication/48760
>
>
> Regards,
>
> Ricardo Correia
>
> ---
> Ricardo João Cruz Correia
> Professor Auxiliar
> ISI: www.researcherid.com/rid/A-2756-2009
> research gate: www.researchgate.net/profile/Ricardo_Cruz-Correia/
> OrcId: orcid.org/-0002-3764-5158
> linked-in: pt.linkedin.com/in/ricardojccorreia
> <http://pt.linkedin.com/in/ricardojccorreia%E2%80%8E>‎
> <http://pt.linkedin.com/in/ricardojccorreia‎>
>
>
> *MEDCIDS* - Departamento de Medicina da Comunidade, Informação e Decisão
> em Saúde <http://cides.med.up.pt/>
> *CINTESIS* - Center for Research in Health Technologies and Information
> Systems <http://cintesis.med.up.pt>
> Faculty of Medicine, University of Porto
>
> Tel: (+351) *220 426 909 / *(+351) *225 513 622,* Fax: +351 *225 513 623*
> Rua Dr. Plácido da Costa, s/n | 4200-450 Porto | *Portugal*
>
>
> On Mon, Sep 3, 2018 at 2:26 PM Bert Verhees  wrote:
>
>>
>>
>>
>> In all other contexts the patient can never be forgotten or deleted. Any
>>> legal transaction is subject to archiving laws. For tax purposes the time
>>> period is 5 years in the Netherlands, I think. Only after these periods as
>>> defined by law the transactions can/must be deleted.
>>>
>>
>> It is true that there are laws which make it necessary to keep certain
>> data, good example, taxes. I business owner must keep a record of all
>> financial transactions. I think the GDPR excludes this from its effect,
>> because laws may not contradict each other.
>>
>> Thanks for this remark
>>
>> Bert
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: GDPR and OpenEhr.

2018-09-01 Thread Diego Boscá
And as I said this is covered by the exemptions to hard delete on that law
article, no need for German providers to delete nothing their national law
doesn't allow for.

El sáb., 1 sept. 2018 a las 20:42, Karsten Hilbert ()
escribió:

> On Sat, Sep 01, 2018 at 08:29:33PM +0200, Diego Boscá wrote:
>
> > There is in fact that right, the "right to be forgotten"
> > https://gdpr-info.eu/art-17-gdpr/
> > The requirement you say about Germany is backed by sections 3 (b) and (c)
> > These exceptions do not apply to private providers, so we have the legal
> > need to support that kind of delete operations to allow openEHR systems
> to
> > be GDPR compliant
>
> Whether we like it or not (I do not like it, personally, as a
> patient, but do like it, professionally, as a GP): in Germany
> there is the right to keep a record "as long as there is
> suspicion you might be sued such that you can exercise your
> right to defend yourself". 30 years is the latest you can be
> sued in Germany. So that's when a hard delete can be
> requested (arguably it even becomes mandatory). Period.
>
> However, the provider is legally bound to make sure the
> record is not used after the patient requests that (there's
> other time limits for other things, but that's the most a
> patient can *request* after those other deadlines have
> passed and before 30 years are over).
>
> It doesn't matter what anyone thinks. That is the legal
> situation ATM.
>
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: GDPR and OpenEhr.

2018-09-01 Thread Diego Boscá
Permanent annonimisation is allowed under some prerequisites (see the other
reply, point 3 of art 17). This is a patient right to be exercised with all
consequences. Data will never be lost as the patient has the right of
obtaining a copy of all the information a provider has about him in an
electronic standard when available. Luckily we can provide also that.

El sáb., 1 sept. 2018 a las 20:29, Thomas Beale ()
escribió:

> I continue to wonder what will happen when a cancer patient (perhaps in a
> moment of depression or disaffection with care) asks for the hard delete,
> gets better, then has a recurrence a few years later. What does the health
> system do when *all the notes are really gone*?
>
> I think a better solution is to create a digital locked room when such
> EHRs are put, one-way encrypted with a giant key provided by the patient.
> Then when they have regrets, they can ask - nicely - for their record to
> come out of cold storage.
>
> Another argument against total deletion is that a) the state has invested
> in helping sick patients and b) other citizens have a potential interest in
> health records belonging to those in the same major disease cohort, i.e.
> diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous deletions are
> certainly going to compromise research that looks at longitudinal Dx v
> treatments v outcomes. Perhaps perhaps permanent anonymisation is a better
> solution in this case, with the original patient being given the new EHR id.
>
> I think GDPR has some way to go yet in healthcare...
>
> - thomas
>
> On 01/09/2018 18:57, Diego Boscá wrote:
>
> If a patient uses a private health provider then he has the right of
> taking all that information and move to another provider. In that case he
> will want a hard-delete of data. And I hope private health providers are
> also able to use openEHR ;D
> I think we should also review the "consent" mechanisms we have, as they
> probably should also be tweaked to comply with GDPR.
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: GDPR and OpenEhr.

2018-09-01 Thread Diego Boscá
There is in fact that right, the "right to be forgotten"
https://gdpr-info.eu/art-17-gdpr/
The requirement you say about Germany is backed by sections 3 (b) and (c)
These exceptions do not apply to private providers, so we have the legal
need to support that kind of delete operations to allow openEHR systems to
be GDPR compliant

El sáb., 1 sept. 2018 a las 20:17, Karsten Hilbert ()
escribió:

> On Sat, Sep 01, 2018 at 07:57:31PM +0200, Diego Boscá wrote:
>
> > If a patient uses a private health provider then he has the right of
> taking
> > all that information and move to another provider. In that case he will
> > want a hard-delete of data.
>
> Indeed they will want that, but there is no absolute right
> for a hard-delete (not that I personally like that fact). As
> I said, in Germany, that right currently only takes effect
> after 30 years (that absolute right). In the meantime,
> however, there's a right for sealing against access.
>
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: GDPR and OpenEhr.

2018-09-01 Thread Diego Boscá
If a patient uses a private health provider then he has the right of taking
all that information and move to another provider. In that case he will
want a hard-delete of data. And I hope private health providers are also
able to use openEHR ;D
I think we should also review the "consent" mechanisms we have, as they
probably should also be tweaked to comply with GDPR.

El sáb., 1 sept. 2018 a las 19:25, Ian McNicoll ()
escribió:

> Hi Bert,
>
> There are certainly some implementations that allow for hard-deletes of
> compositions and Ehrs. This is a complex area as GDPR does not confer an
> absolute right for medical info to be forgotten (as I understand it). It
> does allow for copies of the record to be retained for medico-legal
> purposes.
>
> However, in our cloud-provider setting, we absolutely need to be able to
> hard delete Ehrs, as people may simply want to switch CDR providers. As a
> data processor, we have no right to keep t record, as long as it is
> available via another provider.
>
> 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 Sat, 1 Sep 2018 at 14:52, Bert Verhees  wrote:
>
>> OpenEhr does not really allow to delete data, only logical deletion (mark
>> as deleted), but GDPR demands the right of the patient to be forgotten.
>>
>> Is there some change expected in the specs for compliance to GDPR, or was
>> this already implemented?
>>
>> We had this discussion, slightly different, about ten months ago but no
>> conclusion if I recall well
>>
>> Sorry if I missed a message about this.
>>
>> Thanks
>> Bert Verhees
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Is description = <"*"> mandatory?

2018-08-09 Thread Diego Boscá
In LinkEHR we used to put a default description including the rm type, but
a couple of years ago we decided that it was better to just put an empty
string.

El jue., 9 ago. 2018 a las 16:03, Thomas Beale ()
escribió:

> Hi Silje,
>
> In ADL 1.4, optionality is not specified for the fields of an
> ARCHETYPE_TERM
> <https://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_overview_5>
> - they are essentially all optional. However, clearly having no 'text'
> field is bad / useless.
> In ADL2, which should be used as a guide, 'text' and 'description' fields
> are both specified as mandatory
> <https://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>
> .
>
> Normally the 'text' field should be used for something short and
> meaningful, with the 'description' field containing the longer version.
> However, here I think you are talking about the term definitions of
> DV_ORDINALs, and I guess the idea is that you want to put all the text into
> the 'text' field, since it is a more or less formal definition.
>
> In such cases, since the 'description' field should exist, it can just be
> empty, i.e.
>
> description = <"">
>
> Practically speaking, the current tools are probably doing nearly the
> right thing, but it would be better if there were no '*'.
>
> - thomas
>
> On 09/08/2018 13:43, Bakke, Silje Ljosland wrote:
>
> Hi everyone,
>
>
>
> In modelling cases, particularly where we’re modelling scores and scales,
> the description element of text or ordinal values are unnecessary, because
> the value defined in the score only contain a single string of text. A good
> example of this is the ECOG Performance Status archetype, where editors
> (both Ocean’s AE and Marand’s AD) add a ‘*’ in the empty description
> element, like this:
>
>
>
> ["at0005"] = <
>
> text = <"Fully active, able to carry on all
> pre-disease performance without restriction.">
>
> description = <"*">
>
> >
>
>
>
> Is the description element mandatory, since the editors both do this?
> Could we, in cases where we don’t need it, leave out the description
> altogether?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no / Twitter: @arketyper_no
> <https://twitter.com/arketyper_no>
>
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Project, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/> | The Objective Stance
> <https://theobjectivestance.net/>
> _______
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: The openEHR Asia summit succeeded.

2018-07-30 Thread Diego Boscá
Conferences were transmitted in real time, they are available at the
openEHR JP youtube channel
https://www.youtube.com/channel/UCTIV2k0OhooiuvRgPSqY-iw

2018-07-30 14:10 GMT+02:00 Ian McNicoll :

> Many congratuations Shinji,
>
> The screenshots looked intruiging. Would it be possible to link the
> presentations, pictures and any videos from the openEHR website? We cna add
> to the Events section as we did in the past for other events.
>
> 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 Mon, 30 Jul 2018 at 12:58, Shinji KOBAYASHI  wrote:
>
>> Dear openEHR colleagues,
>>
>> We completed all the schedule for the first openEHR Asia summit, and
>> the second general assembly of Japan.
>> We also celebrated the new board member, Xudong Lu with many kampais.
>> Congratulations.
>> In Asia, openEHR activities are supported with ground roots, and
>> growing steadily.
>> Dr Ryan Bannez showed his beautiful EMR system based on Marand
>> EhrScape in Philippines, and 40 clinics adopted that.
>> Prof Xudong Lu showed 5 big projects plan in China.
>> I presented openEHR Japan activity and nation-wide EHR project in
>> Japan, that involving 75 hospitals.
>> The next openEHR Asia summit will be in China in the next year.
>>
>> Best regards,
>> Shinji Kobayashi
>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Empty COMPOSITION.content is valid?

2018-07-26 Thread Diego Boscá
You would be surprised to the amount of legacy data with no clinical
content, just because original systems allowed it

El jue., 26 jul. 2018 10:41, Bert Verhees  escribió:

> On 26-07-18 09:57, Thomas Beale wrote:
> > Does it make sense to have an empty COMPOSITION.content?
>
> Imagine a visit to a GP, and nothing clinical comes out of it. Nothing
> worth mentioning, but still having had a composition and a consult to
> pay for.
>
>
> ___
> 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: UCUM/SNOMED/custom units

2018-07-23 Thread Diego Boscá
Units need to be (and will be) revamped, we also need other things already
discussed in other posts like rubric, long descriptions (which could be
language dependent), etc. This could be very useful for better describing
custom UCUM units too.
Several alternatives are being explored in order to not break current units
definitions. Maybe adding an optional codephrase or terminology mapping
could do the trick, as then you can tell where the unit comes from and
allows you to provide a "code" which could either contain a Snomed code or
a UCUM expression. Inputs are appreciated as always :)

Regards

2018-07-23 13:14 GMT+02:00 Bert Verhees :

> I wonder if it is possible to use other units then UCUM units in
> DV_QUANTITY. I read from Pablo in Stackoverflow that the SEC is considering
> custom units. I think this is great, but I see some problems coming up. I
> have some questions about this,
>
> I wonder how you can do that without changing the DV_QUANTITY-definition,
> because it has a units-attribute, it says it must be expressed in UCUM
> syntax. It does not say anything about the unit itself, only about the
> notation.
>
> Must we understand UCUM so, that it has not only a syntax for its own
> units, but also for custom units?
>
> That is strange, because custom-units (non-UCUM) can carry custom
> (non-UCUM) syntax-descriptions. So if we are writing a custom unit, and
> using a syntax to specify it, then we need two references, don't we?
>
> One reference for where the unit comes from, and one reference for the
> syntax?
>
>
> A custom unit can also occur in another standard, for example SNOMED, also
> a UCUM-unit can occur in SNOMED, but is it sure it means the same? Normally
> we are very prudent about things like this.
> I found a HL7 wiki about this. Someone did some thinking about this. I
> think that also applies to OpenEhr.
>
> http://wiki.hl7.org/index.php?title=Representation_of_Units
>
> Best regards
> Bert Verhees
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Diego Boscá
We had to wrestle with data transformation in our early days, which made us
learn things in the hard way :)
As you said ADL2 addresses most of these issues so I think it is definitely
the way to go.

2018-07-13 13:37 GMT+02:00 Thomas Beale :

>
>
> On 13/07/2018 12:13, Diego Boscá wrote:
>
>> Technically in ADL1.4 it is completely legal that alternatives have their
>> own node codes. Other thing is that OPT or current software supports it
>>
>
> it is legal, but not always implemented. Your group (UPV) did the right
> thing with LinkEHR early on, and I should have fixed it in ADL 1.4... the
> beauty of hindsight...
>
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Diego Boscá
Technically in ADL1.4 it is completely legal that alternatives have their
own node codes. Other thing is that OPT or current software supports it

2018-07-13 13:05 GMT+02:00 Thomas Beale :

>
>
> On 06/07/2018 18:03, Pablo Pazos wrote:
>
>> Hi Dileep,
>>
>> In the EHRServer we use the template path as an absolute path for each
>> node in the template, that allows to identify each node in the OPT even if
>> different nodes hang from the same archetype root (have the same archetype
>> path). This allows querying for the right node.
>>
>> Also there is another case when nodes with the same path but different
>> data type are in a composition instance. We use the path + type to identify
>> those node alternatives.
>>
>
> THis case disappears with the use of ADL2, which prevents alternatives not
> having node codes ('id-codes' in ADL2).
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Is the proportion kind "integer fraction" correct?

2018-07-03 Thread Diego Boscá
But following the same reasoning you could say that "integer fraction"
makes the values to be interpreted differently from percert, unary or
ratio, and has no real semantic difference, thus "fraction" being only a
visual representation of "integer fraction" ;)

2018-07-03 2:00 GMT+02:00 Pablo Pazos :

> But I think "fraction" makes the values of the DV_PROPORTION (numerator,
> denominator) to be interpreted differently from other proportion kinds
> (percent, unary, ratio). My point is "fraction" and "integer fraction" have
> no real semantic differences, and "integer fraction" is just for visual
> representation.
>
> On Mon, Jul 2, 2018 at 8:50 PM, Diego Boscá  wrote:
>
>> both that and fraction seem to be intended for visualization purposes
>> more than real constraints.
>>
>> 2018-07-03 1:19 GMT+02:00 Pablo Pazos :
>>
>>> Hi, I'm checking the datatypes specs doing some modeling tests on the
>>> archetype editor.
>>>
>>> In the specs, the "integer fraction" proportion kind means the
>>> representation of the fraction 3/2 should be 1 1/2.
>>>
>>> http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_t
>>> ypes/data_types.html#_proportion_kind_class
>>>
>>> Semantically I think this is not on the same level as the other
>>> "proportion kinds", since it doesn't represent a kind, but a format, where
>>> the same values can be recorded as numerator (3) and denominator (2) with
>>> proportion kind "fraction" and will mean the same thing. IMO "integer
>>> fraction" doesn't even change the meaning or interpretation of the
>>> fraction, while other "proportion kinds" do.
>>>
>>> My question is if the "integer fraction" really belongs to a "proportion
>>> kind" or should be somewhere else on the specs? I guess this tried to solve
>>> a use case and it was a shorthand to represent this format as a proportion
>>> kind.
>>>
>>>
>>> Thanks,
>>> Pablo.
>>>
>>> --
>>> *Ing. Pablo Pazos Gutiérrez*
>>> pablo.pa...@cabolabs.com
>>> +598 99 043 145
>>> skype: cabolabs
>>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>> <https://cabolabs.com/>
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> Su dirección de correo electrónico junto a sus datos personales forman
>> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
>> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
>> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
>> rectificación, cancelación y, en su caso oposición, enviando una solicitud
>> por escrito a verat...@veratech.es.
>>
>> ___
>> 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://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> 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
>
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Is the proportion kind "integer fraction" correct?

2018-07-02 Thread Diego Boscá
both that and fraction seem to be intended for visualization purposes more
than real constraints.

2018-07-03 1:19 GMT+02:00 Pablo Pazos :

> Hi, I'm checking the datatypes specs doing some modeling tests on the
> archetype editor.
>
> In the specs, the "integer fraction" proportion kind means the
> representation of the fraction 3/2 should be 1 1/2.
>
> http://www.openehr.org/releases/RM/Release-1.0.3/
> docs/data_types/data_types.html#_proportion_kind_class
>
> Semantically I think this is not on the same level as the other
> "proportion kinds", since it doesn't represent a kind, but a format, where
> the same values can be recorded as numerator (3) and denominator (2) with
> proportion kind "fraction" and will mean the same thing. IMO "integer
> fraction" doesn't even change the meaning or interpretation of the
> fraction, while other "proportion kinds" do.
>
> My question is if the "integer fraction" really belongs to a "proportion
> kind" or should be somewhere else on the specs? I guess this tried to solve
> a use case and it was a shorthand to represent this format as a proportion
> kind.
>
>
> Thanks,
> Pablo.
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> 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
>
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: SV: [Troll] Terminology bindings ... again

2018-03-31 Thread Diego Boscá
What I say is that legacy applications or current systems usually offer
limited options with the knowledge available when they were created. These
options were decided back in the day and usually fit with precoordinated
terms. And defining this subsets helps on going forward

El sáb., 31 mar. 2018 22:14, Philippe Ameline <philippe.amel...@free.fr>
escribió:

> Some people (count me in) strictly ban what you call precoordination (that
> I call "aglutinating language") because they believe that there is a nearly
> infinite set of them and such a system is born to "explode" as the frog
> that wanted to mimic the ox.
>
> To put it differently: you cannot express all possible discourses as
> predetermined concepts.
>
> Do I interpret your answer correctly if I say that you have an optimist
> vision in the form "there is a limited number of clinically sound
> precoordinations so that SNOMED expansion will reach an asymptote that keep
> being manageable"?
>
> Le 31/03/2018 à 20:55, Diego Boscá a écrit :
>
> What I was referencing was one way in which current systems (or more
> exactly, their developers) could use codes already available in Snomed to
> create subsets of their forms, regardless their input forms have
> precoordinated options or use some kind of postcoordination mechanism. By
> defining these subsets, you are making this form comparable with other
> similar forms (that use other approaches to store similar information). It
> isn't about making doctors in the same organization being able to have
> *new* ways of encoding things, is about taking the forms they currently use
> and encode them in order to be comparable with data in other organizations
> (and in principle, they don't even need to be aware of this codification).
> With this, we can make data have a meaning outside their original systems.
>
> This is why I say that precoordination in snomed is a good thing. They are
> terms that have been put in a form somewhere, and having them as is, and at
> the same time having their undelying equivalent postcoordinated expression
> helps in softening the boundary problem IMHO.
> I'm always up to go into the future inventing new cool things, but at
> least in healthcare we are not allowed to lose data already available in
> current systems.
>
> 2018-03-31 11:38 GMT+02:00 Philippe Ameline <philippe.amel...@free.fr>:
>
>> Diego,
>>
>> IMHO your contribution is orthogonal to what Thomas very accurately
>> explained. Building subset is a symptom of the issue, not a solution.
>>
>> As I tried to explain in my initial post, we are currently facing two
>> generation of technologies in medicine:
>> - systems that record information as trees of atomic concepts, in the
>> same way we are all exchanging in "globish" by inserting English concepts
>> in a grammatical structure,
>> - systems that still rely on a fixed database schema and usually have a
>> "discourse system" limited to field/value pairs.
>>
>> When I try to explain all this to lesser tech-savvy people (means, who
>> don't belong to this list ;-) ), I usually explain that:
>> - usual systems (with an information schema tied to a database schema)
>> are like a printed form. The day after you received the 5000 printed sheet
>> you ordered, you will realize that there are several design flaws that you
>> will have to endure while the stock is not empty,
>> - openEHR is a flexible schema, similar to a set of stamps that lets you
>> build forms dynamically from blank paper. If your design has to evolve, you
>> just have to adapt one of the stamps.
>> - in my system, based on an ontology and a dependency grammar, you can
>> use stamps (archetypes like) and/or "write" freely.
>>
>> I have always understood openEHR as a link, a step, between the "good old
>> way" (discourse range hard coded into a database schema) and a modern
>> approach where you can really "tell a patient story" using a genuine
>> (structured, processable) language. 15 years ago, Thomas and I spent hours
>> discussing the opportunity for openEHR to include a reference ontology in
>> its kernel ; this decision was not made for very good reasons, but I guess
>> that it still remains a necessary evolution.
>>
>> Thomas very accurately explained why SNOMED is a deceptive candidate for
>> such a reference ontology. And, unfortunately, it is deep rooted in its
>> origins as a coding system. I can hear all the arguments about "legacy
>> system" and even "legacy medicine" (the one still fully organized for
>> siloed acute care at a time our society alread

Re: SV: [Troll] Terminology bindings ... again

2018-03-23 Thread Diego Boscá
; Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-20 Thread Diego Boscá
Nothing restricts you to create a "data type pattern"/specialized cluster
that has exactly this semantics

El mar., 20 mar. 2018 23:34, A Verhees  escribió:

> One last remark.
>
> There is in medical context need of a datatypes to express: "do this one
> time a month, for example on a specific date".
>
> But technically seen, this is not a duration, the maybe a need for another
> datatype to express this.
>
> Using the duration for this may be a handy shortcut in specs, but it is
> not right. It is in fact misusing a datatype which does not support this
> expression. The ISO string should also be changed accordingly.
>
> Bert
>
> Op 20 mrt. 2018 23:24 schreef "A Verhees" :
>
>> Now I come to think about it, I remember reading somewhere that
>> conversion durations to number of years or months is no longer desired
>> because years and months do not have always the same number of nanoseconds.
>>
>> Of course conversions to days and weeks is easy, although they are also
>> not always the same, but that can be ignored, it is one second every few
>> years.
>>
>> Op 20 mrt. 2018 23:08 schreef "A Verhees" :
>>
>>> Now you say, you are right.
>>>
>>> The Java 8 duration is indeed diffrent, but you can still use the Joda
>>> duration, or you can write your own duration class. In Golang the duration
>>> class is also limited, it is build around nanoseconds, but I wrote my own
>>> which is conform the OpenEhr specs, which was not that hard.
>>>
>>> https://golang.org/pkg/time/#Duration
>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>>
>>> Maybe it is a good idea for the OpenEhr community to study the duration
>>> type again to see why in two major programming languages there is another
>>> approach build around nanoseconds and having  conversions to hours, etc.
>>> Maybe there is another trend coming up. Maybe it is interesting to conform
>>> to these trends
>>>
>>> Bert
>>>
>>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>>>
>>> Thanks Thomas, will create the PR!
>>>
>>> Also will double check if the same happens with other types, but I think
>>> the only "odd" one that might not be correct to assume, is the Duration.
>>> For instance, Java 8 added the Duration as a base type, but it only handles
>>> day to seconds duration expressions, year, month, week are not supported.
>>> Each technology has it's own quirks :)
>>>
>>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
>>> wrote:
>>>


 On 19/03/2018 22:25, Pablo Pazos wrote:

 Hi Thomas, the definition of DV_DURATION is clear to me :)

 The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
 C_DURATION because the referenced Duration class in C_DURATION was not
 included on the specs. *This is the issue I'm pointing to, the missing
 class.*


 Right - the ADL/AOM 1.4 specs made the assumption that each primitive
 constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
 constrained a same- or similarly named primitive type like Integer, String,
 Date, Duration etc that are assumed to be part of the technology
 environment. THey are normally part of the programming language, DB, or
 serialisation formalisms.

 I think this probably was not as clear as it should have been in that
 spec.

 In the AOM2/ADL2 specs, we have clarified this so that the same types
 (C_INTEGER etc) now refer to types that are defined in the Foundation spec
 of the BASE component.


 Clarifying that on an errata addendum would help to avoid such
 implementation mistakes, that are really caused by the missing information
 on the spec + interpretation to fill the gap.


 agree, we should do this - can you create a PR for this? Or add to an
 existing PR.



 BTW, this is one case that I detected because I'm doing research for a
 new course. There might be issues like this on other areas of 1.0.2, I mean
 missing classes referenced from AOM or AOP. I didn't do a complete review
 of the specs.

 I would love to migrate everything to baseline spec and use AOM2, but I
 can't afford the cost right now. I'm sure others are on my same position.


 hopefully that will change soon, because ADL2 is more regular and
 simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
 I'd be interested to know what the real costs are and to see what we can do
 to make the transition simpler, because staying with ADL1.4 is limiting
 system functionality for the future.


 BTW tried to check if the issue is also on 1.0.3 but the link to
 support is broken http://openehr.org/RM/Release-1.0.3/support.html


 the page where you got that link
  is 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-20 Thread Diego Boscá
We can revisit all the types we want, but we shouldn't forget that types
will be used for medical data, and maybe we don't really need nanosecond
precision.

El mar., 20 mar. 2018 23:09, A Verhees  escribió:

> Now you say, you are right.
>
> The Java 8 duration is indeed diffrent, but you can still use the Joda
> duration, or you can write your own duration class. In Golang the duration
> class is also limited, it is build around nanoseconds, but I wrote my own
> which is conform the OpenEhr specs, which was not that hard.
>
> https://golang.org/pkg/time/#Duration
> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>
> Maybe it is a good idea for the OpenEhr community to study the duration
> type again to see why in two major programming languages there is another
> approach build around nanoseconds and having  conversions to hours, etc.
> Maybe there is another trend coming up. Maybe it is interesting to conform
> to these trends
>
> Bert
>
> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>
> Thanks Thomas, will create the PR!
>
> Also will double check if the same happens with other types, but I think
> the only "odd" one that might not be correct to assume, is the Duration.
> For instance, Java 8 added the Duration as a base type, but it only handles
> day to seconds duration expressions, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
> wrote:
>
>>
>>
>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>
>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>
>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>> C_DURATION because the referenced Duration class in C_DURATION was not
>> included on the specs. *This is the issue I'm pointing to, the missing
>> class.*
>>
>>
>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>> constrained a same- or similarly named primitive type like Integer, String,
>> Date, Duration etc that are assumed to be part of the technology
>> environment. THey are normally part of the programming language, DB, or
>> serialisation formalisms.
>>
>> I think this probably was not as clear as it should have been in that
>> spec.
>>
>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>> of the BASE component.
>>
>>
>> Clarifying that on an errata addendum would help to avoid such
>> implementation mistakes, that are really caused by the missing information
>> on the spec + interpretation to fill the gap.
>>
>>
>> agree, we should do this - can you create a PR for this? Or add to an
>> existing PR.
>>
>>
>>
>> BTW, this is one case that I detected because I'm doing research for a
>> new course. There might be issues like this on other areas of 1.0.2, I mean
>> missing classes referenced from AOM or AOP. I didn't do a complete review
>> of the specs.
>>
>> I would love to migrate everything to baseline spec and use AOM2, but I
>> can't afford the cost right now. I'm sure others are on my same position.
>>
>>
>> hopefully that will change soon, because ADL2 is more regular and simpler
>> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
>> interested to know what the real costs are and to see what we can do to
>> make the transition simpler, because staying with ADL1.4 is limiting system
>> functionality for the future.
>>
>>
>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>
>>
>> the page where you got that link
>>  is now
>> fixed.
>>
>> - thomas
>>
>>
>> ___
>> 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 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> 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: [Troll] Terminology bindings ... again

2018-03-15 Thread Diego Boscá
As Ricardo already said, "Pathological fracture of ankle due to secondary
osteoporosis" is less a "word" and more a "phrase" that computers can
easily understand, because it is equivalent to:
64572001 |Disease (disorder)| :
42752001 |Due to| = 703264005 |Secondary osteoporosis (disorder)|
{ 363698007 |Finding site| = 33696004 |Bone structure of ankle
(body structure)|,
  116676008 |Associated morphology| = 22640007 |Pathologic
fracture (morphologic abnormality)| }

I don't know what is 'ancient' about being able to ask things like "give me
all the patients with a diagnosis of a disease due to osteoporosis" or "all
patients with fractures in the lower body"



2018-03-15 21:20 GMT+01:00 Philippe Ameline <philippe.amel...@free.fr>:

> Le 15/03/2018 à 20:30, Ricardo Gonçalves a écrit :
>
>
> I too want to look at the the future and picture a state of art component
> and hopefully a [health] technological utopia, but a lot of work led us to
> what is currently available. Are we taking that to try/improve things and
> get somewhere? Are we holding back until something more mature, more
> usable, more future-alike comes up? Which path is more likely to bring us
> closer to the goal?
>
>
> Hi Ricardo,
>
> The question of settling in a local optimum or to go find a better place
> has probably been the most ancient question that sapiens has been facing ;-)
> Should we keep working hard in this place where harvesting is so hard, or
> should we try to climb this mountain and see if it is not easier on the
> other side?
>
> My opinion is that there is a good reason not to get stuck (trying hard
> forever) with Snomed.
>
> As you said, thinks started with classifications, then some people came up
> with coding systems and later on with ontology. The ability to tell things
> improved step by step and led to an evolution of information structures.
> Meanwhile, the whole society was transformed by ambient information
> systems to the point that we entered the post-industrial era, and, as you
> know it well, the chronic turn demands for a deep reinvention of the
> medical domain.
>
> My opinion is that you cannot cope with such challenges using a "language"
> that, due to its roots as a coding system, includes "words" like
> "Pathological fracture of ankle due to secondary osteoporosis" (concept
> 704293000).
>
> Time will tell if the settlers were more wise than the explorers... and we
> all have to keep in mind, as you nailed it, that we may have different
> goals.
>
> Best,
>
> Philippe
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Re: [Troll] Terminology bindings ... again

2018-03-13 Thread Diego Boscá
I assume the reason is that asking clinicians to do coding without any help
provides great variability and leads to coding errors. What Thomas said
about presenting clinicians with addecuated subsets is key to avoid that.
There are also mechanisms to check coding quality/errors, but usually need
high domain & terminology knowledge (but creating systems that 'learn' from
documentalists' knowledge is feasible)

El mar., 13 mar. 2018 19:03, Pablo Pazos 
escribió:

>
>
> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert 
> wrote:
>
>> > just imagine standardizing every diagnosis
>>
>> That typically leads to either bad statistics or disimproved care.
>>
>
> Can I ask why?
>
>
>>
>> Karsten
>>
>> ___
>> 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
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
> ___
> 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: Terminology bindings ... again

2018-03-12 Thread Diego Boscá
Culture blog
>> <http://wolandsothercat.net/>
>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

2018-03-02 Thread Diego Boscá
Sure thing, see my example :)

2018-03-02 11:23 GMT+01:00 Karsten Hilbert <karsten.hilb...@gmx.net>:

> On Fri, Mar 02, 2018 at 09:47:12AM +0100, Diego Boscá wrote:
>
> > Not sure if I fully understand/agree. As knowledge advances, past data
> > could be seen under a new light (e.g. some medication was given to a set
> of
> > patients and now we know it has a contraindication with another
> medication)
> > and we could get different results each time we run the query, which is
> > exactly what we want
>
> Sure, but, for medico-legal reasons past data must be
> see-able under then-applied rules/constraints/ranges
> as well.
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

2018-03-02 Thread Diego Boscá
 adding this support but downsides will need
> careful management, probably based on profiles/levels etc.
>
>>
>>
>> - thomas
>>
>>
>>
>> ___
>> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

2018-03-02 Thread Diego Boscá
Not sure if I fully understand/agree. As knowledge advances, past data
could be seen under a new light (e.g. some medication was given to a set of
patients and now we know it has a contraindication with another medication)
and we could get different results each time we run the query, which is
exactly what we want

2018-03-02 2:55 GMT+01:00 Colin Sutton <colin.sut...@ctc.usyd.edu.au>:

> There is a risk that the external service could provide different answers
> at different times, if the external service is updated for technical or
> clinical reasons (e.g. knowledge improvements)
> Shouldn't the result of the query to the external service be made at the
> time of the source event, not in AQL.
> —
> Colin
> > On 1 Mar 2018, at 10:31 pm, Bert Verhees <bert.verh...@rosa.nl> wrote:
> >
> > On 01-03-18 12:01, Diego Boscá wrote:
> >> I believe that we need a way in standard AQL to call to arbitrary
> external services, this seems like another use case for that \
> >
> > I agree!
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org
> > http://scanmail.trustwave.com/?c=13000=oeSX2qbCWwprcB5eNMB27oRdY2Loky
> 0QJHUrFju91A=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%
> 2fopenehr-technical%5flists%2eopenehr%2eorg
>
>
> 
> #
> Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive
> email content security solution.
> 
> #
>
> 
> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
> to be read or used by the named addressee. It is confidential and may
> contain legally privileged information. No confidentiality or privilege is
> waived or lost by any mistaken transmission to you. The CTC is not
> responsible for any unauthorised alterations to this e-mail or attachment
> to it. Views expressed in this message are those of the individual sender,
> and are not necessarily the views of the CTC. If you receive this e-mail in
> error, please immediately delete it and notify the sender. You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient.
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

2018-03-01 Thread Diego Boscá
Assuming there is a service that provides the given value for a given
identified range (based on the parameters you provide like sex, age,
race... ) it would be allowing kind of namespaces that have defined
operations. This would also allow easy querying of external terminologies,
public health queries (average/max/min of X in population that has Y, Z, W
properties), etc.

El 1 mar. 2018 12:06 p. m., "Seref Arikan" <
serefari...@kurumsalteknoloji.com> escribió:

> Hi Diego,
>
> I'd like to hear how you'd address the requirement via a call to an
> external service.
>
> I've been holding back on the recent external service calls discussions :)
> there is certainly a need for that but it also has the potential to open a
> can of worms and I'd better no hijack this thread ;)
>
> On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá <yamp...@gmail.com> wrote:
>
>> I believe that we need a way in standard AQL to call to arbitrary
>> external services, this seems like another use case for that
>>
>> El 1 mar. 2018 11:46 a. m., "Seref Arikan" <serefarikan@kurumsalteknoloji
>> .com> escribió:
>>
>>> Hi Colin,
>>> See responses inline please
>>>
>>> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
>>> colin.sut...@ctc.usyd.edu.au> wrote:
>>>
>>>>
>>>>
>>>> On 1 Mar 2018, at 1:59 am, Seref Arikan <serefarikan@kurumsalteknoloji
>>>> .com> wrote:
>>>>
>>>> […]
>>>>
>>>>>
>>>>>
>>>>> First: if the threshold is changing with respect to all instances of a
>>>>> particular composition (template_id = 'x') , when the change happens, 
>>>>> would
>>>>> not you have to update reference ranges of the DV_QUANTITY node in all
>>>>> composition instances across all EHRs to express the new threshold? That
>>>>> is, if you define high systolic blood pressure using a reference value,
>>>>> would not you have to update all blood pressure observations when the
>>>>> accepted 'high' value (threshold) changes?
>>>>>
>>>>> Second: Setting the reference value to express a threshold would make
>>>>> it impossible to query above/below threshold sets of composition via AQL
>>>>> because it'd require a query that uses the WHERE clause as follows:
>>>>> " WHERE some/path/node1.value > 
>>>>> /some/path/node1.reference_range.value"
>>>>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>>>>> the moment, not even grammar-wise (I may be out of date on this one)
>>>>>
>>>>> If you keep the reference value at the application level, all you have
>>>>> to do is update it without having to touch the existing instances and use
>>>>> AQL to select above/below threshold since you can plug the threshold value
>>>>> directly into WHER
>>>>>
>>>>> […]
>>>>>
>>>>  In a clinical trial, the protocol may set thresholds for measurements
>>>> in one version of the protocol, then change the thresholds in a subsequent
>>>> version of the protocol. Since a decision may be based on a threshold
>>>> level, the threshold value needs to be retained along with the measurement
>>>> for each instance under each protocol. So I think you need a new template
>>>> for each protocol.
>>>>
>>> Yep, a new template for each protocol would be what I'd consider, as I
>>> mentioned in another reply. Based on the information I heard so far
>>> regarding the requirements and the specific example you provided here, I'd
>>> consider associating thresholds with the identifier+version of the template
>>> for the protocol: can you see any problems with this in the context of your
>>> specific example?
>>>
>>>>
>>>> An AQL query on the threshold level will therefore need to have a
>>>> unique name for each threshold ( not a value of the threshold) in order to
>>>> retrieve the value used across protocols in the decision, for a simple case
>>>> where the decision algorithm does not change.
>>>>
>>> Such an AQL query would give you the value used for the protocols indeed
>>> (though I don't think you'd need a name, why not use the same path across
>>> different versions of protocol templates?) . You could then use those
>>> values to issue queries to select above/below thres

Re: Setting thresholds

2018-03-01 Thread Diego Boscá
I believe that we need a way in standard AQL to call to arbitrary external
services, this seems like another use case for that

El 1 mar. 2018 11:46 a. m., "Seref Arikan" <
serefari...@kurumsalteknoloji.com> escribió:

> Hi Colin,
> See responses inline please
>
> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
> colin.sut...@ctc.usyd.edu.au> wrote:
>
>>
>>
>> On 1 Mar 2018, at 1:59 am, Seref Arikan > .com> wrote:
>>
>> […]
>>
>>>
>>>
>>> First: if the threshold is changing with respect to all instances of a
>>> particular composition (template_id = 'x') , when the change happens, would
>>> not you have to update reference ranges of the DV_QUANTITY node in all
>>> composition instances across all EHRs to express the new threshold? That
>>> is, if you define high systolic blood pressure using a reference value,
>>> would not you have to update all blood pressure observations when the
>>> accepted 'high' value (threshold) changes?
>>>
>>> Second: Setting the reference value to express a threshold would make it
>>> impossible to query above/below threshold sets of composition via AQL
>>> because it'd require a query that uses the WHERE clause as follows:
>>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
>>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>>> the moment, not even grammar-wise (I may be out of date on this one)
>>>
>>> If you keep the reference value at the application level, all you have
>>> to do is update it without having to touch the existing instances and use
>>> AQL to select above/below threshold since you can plug the threshold value
>>> directly into WHER
>>>
>>> […]
>>>
>>  In a clinical trial, the protocol may set thresholds for measurements in
>> one version of the protocol, then change the thresholds in a subsequent
>> version of the protocol. Since a decision may be based on a threshold
>> level, the threshold value needs to be retained along with the measurement
>> for each instance under each protocol. So I think you need a new template
>> for each protocol.
>>
> Yep, a new template for each protocol would be what I'd consider, as I
> mentioned in another reply. Based on the information I heard so far
> regarding the requirements and the specific example you provided here, I'd
> consider associating thresholds with the identifier+version of the template
> for the protocol: can you see any problems with this in the context of your
> specific example?
>
>>
>> An AQL query on the threshold level will therefore need to have a unique
>> name for each threshold ( not a value of the threshold) in order to
>> retrieve the value used across protocols in the decision, for a simple case
>> where the decision algorithm does not change.
>>
> Such an AQL query would give you the value used for the protocols indeed
> (though I don't think you'd need a name, why not use the same path across
> different versions of protocol templates?) . You could then use those
> values to issue queries to select above/below threshold instances of data.
> This would be a workaround for the AQL problem I mentioned in my second
> point above.
>
>> —
>> Colin
>> --
>>
>> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
>> security solution.
>>
>> --
>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
>> to be read or used by the named addressee. It is confidential and may
>> contain legally privileged information. No confidentiality or privilege is
>> waived or lost by any mistaken transmission to you. The CTC is not
>> responsible for any unauthorised alterations to this e-mail or attachment
>> to it. Views expressed in this message are those of the individual sender,
>> and are not necessarily the views of the CTC. If you receive this e-mail in
>> error, please immediately delete it and notify the sender. You must not
>> disclose, copy or use any part of this e-mail if you are not the intended
>> recipient.
>> --
>>
>> ___
>> 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: Creating a terminology

2018-02-22 Thread Diego Boscá
Matthew, what is the scope of your terminology? Are the terms intended to
appear in data instances? If terms are intrinsic to a set of archetypes
then you could probably define the terms as constraint bindings in each
archetype.

El 22 feb. 2018 1:44 p. m., "Darlison, Matthew" 
escribió:

Dear Gerard,



Many thanks – that’s interesting as an expression of the terminology, but
I’m guessing that was either generated from a machine-readable expression
of the terminology, or would need such a machine-readable version to exist
before it could be instantiated within a terminology server/service? I’m
also interested to try that out, so that other software might be able to
interrogate the resource…



Yours,



Matthew



*From:* openEHR-technical [mailto:openehr-technical-
boun...@lists.openehr.org] *On Behalf Of *GF
*Sent:* 22 February 2018 12:23
*To:* Thomas Beale 
*Subject:* Re: Creating a terminology



Dear Matthew,



In the attachment a candidate terminology as PDF



It is known as SIAMM

Semantic Interpretabily Artefact Modelling method


Gerard   Freriks

+31 620347088 <+31%206%2020347088>
  gf...@luna.nl



Kattensingel  20

2801 CA Gouda

the Netherlands



On 22 Feb 2018, at 13:03, Darlison, Matthew  wrote:



Dear All,

I've been looking for some time for ways of injecting knowledge into the
ecosystem so that it is available to an EHR, but also to other systems that
might want to use it.

I currently think I need to create a terminology (or maybe more than one),
but I've found vanishingly few open tools and little guidance on what I
could use to do this, and experiment to see if it does what I need.

I'd be grateful for any advice...

Yours,

Matthew


___
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: Templates for application form development

2018-02-20 Thread Diego Boscá
These rules/assertions are things we can express with the AM right now,
right?  :D

El 20 feb. 2018 5:37 p. m., "Thomas Beale" 
escribió:

>
> On 19/02/2018 10:47, Pablo Pazos wrote:
>
>> IMO annotating templates with UI info is not a good idea. A layered
>> approach is much cleaner and scalable, i.e. to define a new artifact on top
>> of current templates / archetypes / RM (these are also examples of layered
>> design).
>>
>
> here, 'templates' means pure data templates, i.e. pure RM or other data
> constructs, e.g. PROC (Task Planning) or CDS etc.
>
>
>> Under this approach, if we have UITemplates on top of openEHR Templates,
>> when we generate Operational UITemplates, that will contain UI + structure
>> (template and archetype constraints) + RM references. This would be the
>> final element to be used to feed software. but the underlying models are
>> all separated and have a specific responsibility.
>>
>
> So what I am proposing is what you are calling UITemplates (one could also
> think of DOCTemplates and MSGTemplates) - they are openEHR templates, as in
> being ADL/AOM artefacts, but based on a model of UI/presentation primitives
> that enables RM and other data elements to be embedded.
>
>
>> If we go ahead, we can add another level for workflow, defining an order
>> and conditions under which each "screen" should be displayed, like a
>> WFTemplate, having an Operational WFTemplate that will include all WF + GUI
>> + structure + RM references.
>>
>
> I think this can make sense as either another model layer, or maybe better
> as specific annotations that use FOPL-like or rule statements to define
> work flow, e.g.
>
> when /data/path1/value = "coded" then display (/ui/path5)
>
> where /data/path1 is an archetype path of the kind we are used to,
> pointing to some DV_TEXT element and /ui/path5 is a path through the UI
> template that points to a sub-form, presumably one that knows how to ask
> for a coded text.
>
> If we separate out screen workflow from screen logical layout, then we can
> re-use the latter with different workflows, reprocess it into a PDF or
> other document structure and so on.
>
>
>> We can continue adding layers :)
>>
>
> exactly right.
>
> - thomas
>
> ___
> 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: Templates for application form development

2018-02-19 Thread Diego Boscá
Personally I would prefer if no visualization attributes ended up in the
EHR RM, but I'm fine if we want to create an additional RM to handle
visualization (and we create templates of that model that point to the EHR
model)

2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> On 18-02-18 23:09, GF wrote:
>
>> Is it an idea to annotate nodes with instructions for display.
>>
>
> Personally I think having special templates/archetypes for display is
> better. Templates are create per purpose, and mixing purposes in a single
> template does  seem good idea to me
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

2018-02-18 Thread Diego Boscá
Wops, pressed send button too early.

We have experimented with lforms and conversions from archetypes are really
straightforward

El 18 feb. 2018 10:02 p. m., "Diego Boscá" <yamp...@gmail.com> escribió:

>
> El 18 feb. 2018 7:58 p. m., "Pablo Pazos" <pablo.pa...@cabolabs.com>
> escribió:
>
>> I have a pdf spec in Spanish, this was a university project to have
>> platform independent GUI definitions based on opts, while creating
>> technology specific GUI generators for data entry and display. I mentioned
>> this a while ago on the lists but catched not much attention.
>>
>> Need to do a little translation work :)
>>
>> On Feb 18, 2018 7:51 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote:
>>
>>
>>
>> On 17/02/2018 20:11, Pablo Pazos wrote:
>>
>>> I think SET has a lot of applications, including result sets.
>>> Of course that should interior from LOCATABLE to be archetypable.
>>>
>>> I'm not sure on the types associated with the UI. I have a specification
>>> for UITenplates that includes some of that, I can share it :)
>>>
>>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works, something
>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>> does some of this, and it would also be useful to extract some of the
>> semantics of that tool into a standard specification to support this kind
>> of thing.
>>
>> - thomas
>>
>>
>>
>> ___
>> 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: Templates for application form development

2018-02-18 Thread Diego Boscá
El 18 feb. 2018 7:58 p. m., "Pablo Pazos" 
escribió:

> I have a pdf spec in Spanish, this was a university project to have
> platform independent GUI definitions based on opts, while creating
> technology specific GUI generators for data entry and display. I mentioned
> this a while ago on the lists but catched not much attention.
>
> Need to do a little translation work :)
>
> On Feb 18, 2018 7:51 AM, "Thomas Beale"  wrote:
>
>
>
> On 17/02/2018 20:11, Pablo Pazos wrote:
>
>> I think SET has a lot of applications, including result sets.
>> Of course that should interior from LOCATABLE to be archetypable.
>>
>> I'm not sure on the types associated with the UI. I have a specification
>> for UITenplates that includes some of that, I can share it :)
>>
>>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works, something
> like Balsamiq but with real data connections built in. Marand's EhrExplorer
> does some of this, and it would also be useful to extract some of the
> semantics of that tool into a standard specification to support this kind
> of thing.
>
> - thomas
>
>
>
> ___
> 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: Optmizing AQL

2018-02-17 Thread Diego Boscá
I agree with all your points BTW :)

2018-02-17 15:09 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> On 17-02-18 13:11, Diego Boscá wrote:
>
> Maybe it is possible to generalize it in a way that it could be external
> calls that return a value or list of values. Maybe this is enough for
> SNOMED, CDSS, but also for queries to linked data such as drug-drug
> interaction and other services availabe in bioportal, etc.
>
>
> Hi Diego, I don't know what bioportal is, and how you want to find
> drug-drug interactions. In the Netherlands we have a large and well
> maintained data-vendor for this purpose, called Z-index. But I found that
> SNOMED itself also has drug-drug interactions, and it can, maybe, also
> become a national extension to SNOMED, because drugs often differ from
> country to country.
>
> Maybe this can be decided later, and that first the focus will be on the
> SNOMED part.
>
> I was thinking in your suggested way too (I think), that a special
> value-list-layer is added inside the AQL query-engine, which can do some
> comparison at the moment the AQL engine creates a result-set (internal)
>
> What is important to decide is that the AQL is using a SNOMED resultset,
> and not the other way, so the AQL has the deep magic layer.
> So the magic will happen at a deep internal level the AQL part using the
> SNOMED part cannot be at AQL-API-level, because that would be the same as
> doing the queries separately, and that would be very costly. Although, for
> a start, this is possible.
>
> For SNOMED, I found there are API's defined or being defined, so that
> would be the stable part.
>
> What is very important, but maybe that is already taken care of, we need a
> formal way to include a SNOMED expression into an AQL query.
>
> If we are able to separate a SNOMED part from the AQL part, and define how
> it interacts with the AQL part, then we can parse that SNOMED part in a
> microservice and hand over the result to the database-specific AQL engine
> maintainers/developers.
>
> Bert
>
>
> 2018-02-17 9:23 GMT+01:00 A Verhees <bert.verh...@rosa.nl>:
>
>> The discussion Pablo has makes me think it could be good to have in an
>> AQL-engine an entry to have external query languages executed like SNOMED
>> expressions which can treat result data as hierarchies of data and so add
>> an extra functionality layer
>>
>> Bert
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
>
> ___
> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Optmizing AQL

2018-02-17 Thread Diego Boscá
https://bioportal.bioontology.org/

It has tons of knowledge exposed as queriable web services. All services
have an RDF output, so is perfect to demonstrate linked data

2018-02-17 15:09 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> On 17-02-18 13:11, Diego Boscá wrote:
>
> Maybe it is possible to generalize it in a way that it could be external
> calls that return a value or list of values. Maybe this is enough for
> SNOMED, CDSS, but also for queries to linked data such as drug-drug
> interaction and other services availabe in bioportal, etc.
>
>
> Hi Diego, I don't know what bioportal is, and how you want to find
> drug-drug interactions. In the Netherlands we have a large and well
> maintained data-vendor for this purpose, called Z-index. But I found that
> SNOMED itself also has drug-drug interactions, and it can, maybe, also
> become a national extension to SNOMED, because drugs often differ from
> country to country.
>
> Maybe this can be decided later, and that first the focus will be on the
> SNOMED part.
>
> I was thinking in your suggested way too (I think), that a special
> value-list-layer is added inside the AQL query-engine, which can do some
> comparison at the moment the AQL engine creates a result-set (internal)
>
> What is important to decide is that the AQL is using a SNOMED resultset,
> and not the other way, so the AQL has the deep magic layer.
> So the magic will happen at a deep internal level the AQL part using the
> SNOMED part cannot be at AQL-API-level, because that would be the same as
> doing the queries separately, and that would be very costly. Although, for
> a start, this is possible.
>
> For SNOMED, I found there are API's defined or being defined, so that
> would be the stable part.
>
> What is very important, but maybe that is already taken care of, we need a
> formal way to include a SNOMED expression into an AQL query.
>
> If we are able to separate a SNOMED part from the AQL part, and define how
> it interacts with the AQL part, then we can parse that SNOMED part in a
> microservice and hand over the result to the database-specific AQL engine
> maintainers/developers.
>
> Bert
>
>
> 2018-02-17 9:23 GMT+01:00 A Verhees <bert.verh...@rosa.nl>:
>
>> The discussion Pablo has makes me think it could be good to have in an
>> AQL-engine an entry to have external query languages executed like SNOMED
>> expressions which can treat result data as hierarchies of data and so add
>> an extra functionality layer
>>
>> Bert
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
>
> ___
> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF

Re: Optmizing AQL

2018-02-17 Thread Diego Boscá
Maybe it is possible to generalize it in a way that it could be external
calls that return a value or list of values. Maybe this is enough for
SNOMED, CDSS, but also for queries to linked data such as drug-drug
interaction and other services availabe in bioportal, etc.

2018-02-17 9:23 GMT+01:00 A Verhees <bert.verh...@rosa.nl>:

> The discussion Pablo has makes me think it could be good to have in an
> AQL-engine an entry to have external query languages executed like SNOMED
> expressions which can treat result data as hierarchies of data and so add
> an extra functionality layer
>
> Bert
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

2018-02-17 Thread Diego Boscá
In an ideal world you probably would just ask if the code is in the subset
(both as parameters). From the snomed evaluation cost of both operations
(give me all the codes and is this code in the subset) cost virtually the
same (or less). Also several caching techniques could be used in both
scenarios so recurring queries are instant even for the "A in B" operation

El 17 feb. 2018 8:58 a. m., "A Verhees"  escribió:

Hi, sorry to interfere, if II understand well,

I think a possible problem could be that respiratory infection caused by a
virus can return some derived codes to be returned although in this case it
are not so many.

However to use this mechanism generally, it can happen that really many
derived codes will be returned from the SNOMED engine, and in that case the
AQL query would need to be executed many times. Once for each possible
derived code.

One could also consider to hand over the result set from AQL to the SNOMED
engine to see if it is derived, which could cause less executions.

But in both cases it is datamining which is always difficult to estimate
what the best strategy in a specific case is.

A good idea maybe to design an intelligent query-strategy-decision engine
which offers advice to see what works best. This engine could execute
limited queries, for example, with a count operator so that it does not
need to go all the way when a limit is reached.

It is true what you write that datamining queries seldom are expected to
return in real time, but I have seen situations in marketing were they ran
for hours and queried almost one million dossiers, we even created in
between databases.

That decision engine could also be an external service.

It is good to hear that you think about separated services anyway. That
works in the advantage of a microservices architecture.

Bert

Op za 17 feb. 2018 04:30 schreef Pablo Pazos :

> Hi Pieter,
>
> On Fri, Feb 16, 2018 at 12:27 PM, Pieter Bos  wrote:
>
>> Sounds like a good proposal Pablo.
>>
>>
> The idea came from a PoC I did last year integrating SNOMED expressions
> into openEHR queries.
>
> IMO complex queries will need external very specialized micro services to
> be evaluated, and ADL syntax is not enough to represent some complex
> queries.
>
> For instance, "give me all patients that had a diagnosis of respiratory
> infection caused by virus, from any composition whose archetype is
> specialized from X".
>
>
> 1. "diagnosis" = archID (Problem/Diagnosis) + path_to_coded_diagnosis
> 2. "respiratory infection caused by virus" = SNOMED Expression (<<
> 275498002 |infección del tracto respiratorio (trastorno)| : 246075003
> |agente causal| = 49872002 |virus|)
> 3. "composition defined by a specialization of archetype X" = list of arch
> IDs in a specialization hierarchy
>
>
> 1. Is part of openEHR and the internal data repo model
> 2. Should be evaluated against a service that will return codes in a plain
> list
> 3. Should be evaluated against a service that will return archetype ids in
> a plain list
>
> With 2 and 3 resolved, it is easy to transform everything into SQL or
> whatever, execute the query, get results and transform results in some
> representation (JSON, XML, CSV, etc).
>
> We could still add complexity to the query, and will need more external
> microservices to resolve instead of implementing everything internally
> generating unmaintainable/unescalable/less interoperable systems.
>
> Another idea is to think of query "features", so we can define profiles,
> for instance my queries support SNOMED expressions, your queries support
> querying by archetype hierarchies, etc. If we standardize the features it
> will be easy to have compliance statements for each system, marking which
> features are implemented on an openEHR CDR. And the idea of having external
> micro services that can help implementing those features would help to have
> full featured query interfaces on many different systems, and even reach
> query interoperability (we are far from that right now).
>
>
>
>> For ADL 2 a single archetype api can be used for both archetypes and
>> templates. However, it makes sense to allow the get api of archetypes to
>> specify the form you want the result in: differential, flattened, or
>> operational template (opt2).
>>
>
> IMO most endpoints on the API should be agnostic of the ADL version and
> work with template ids, archetype ids and paths. But of course, if we have
> template management endpoints, that will be ADL/OPT version dependant,
> since formats and models differ.
>
>
>>
>> Our EHR still will integrate the archetype part and query part, as well
>> as the option to choose a used archetype for a slot at runtime. Could all
>> be built with separate services and apis, but once you have everything
>> integrated it makes for a very easy to use API for both EHR and
>> datawarehouse usage. without needing sophisticated client libraries.
>> However, 

Re: Quantities of arbitrary units in openEHR

2018-01-26 Thread Diego Boscá
maybe something like this

ELEMENT[at0004] occurrences matches {0..1} matches {  -- One element
value existence matches {0..1}
matches {
DV_QUANTITY occurrences matches
{0..1} matches {  -- DV_QUANTITY
units existence matches
{1..1} matches {
[ac0001]
}
}
}
}

...


 constraint_binding = <
["UCUM"] = <
items = <
["ac0001"] = <[UCUM::mass]>
>
>
>


'mass' or whatever way of identifying the valid unit set



2018-01-26 10:40 GMT+01:00 Bakke, Silje Ljosland <silje.ljosland.bakke@
nasjonalikt.no>:

> This sounds good in theory, but I don’t think it’ll help me with my
> modelling in the next couple of weeks? J
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-boun
> c...@lists.openehr.org] *On Behalf Of *Diego Boscá
> *Sent:* Friday, January 26, 2018 10:18 AM
> *To:* For openEHR technical discussions <openehr-technical@lists.opene
> hr.org>
> *Subject:* Re: Quantities of arbitrary units in openEHR
>
>
>
> In my mind, this should be done not by fixing a property but by defining a
> constraint reference pointing to the service/set of codes that can provide
> you with all mass units
>
>
>
> 2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> Deriving the properties from the codes makes sense when you actually
> specify the codes, but what do you do when you want to specify “this is a
> concentration, but I don’t care about the exact units”?
>
>
>
> “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all
> for “new units for which we haven’t got the property defined in the
> terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
>
> I see that IUPAC and IFCC has decided to use the term “procedure defined
> unit” instead of “arbitrary unit”.
>
>
>
> Also, does leaving the “property” field out mean that we can have one
> Quantity element with the units Cel, m, kg, ml and [arb'U]?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-boun
> c...@lists.openehr.org] *På vegne av* Diego Boscá
> *Sendt:* fredag 26. januar 2018 09:42
> *Til:* For openEHR technical discussions <openehr-technical@lists.opene
> hr.org>
> *Emne:* Re: Quantities of arbitrary units in openEHR
>
>
>
> I think there are several potential problems with this, and IMHO we are
> stepping too much on what should be done in a terminology service (We are
> literally talking about a 'public available UCUM service'). You can also
> ask the terminology service what kind of unit code you have. Your
> implementation could answer "arbitrary" for these new units.
>
>
>
> In my opinion, saying "here comes a mass unit code" is not much different
> from "here comes a diagnosis code", and we say these in a completely
> different way (a better way, if you ask me).
>
>
>
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
> kind of terminology code that is potentially dangerous as knowledge or
> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
> measurements' all mixed up. That's why I also expect these properties to be
> as derived from the codes and not the other way around.
>
>
>
> 2018-01-26 9:21 GMT+01:00 Sebastian Garde <sebastian.garde@oceaninformat
> ics.com>:
>
> While I agree with the SPEC-95 rationale (once you have a unit, you should
> be able to know what its property is), it is still convenient to have the
> property for constraining.
> Otherwise you don't have a way to say in an archetype: I don't care about
> the exact unit here, but please let it be a "Mass".
>
> -Ursprüngliche Nachricht-
> Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> Im Auftrag von Thomas Beale
> Gesendet: Freitag, 26. Januar 2018 09:13
> An: openehr-technical@lists.openehr.org
> Betreff: Re: Quantities of arbitrary units in openEHR
>
> Right - at the moment, it is a 'fake' field in archetypes, enabled by
> being in the BMM or other expression of the RM. It's convenient to do this
> occasionally, since we don't think 'property' needs to be a field of
> DV_QUANTITY - but maybe it should be, since for so

Re: Quantities of arbitrary units in openEHR

2018-01-26 Thread Diego Boscá
In my mind, this should be done not by fixing a property but by defining a
constraint reference pointing to the service/set of codes that can provide
you with all mass units

2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no>:

> Deriving the properties from the codes makes sense when you actually
> specify the codes, but what do you do when you want to specify “this is a
> concentration, but I don’t care about the exact units”?
>
>
>
> “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all
> for “new units for which we haven’t got the property defined in the
> terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
>
> I see that IUPAC and IFCC has decided to use the term “procedure defined
> unit” instead of “arbitrary unit”.
>
>
>
> Also, does leaving the “property” field out mean that we can have one
> Quantity element with the units Cel, m, kg, ml and [arb'U]?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *På vegne av* Diego Boscá
> *Sendt:* fredag 26. januar 2018 09:42
> *Til:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Emne:* Re: Quantities of arbitrary units in openEHR
>
>
>
> I think there are several potential problems with this, and IMHO we are
> stepping too much on what should be done in a terminology service (We are
> literally talking about a 'public available UCUM service'). You can also
> ask the terminology service what kind of unit code you have. Your
> implementation could answer "arbitrary" for these new units.
>
>
>
> In my opinion, saying "here comes a mass unit code" is not much different
> from "here comes a diagnosis code", and we say these in a completely
> different way (a better way, if you ask me).
>
>
>
> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
> kind of terminology code that is potentially dangerous as knowledge or
> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
> measurements' all mixed up. That's why I also expect these properties to be
> as derived from the codes and not the other way around.
>
>
>
> 2018-01-26 9:21 GMT+01:00 Sebastian Garde <sebastian.garde@
> oceaninformatics.com>:
>
> While I agree with the SPEC-95 rationale (once you have a unit, you should
> be able to know what its property is), it is still convenient to have the
> property for constraining.
> Otherwise you don't have a way to say in an archetype: I don't care about
> the exact unit here, but please let it be a "Mass".
>
> -Ursprüngliche Nachricht-
> Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> Im Auftrag von Thomas Beale
> Gesendet: Freitag, 26. Januar 2018 09:13
> An: openehr-technical@lists.openehr.org
> Betreff: Re: Quantities of arbitrary units in openEHR
>
> Right - at the moment, it is a 'fake' field in archetypes, enabled by
> being in the BMM or other expression of the RM. It's convenient to do this
> occasionally, since we don't think 'property' needs to be a field of
> DV_QUANTITY - but maybe it should be, since for some of the more esoteric
> units, it's not that clear what is being measured.
>
> This trick is also not mentioned in the ADL/AOM specs, and it either
> should be, or we just don't allow it. I don't have a strong opinion either
> way.
>
> - thomas
>
>
> On 26/01/2018 07:51, Pieter Bos wrote:
> > A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification,
> > there is no property attribute or function present in dv_quantity,
> > even though the text says it can be conveniently constrained. There is
> > a reference to the spec-95 jira issue, which says it has been removed.
> > So there’s no way to constrain it - unless the specification contains
> > a mistake :)
> >
> > It is present in the BMM variants of the RM though, as a mandatory field.
> >
> > Regards,
> >
> > Pieter Bos
> >
>
>
> ___
> 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
>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/0

Re: Quantities of arbitrary units in openEHR

2018-01-26 Thread Diego Boscá
I think there are several potential problems with this, and IMHO we are
stepping too much on what should be done in a terminology service (We are
literally talking about a 'public available UCUM service'). You can also
ask the terminology service what kind of unit code you have. Your
implementation could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different
from "here comes a diagnosis code", and we say these in a completely
different way (a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
kind of terminology code that is potentially dangerous as knowledge or
terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
measurements' all mixed up. That's why I also expect these properties to be
as derived from the codes and not the other way around.

2018-01-26 9:21 GMT+01:00 Sebastian Garde <
sebastian.ga...@oceaninformatics.com>:

> While I agree with the SPEC-95 rationale (once you have a unit, you should
> be able to know what its property is), it is still convenient to have the
> property for constraining.
> Otherwise you don't have a way to say in an archetype: I don't care about
> the exact unit here, but please let it be a "Mass".
>
> -Ursprüngliche Nachricht-
> Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> Im Auftrag von Thomas Beale
> Gesendet: Freitag, 26. Januar 2018 09:13
> An: openehr-technical@lists.openehr.org
> Betreff: Re: Quantities of arbitrary units in openEHR
>
> Right - at the moment, it is a 'fake' field in archetypes, enabled by
> being in the BMM or other expression of the RM. It's convenient to do this
> occasionally, since we don't think 'property' needs to be a field of
> DV_QUANTITY - but maybe it should be, since for some of the more esoteric
> units, it's not that clear what is being measured.
>
> This trick is also not mentioned in the ADL/AOM specs, and it either
> should be, or we just don't allow it. I don't have a strong opinion either
> way.
>
> - thomas
>
>
> On 26/01/2018 07:51, Pieter Bos wrote:
> > A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification,
> > there is no property attribute or function present in dv_quantity,
> > even though the text says it can be conveniently constrained. There is
> > a reference to the spec-95 jira issue, which says it has been removed.
> > So there’s no way to constrain it - unless the specification contains
> > a mistake :)
> >
> > It is present in the BMM variants of the RM though, as a mandatory field.
> >
> > Regards,
> >
> > Pieter Bos
> >
>
>
> ___
> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

2017-11-30 Thread Diego Boscá
underscore it is then! :D

2017-11-30 9:09 GMT-03:00 Pieter Bos <pieter@nedap.com>:

> The test package is called “test_pkg” at least in adl2 – so underscores
> are supported.
>
> Pieter
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Diego Boscá <yamp...@gmail.com>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Thursday, 30 November 2017 at 13:06
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: Extract archetypes
>
> Having said that, I'm not sure current regex for archetype ids allows the
> use of spaces or undescores on the rm part. I'll have to check that
>
> 2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com<mailto:yamp
> e...@gmail.com>>:
> Hi Bert,
> I would say that the "rm name" would be "EHR_Extract", as it is the way
> the package is called in the documentation http://www.openehr.org/
> releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that
> demographics and EHR are the other package names).
> After that you would put the corresponding class name to constraint
> Regards
>
> 2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl ert.verh...@rosa.nl>>:
> Hi,
>
>
> Since that it is so that some extract-classes derive from Locatable, they
> can be used to use them as RM-class for an archetype-definition.
>
> But how would the ArchetypeId look like, special the rmName. Would it be
> something like openEHR-Extract-Extract ?
>
> Thanks in advance for answering
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org<mailto:openEHR-
> techni...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> --
>
> [eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>
>
> [witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  <
> https://htmlsig.com/t/01C4DPJG>  [aps]  <https://htmlsig.com/t/
> 01BZTWS7>
> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es<mailto:diebo...@veratech.es>
> yamp...@gmail.com<mailto:yamp...@gmail.com>
>
> VeraTech for Health SL
> +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023
> <tel:+34%20627%2001%2050%2023>
> www.veratech.es<http://www.veratech.es/>
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es<mailto:verat...@veratech.es>.
>
>
>
> --
>
> [eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>
>
> [witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  <
> https://htmlsig.com/t/01C4DPJG>  [aps]  <https://htmlsig.com/t/
> 01BZTWS7>
> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es<mailto:diebo...@veratech.es>
> yamp...@gmail.com<mailto:yamp...@gmail.com>
>
> VeraTech for Health SL
> +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023
> <tel:+34%20627%2001%2050%2023>
> www.veratech.es<http://www.veratech.es/>
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es<mailto:verat...@veratech.es>.
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2

Re: Extract archetypes

2017-11-30 Thread Diego Boscá
Having said that, I'm not sure current regex for archetype ids allows the
use of spaces or undescores on the rm part. I'll have to check that

2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com>:

> Hi Bert,
>
> I would say that the "rm name" would be "EHR_Extract", as it is the way
> the package is called in the documentation http://www.openehr.org/
> releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that
> demographics and EHR are the other package names).
>
> After that you would put the corresponding class name to constraint
>
> Regards
>
> 2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl>:
>
>> Hi,
>>
>>
>> Since that it is so that some extract-classes derive from Locatable, they
>> can be used to use them as RM-class for an archetype-definition.
>>
>> But how would the ArchetypeId look like, special the rmName. Would it be
>> something like openEHR-Extract-Extract ?
>>
>> Thanks in advance for answering
>>
>> Bert
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

2017-11-30 Thread Diego Boscá
Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is the way the
package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html
(notice that demographics and EHR are the other package names).

After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl>:

> Hi,
>
>
> Since that it is so that some extract-classes derive from Locatable, they
> can be used to use them as RM-class for an archetype-definition.
>
> But how would the ArchetypeId look like, special the rmName. Would it be
> something like openEHR-Extract-Extract ?
>
> Thanks in advance for answering
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

2017-11-13 Thread Diego Boscá
I think the first point is key:
I don't really see an scenario where your health data would be sent to an
untrusted source. But maybe in a future where we can envision an
"ebay-like" service of distributed medical services or something like that

2017-11-13 13:17 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> Not very far from now (looking into the future, Scotty and Captain Kirk),
> health information will be a worldwide web.
> Mayor players are diving into this trillion dollar business.
>
> Health information will need to be accessible, and blockchain can be used
> to guard all interaction between systems.
> You can find dozens of documents which handle about this.
>
> In the Netherlands Nictiz is busy with it.
>
> For example read this (sorry, only Dutch)
> https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/
> Blockchain_in_de_zorg.pdf
>
> Summarizing:
> - Blockchain is needed when interacting parties do not trust or know each
> other
> - A trusted third party cannot be found or is not desirable
> - Validity en transparency of transactions is important
> - Stored or interchanged data are very important
>
>
>
> On 13-11-17 13:02, Anastasiou A. wrote:
>
>> Perhaps an optional Blockchain capability could be added in the service
>> model, at points where an
>> "internal" system had to interface with one or more "external" systems.
>>
>> For example, you could provide access to a specific dataset and
>> blockchain calls that
>> modify its state.
>>
>> This would then also require the extension of the service model for
>> verifying certain actions
>> against the blockchain.
>>
>> Within the RM, there is the Feeder System Audit (
>> http://www.openehr.org/releases/RM/latest/docs/common/
>> common.html#_feeder_system_audit)
>>
>> It's a new concept, still needs use cases about it I think.
>>
>> All the best
>> Athanasios Anastasiou
>>
>>
>>
>>
>>
>>
>>
>> -Original Message-
>> From: openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org] On Behalf Of Bert Verhees
>> Sent: 13 November 2017 11:47
>> To: For openEHR technical discussions
>> Subject: Blockchain
>>
>> How are the plans about blockchain for OpenEhr? Is there any plan to
>> incorporate it in the standard, or is it regarded as a technical
>> implementers business?
>>
>> Bert
>>
>>
>> ___
>> 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
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Blockchain

2017-11-13 Thread Diego Boscá
Hi Bert,

Where do you want to apply it?

2017-11-13 12:46 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:

> How are the plans about blockchain for OpenEhr? Is there any plan to
> incorporate it in the standard, or is it regarded as a technical
> implementers business?
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Stackoverflow tag: openehr

2017-11-11 Thread Diego Boscá
Great! Good news

El 11 nov. 2017 3:56 p. m., "gjb"  escribió:

> Hi all,
> Today I created a tag on Stackoverflow for openEHR
> https://stackoverflow.com/questions/tagged/openehr
> For it to persist over time there needs to be sufficent level of activity
> involving openehr tagged questions.
>
> enjoy!
>
> Gavin Brelstaff
> CRS4 Sardinia
> https://stackoverflow.com/users/3507061/gavinbrelstaff
>
>
>
> ___
> 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: RE:

2017-10-30 Thread Diego Boscá
I can confirm all links work

2017-10-30 9:58 GMT+01:00 Seref Arikan <serefari...@kurumsalteknoloji.com>:

> Hi Wouter,
>
> I just checked, and it is working as far as I can see. It should be
> http://discovery.ucl.ac.uk/1500996/ Does this not work for you?
>
> On Mon, Oct 30, 2017 at 8:54 AM, Wouter Zanen <w.za...@eurotransplant.org>
> wrote:
>
>> Hi,
>>
>> The link to the full thesis on the openEHR website doesn't seem to work.
>>
>> Best regards,
>>
>> Wouter Zanen
>>
>>
>>
>> De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde en
>> kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit bericht
>> niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te
>> melden en het bericht (inclusief bijlagen) uit uw systeem te verwijderen.
>> Eurotransplant staat door de elektronische verzending van dit bericht niet
>> in voor de juiste en volledige overbrenging van de inhoud, noch voor
>> tijdige ontvangst daarvan. Voor informatie over Eurotransplant raadpleegt
>> u: www.eurotransplant.org.
>>
>>
>>
>> This message is intended for the addressee's eyes only and it may contain
>> confidential and/or personal information. If you are not the intended
>> recipient, you are hereby kindly requested to notify the sender and delete
>> this message (including attachments) from your system immediately. In view
>> of the electronic nature of this communication, Eurotransplant is neither
>> liable for the proper and complete transmission of the information
>> contained therein nor for any delay in its receipt. For information on
>> Eurotransplant please visit: www.eurotransplant.org
>>
>> >>> Rong Chen <rong.c...@cambio.se> 27/10/2017 14:37 >>>
>> Congratulations to both Seref and David. I look forward to reading the
>> full thesis.
>>
>> Regards,
>> Rong
>>
>> Rong Chen, MD PhD
>> Chief Medical Informatics Officer
>> +46 704 388 001
>>
>> *Cambio*+ Healthcare Systems AB
>> Stockholm:
>> Drottninggatan 89 SE-113 60 Stockholm
>> Vx: +46 8 691 49 00 <+46%208%20691%2049%2000> | Fax: +46 8 691 49 99
>> <+46%208%20691%2049%2099>
>> Linköping:
>> Universitetsvägen 14 SE-583 30 Linköping
>> Vx: +46 13 20 03 00 <+46%2013%2020%2003%2000> | Fax: +46 13 20 03 99
>> <+46%2013%2020%2003%2099>
>> Epost: i...@cambio.se  | Hemsida: www.cambio.se
>>
>> *From:* openEHR-clinical [mailto:openehr-clinical-bounc
>> e...@lists.openehr.org] *On Behalf Of *Ingram, David
>> *Sent:* den 27 oktober 2017 13:28
>> *To:* For openEHR clinical discussions (openehr-clinical@lists.openeh
>> r.org) <openehr-clini...@lists.openehr.org>; For openEHR technical
>> discussions <openehr-technical@lists.openehr.org>
>> *Subject:*
>>
>> *An implementation focused evaluation of openEHR and its integration with
>> Bayesian Belief Networks for clinical decision support*
>> One of my most persistent PhD students, Seref Arikan, has published his
>> ground-breaking PhD thesis on the UCL online repository.
>> A fuller announcement and link has been posted in the News Section of the
>> openEHR web site at:
>> http://openehr.org/news_events/community_news
>> We hope it will make a useful contribution to the ongoing international
>> advances in openEHR methodology.
>> David Ingram
>> Emeritus Professor of Health Informatics at UCL
>> President and Chairman of the Board of Governors of the openEHR
>> Foundation
>> Trustee of the OpenEyes Foundation Charity
>> Academic Board Member, the Planetearth Institute
>>
>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re:

2017-10-27 Thread Diego Boscá
Congratulations! This will make an intresting read! :D

2017-10-27 13:27 GMT+02:00 Ingram, David <d.ing...@ucl.ac.uk>:

> *An implementation focused evaluation of openEHR and its integration with
> Bayesian Belief Networks for clinical decision support*
>
> One of my most persistent PhD students, Seref Arikan, has published his
> ground-breaking PhD thesis on the UCL online repository.
>
> A fuller announcement and link has been posted in the News Section of the
> openEHR web site at:
>
> http://openehr.org/news_events/community_news
>
> We hope it will make a useful contribution to the ongoing international
> advances in openEHR methodology.
>
> David Ingram
>
> Emeritus Professor of Health Informatics at UCL
>
> President and Chairman of the Board of Governors of the openEHR Foundation
>
> Trustee of the OpenEyes Foundation Charity
>
> Academic Board Member, the Planetearth Institute
>
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Is 'Choice' datatype available in Archetype editor an OpenEHR standard

2017-09-22 Thread Diego Boscá
Hi Dileep,

Choice is not a data type per se, but a visual aid to tell you that at a
given place in the archetype you have defined more than one data type as a
valid option. In real patient data only one of the types will be present.

Regards

2017-09-22 13:14 GMT+02:00 Dileep V S <dil...@healthelife.in>:

> Hi,
> Archetype editor includes a datatype called "Choice'. This allows more
> than one data type(text & coded text for example) for the same node. Is
> this OpenEHR standard?
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113 <+91%2096328%2088113>
> a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: New interim release of ADL Workbench.

2017-09-20 Thread Diego Boscá
I was referring to the schema to the bmm model/format itself
:)

2017-09-20 14:29 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:

> Hi Diego,
>
> the latest versions are always in the reference-models Github repo
> <https://github.com/openEHR/reference-models>, if you mean the schemas
> for various RMs.
>
> - thomas
>
> On 20/09/2017 11:46, Diego Boscá wrote:
>
> Thomas,
>
> Do you have available lastest version of bmm "schema"?
>
> Regards
>
> 2017-09-20 12:31 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:
>
>>
>> I have released a new version of the ADL Workbench (build 2.0.6.2934
>> <https://openehr.atlassian.net/browse/AWBPR-64>) which fixes various
>> problems, including start-up problems (AWBPR-64
>> <https://openehr.atlassian.net/browse/AWBPR-64>)  caused by a bad BMM
>> schema that was included in the previous build.
>>
>> The above link is a 64-bit build for Windows (7, 8, 10 etc). We'll post a
>> Mac version as soon as possible.
>>
>> - thomas beale
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> _______
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: New interim release of ADL Workbench.

2017-09-20 Thread Diego Boscá
Thomas,

Do you have available lastest version of bmm "schema"?

Regards

2017-09-20 12:31 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:

>
> I have released a new version of the ADL Workbench (build 2.0.6.2934
> <https://openehr.atlassian.net/browse/AWBPR-64>) which fixes various
> problems, including start-up problems (AWBPR-64
> <https://openehr.atlassian.net/browse/AWBPR-64>)  caused by a bad BMM
> schema that was included in the previous build.
>
> The above link is a 64-bit build for Windows (7, 8, 10 etc). We'll post a
> Mac version as soon as possible.
>
> - thomas beale
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR related News: Ripple Foundation launches EtherCIS to the world of Healthcare

2017-07-27 Thread Diego Boscá
Congratulations Tony!
Impressive work, we'll have to test this. Videos look great!


2017-07-27 18:19 GMT+02:00 Tony Shannon <tony.shannon@ripple.foundation>:

> Dear openEHR Colleagues,
>
> At long last I'm pleased to announce some news to the openEHR community,
> which I hope you will find of interest/value to you.
>
> Those of you who know me, know I have been championing openEHR for quite
> some time, I believe it is key to the future of healthcare.
> You may also know that I have been an advocate for an open source
> implementation of openEHR in action for quite some time too.
>
> In my opinion if we want openEHR to truly transform the world of healthIT
> and healthcare, we need to make the related tools very easily available
> around the world.
>
> So, building on some great work began years ago with Seref Arikan
> (Opereffa) and aligned to the leading edge open source work of Pablo Pazos
> with Cabolabs EHRServer.
> I'm very pleased to announce the public release of EtherCIS, as an
> internationally leading open source example of the openEHR standard in
> action, including support for AQL.
> http://ripple.foundation/2017/07/ripple-foundation-launches-
> ethercis-world-healthcare/
>
> Over the last 2 years, the work to get EtherCIS to this point has been
> done within the context of a broad open platform push (begun out of Leeds
> in England).
> Initially known as the Ripple Open Source Initiative, the effort has since
> evolved to become the work of the non profit Ripple Foundation which I
> lead.
> http://ripple.foundation
>
> We have supported the development of EtherCIS in the context of developing
> and testing of a highly usable/open source "showcase stack", which we will
> share more details on later.
>
> For now I wanted to thank a few folk who have made this development
> possible,
> Of course the many many folk who have brought openEHR to the point that is
> already at... you know who you are , I know many of you as friends and
> again a word of thanks today.
> Dr Ian McNicoll who has helped with his usual good humoured leadership of
> the openEHR mission and supporting/overseeing the openEHR aspects to our
> work,
> Marand for their ongoing help with their openEHR EHRscape service which is
> a key part of our Ripple showcase.
> and last by by no means least..
> Christian Chevalley without whom , this world leading open source example
> of the openEHR standard in action would not have been possible.
>
> Christian may wish to say a few words about his work here shortly, but
> suffice to say Christian has put his heart and soul into this very valuable
> work and working with us to open source this work, has gifted something
> very useful to the world.
> I appreciate all he has done to make this public release of EtherCIS
> possible, which I believe to now be the leading open source example of
> openEHR in action.
>
>
> We believe that openEHR has been designed to support the needs of 21st
> Century Healthcare.
> We know openEHR is in action around the world and the change that is
> needed has begun.
> You may have seen some of our recent/related openEHR videos which we hope
> you like and hope you share. http://ripple.foundation/news/
>
> We believe the time has come for an open source implementation of openEHR
> in action to take openEHR to the next level, around the world.
> We wanted to share this news with the openEHR community to encourage you
> and your colleagues to review all of our work and EtherCIS in particular.
> We now invite you to review it, critique it, spread the word about it and
> help us improve it.
>
> We hope this news is of interest and value to your own work.
> EtherCIS has arrived..
> The time for openEHR is now...
>
> Kind Regards
>
> Tony
>
> Dr. Tony Shannon
> Director, Ripple Foundation   ripple.foundation
> tony.shannon@ripple.foundation
>
>
> ___
> openEHR-implementers mailing list
> openehr-implement...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya final

Re: Reports - a new openEHR RM type?

2017-05-31 Thread Diego Boscá
About "report":
Maybe we just need a subclass of Folder that contains a "Locatable" (0..*)
attribute. Shouldn't break things too much. Maybe going the FHIR way is
also feasible: Create a new class with a Folder and a container of
locatables that can be pointed by the Folder.

About questionnaire:
This was written on the wiki some time ago:
https://openehr.atlassian.net/wiki/display/healthmod/Questionnaires+and+openEHR
Also, I asked a similar question on the 'questions' parts of the wiki:
https://openehr.atlassian.net/wiki/questions/30900242/how-to-model-meta-archetypes

Regards



2017-05-31 6:54 GMT+02:00 Pablo Pazos <pablo.pa...@cabolabs.com>:

> Hi Thomas,
>
> Thinking about the hierarchy, at which level will be a Report be? Below
> compo? Below entry? Structure? Representation?
>
> OT: many asked me this and didn't had a good answer. Do we have a pattern
> to model questionnaires? Some require to define questions, and the answer
> type in most cases is boolean, or coded text (multiple choice), and answers
> might be 0..* (more than one answer for the same question is valid).
>
> Cheers,
> Pablo.
>
> On Tue, May 30, 2017 at 11:55 PM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>>
>> some of us have been looking at the idea that a 'report' should be a new
>> content type in openEHR, that can include other content of different types,
>> and in different ways.
>>
>> We have published a wiki page
>> <https://openehr.atlassian.net/wiki/display/spec/Reports> with the
>> initial notes on the idea, and a (possibly) novel approach to solving the
>> quoting/inclusion problem, which is to serialise included content into the
>> report. We think the report type (the name may need to be reconsidered)
>> would apply to discharge summaries, general summaries, referrals, and
>> possibly care plans.
>> Comments and reactions welcome on the wiki page or here.
>>
>> thanks
>>
>> - thomas
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica <http://www.arssemantica.com>
>> Consultant, ABD Team, Intermountain Healthcare
>> <https://intermountainhealthcare.org/>
>> Management Board, Specifications Program Lead, openEHR Foundation
>> <http://www.openehr.org>
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> <http://www.bcs.org/category/6044>
>> Health IT blog <http://wolandscat.net/> | Culture blog
>> <http://wolandsothercat.net/>
>>
>> ___
>> 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
> Cel:(00598) 99 043 145
> Skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> pablo.pa...@cabolabs.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
well, nothing stops you for not encoding the query in definition time, most
services are ok with that
e.g.

http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query=
<404684003:363698007=39057004

2017-05-03 16:31 GMT+02:00 Thomas Beale <thomas.be...@openehr.org>:

>
> On 03/05/2017 13:31, Diego Boscá wrote:
>
>> Or just use the "Long syntax" as described in point 5.2 from Expression
>> Constraint Language, which keeps things readable enough
>> http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|
>>
>>
> at the very least, a %20 is needed for the spaces, and %7C for the pipes,
> i.e.
>
> http://snomed.info/ecl/descendantOrSelfOf%2073211009%20%
> 7CDiabetes%20mellitus%7C
>
> i.e. ... not readable...
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
lay/SLPG/SNOMED+CT+URI+Standard>,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages>
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for expressions, so I guess it does
> not yet exist.
>
> Stupid.
>
> Bert
>
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
For the expression constraint language seems strange to encode the
characters when there is already an official expression constraint language
alternative that avoids these kinds of characters

2017-05-03 13:09 GMT+02:00 Daniel Karlsson <daniel.karls...@liu.se>:

> See this page:
> https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
> Please consider the language used when posting.
> /Daniel
>
> On May 3, 2017 13:03, Bert Verhees <bert.verh...@rosa.nl> wrote:
>
> On 03-05-17 12:53, Thomas Beale wrote:
>
> On 03/05/2017 11:40, Bert Verhees wrote:
>
> On 03-05-17 12:36, Thomas Beale wrote:
>
> The only missing part, now that I look at the SNOMED Compositional Grammar
> <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression
> Constraint Language <https://confluence.ihtsdotools.org/display/DOCECL>
> specs, is how to create a URI (which is the type of a term binding in ADL2
> <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
> from a post-coordinated expression or constraint expression. This should be
> trivial, but I don't see where SNOMED has specified it.
>
>
> True, I was looking for that also, a few days ago. I don't have time to
> read much now, but there is a document on the SNOMED site on URI's, maybe
> it is in there?
> I can take a look later or look in my documentation, I have course
> materials. I come back to this tomorrow if not someone else already has.
>
>
> The URI spec is here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages>
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for expressions, so I guess it does
> not yet exist.
>
> Stupid.
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-05-03 Thread Diego Boscá
Seems like the only way right now is creating refsets and referencing them
with standard URIs...

2017-05-03 13:02 GMT+02:00 Bert Verhees <bert.verh...@rosa.nl>:

> On 03-05-17 12:53, Thomas Beale wrote:
>
> On 03/05/2017 11:40, Bert Verhees wrote:
>
> On 03-05-17 12:36, Thomas Beale wrote:
>
> The only missing part, now that I look at the SNOMED Compositional Grammar
> <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression
> Constraint Language <https://confluence.ihtsdotools.org/display/DOCECL>
> specs, is how to create a URI (which is the type of a term binding in ADL2
> <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>)
> from a post-coordinated expression or constraint expression. This should be
> trivial, but I don't see where SNOMED has specified it.
>
>
> True, I was looking for that also, a few days ago. I don't have time to
> read much now, but there is a document on the SNOMED site on URI's, maybe
> it is in there?
> I can take a look later or look in my documentation, I have course
> materials. I come back to this tomorrow if not someone else already has.
>
>
> The URI spec is here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>,
> but it doesn't address URIs for expressions either.
>
> (All the SNOMED language specs appear to be here
> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages>
> these days - nice and convenient, and also nicely published. We probably
> should go back to linking to them somewhere on the openEHR site).
>
>
> I checked my course materials from last year, lucky I found it quickly,
> there is not any mentioning of URI's for expressions, so I guess it does
> not yet exist.
>
> Stupid.
>
> Bert
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-04-25 Thread Diego Boscá
But you probably need to define national extensions in constraint binding
in templates. Templates are archetypes in the end

2017-04-25 11:47 GMT+02:00 Bert Verhees <bert.verh...@rosa.nl>:

> On 25-04-17 09:50, Diego Boscá wrote:
>
>> I think having this in a hardcoded terminology list is probably far from
>> ideal (e.g. how do you put "snomed ct+norway national extension"? do we
>> need an exhaustive listing of all possible extensions/versions?)
>>
>
> When you use SNOMED in termbindings, you don't need to mention extensions,
> the code will do. But we need post coordinated expressions for the things
> which are not coded but still required to express in a SNOMED. At this
> moment, the ADL standard is not ready for that. I already made a JIRA entry
>
> When you need SNOMED in a terminology constraint, and you want to
> constrain to a subset, then it should be sufficient to use the code to that
> subset. The terminology service should be able to find out if it is a code
> to an entry, an hierarchy or a subset, and response appropriate.
>
> I am not sure about national extensions
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

2017-04-25 Thread Diego Boscá
This should be used as the name at least then

2017-04-25 10:08 GMT+02:00 <michael.law...@csiro.au>:

>
> There is a spec that tells you how to identify different editions and
> versions of SNOMED CT - see http://snomed.org/uri
>
> In short, http://snomed.info/sct is the identifier for any version of
> SNOMED CT.  for the Norway extension you need to know which module it is in
> (this is what will be used in the Module Dependency Reference Set for the
> Norway release) and then, if it was 12345668 for example, the identifier is
> http://snomed.info/sct/12345678
>
> Michael
>
> Sent from my iPhone
>
> On 25 Apr 2017, at 5:52 pm, Diego Boscá <yamp...@gmail.com> wrote:
>
> I think having this in a hardcoded terminology list is probably far from
> ideal (e.g. how do you put "snomed ct+norway national extension"? do we
> need an exhaustive listing of all possible extensions/versions?)
>
> 2017-04-25 8:03 GMT+02:00 Ian McNicoll <i...@freshehr.com>:
>
>> SNOMED-CT is the official designator, based on the archetype editor
>> terminology list.
>> On Tue, 25 Apr 2017 at 06:36, Pablo Pazos <pablo.pa...@cabolabs.com>
>> wrote:
>>
>>> Congratulations about the new adoption!
>>>
>>> The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
>>> specs we are using SNOMED-CT as the name (it should be corrected to the
>>> name preferred by the IHTSDO). On an event they explicitly asked to avoid
>>> the SNOMED-CT with the hyphen when referencing the standard.
>>>
>>> As for the term id, I've seen [snomed-ct::35917007 on the specs, or
>>> SNOMED-CT on sample archetypes: https://github.com/openEHR/spe
>>> cifications-ITS/search?utf8=%E2%9C%93=snomed=
>>>
>>> Tested on the Ocean's archetype editor and they use:
>>>
>>> constraint_bindings = <
>>> ["SNOMED-CT"] = <
>>> items = <
>>> ["ac0001"] = >> ?subset=cabolabs>
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss <b...@dips.no> wrote:
>>>
>>>> Norway just became a SNOMED country.
>>>>
>>>> One simple question – what is the correct terminologyId to use for
>>>> SNOMED-CT.
>>>>
>>>>
>>>>
>>>> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>>>>
>>>>
>>>>
>>>>  
>>>> Høyre øye
>>>> 
>>>>   
>>>> SNOMEDCT
>>>>   
>>>>   18944008
>>>> 
>>>>   
>>>>
>>>>
>>>>
>>>> Vennlig hilsen
>>>> Bjørn Næss
>>>> Produktansvarlig
>>>> DIPS ASA
>>>>
>>>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>>>>
>>>>
>>>>
>>>> ___
>>>>
>>> openEHR-implementers mailing list
>>>> openehr-implement...@lists.openehr.org
>>>> http://lists.openehr.org/mailman/listinfo/openehr-implemente
>>>> rs_lists.openehr.org
>>>>
>>>
>>>
>>>
>>> --
>>> Ing. Pablo Pazos Gutiérrez
>>> Cel:(00598) 99 043 145
>>> Skype: cabolabs
>>> <http://cabolabs.com/>
>>> http://www.cabolabs.com
>>> pablo.pa...@cabolabs.com
>>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>
>> --
>> Ian McNicoll
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Die

Re: SNOMEDCT - correct representation

2017-04-25 Thread Diego Boscá
I think having this in a hardcoded terminology list is probably far from
ideal (e.g. how do you put "snomed ct+norway national extension"? do we
need an exhaustive listing of all possible extensions/versions?)

2017-04-25 8:03 GMT+02:00 Ian McNicoll <i...@freshehr.com>:

> SNOMED-CT is the official designator, based on the archetype editor
> terminology list.
> On Tue, 25 Apr 2017 at 06:36, Pablo Pazos <pablo.pa...@cabolabs.com>
> wrote:
>
>> Congratulations about the new adoption!
>>
>> The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
>> specs we are using SNOMED-CT as the name (it should be corrected to the
>> name preferred by the IHTSDO). On an event they explicitly asked to avoid
>> the SNOMED-CT with the hyphen when referencing the standard.
>>
>> As for the term id, I've seen [snomed-ct::35917007 on the specs, or
>> SNOMED-CT on sample archetypes: https://github.com/openEHR/
>> specifications-ITS/search?utf8=%E2%9C%93=snomed=
>>
>> Tested on the Ocean's archetype editor and they use:
>>
>> constraint_bindings = <
>> ["SNOMED-CT"] = <
>> items = <
>> ["ac0001"] = <terminology:SNOMED-CT/
>> release?subset=cabolabs>
>> >
>> >
>> >
>>
>>
>>
>> On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss <b...@dips.no> wrote:
>>
>>> Norway just became a SNOMED country.
>>>
>>> One simple question – what is the correct terminologyId to use for
>>> SNOMED-CT.
>>>
>>>
>>>
>>> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>>>
>>>
>>>
>>>  
>>> Høyre øye
>>> 
>>>   
>>> SNOMEDCT
>>>   
>>>   18944008
>>> 
>>>   
>>>
>>>
>>>
>>> Vennlig hilsen
>>> Bjørn Næss
>>> Produktansvarlig
>>> DIPS ASA
>>>
>>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>>>
>>>
>>>
>>> ___
>>>
>> openEHR-implementers mailing list
>>> openehr-implement...@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> implementers_lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> Cel:(00598) 99 043 145
>> Skype: cabolabs
>> <http://cabolabs.com/>
>> http://www.cabolabs.com
>> pablo.pa...@cabolabs.com
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
> --
> Ian McNicoll
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Random / Synthetic Data Generation over Templates

2017-04-13 Thread Diego Boscá
Yeah, LinkEHR can do that

Regards

El 13/4/2017 17:37, "Anastasiou A."  escribió:

> Hello everyone
>
>
>
> I remember some time ago, there was a tool that given a detailed template
> description, it would populate it with random data taking
> into account only knowledge about the datatype.
>
>
>
> I vaguely remember Heather Leslie mentioningit but I may be wrong.
>
>
>
> Is that functionality available from one of Ocean’s tools? (e.g. the
> Template Designer)
>
>
>
> Is similar functionality available through other tools? (e.g. LinkEHR,
> other).
>
>
>
> Looking forward to hearing from you
>
> Athanasios Anastasiou
>
>
>
>
>
> ___
> 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: Hand coding templates in ADL 1.4

2017-02-12 Thread Diego Boscá
Hello Dileep,

If you stick with ADL 1.4 then you could use LinkEHR Studio (
http://linkehr.com) to create templates from other RM such as demographic
model. The same tool can be used to import OET and export OPT for any given
RM.

Regards

El 12/2/2017 9:44, "Dileep V S"  escribió:

Hi,

We are exploring OpenEHR as part of a public health management pilot
project in India and have some questions that I am unable to find proper
answers.

After studying the available libraries, tools and opensource server
implementations, ADL 1.4 seems to be more widely supported than the newer
ADL 2.0. The shared archetype repository (CKM) still contains only 1.4
version archetypes. In light of this, I am assuming that for anybody
planning to adopt OpenEHR, it will be advisable to stick to ADL1.4 for now.

Further I have learned the following wrt. ADL 1.4 standards

File formats for 1.4 version

   - Archetypes  - ADL 1.4
   - Templates - OET
   - Operational template - OPT 1.4

Modelling tools - Archetype editor, template designer

I am stuck with trying to answer the following questions. It would be great
if somebody can help.

   1. Can we hand create templates that are not supported by the template
   designer? For example demographics?
   2. If yes how do we convert the hand coded OETs to OPTs?
   3. Where do we get more details on OET file syntax?

Thanks

Dileep
HealtheLife Ventures LLP
bamgalore

___
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: Runtime name suggestions?

2017-01-17 Thread Diego Boscá
I believe linkEHR supports this, and you can export the archetype to be
fully compatible with AD and TD

2017-01-17 13:46 GMT+01:00 Ian McNicoll :

> ITEM_TREE[at0001] matches { -- Tree
> items cardinality matches {1..*; unordered} matches {
> CLUSTER[at0009] occurrences matches {0..1} matches { -- Flavour
> name matches {
> DV_TEXT matches {*}
> DV_CODED_TEXT matches {
> defining_code matches {
> [local::
> at0010, -- asdasd
> at0011] -- asdasda
> }
> }
> }
> 
>
> The main issue is that though the the Archetype Editor will read that
> construct, it loses the internal codes if the archetype is changed i.e it
> does not write the data back out again.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> 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 17 January 2017 at 12:36, Thomas Beale 
> wrote:
>
>>
>> It should be the same as for ADL2 except of course, stick to using the
>> correct at-codes, i.e. 'at0004' etc, rather than id-codes. SO I think the
>> example from the ADL 2 spec is pretty close to the one you want, with
>> at-codes, and terminal constraints they way you want.
>>
>> definition
>> ...
>> name ∈ {
>> DV_CODED_TEXT[id79] ∈ {
>> defining_code ∈ {[ac1]}
>> }
>> DV_TEXT[id14] ∈ {
>> value ∈ {/.+/} -- non-empty string
>> }
>> }
>> ...
>> terminology
>> ...
>> term_bindings = <
>> ["snomed_ct"]= <
>> ["ac1"] =  -- any SNOMED CT code
>> >
>> >
>>
>>
>> - thomas
>>
>> On 17/01/2017 11:23, Bakke, Silje Ljosland wrote:
>>
>> Thanks! If I knew the syntax I could hack the ADL and test how TD handles
>> it. J
>>
>>
>>
>> Regards,
>> *Silje*
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org ] *On
>> Behalf Of *Ian McNicoll
>> *Sent:* Tuesday, January 17, 2017 12:17 PM
>> *To:* For openEHR technical discussions > hr.org> 
>> *Subject:* Re: Runtime name suggestions?
>>
>>
>>
>> Hi Silje
>>
>> As Thomas has noted, it is possible in adl but is not supported in
>> archetype editor. That is probably fixable but I'm not sure currently how
>> template designer would handle it.
>>
>> Ian
>>
>> On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland <
>> silje.ljosland.ba...@nasjonalikt.no> wrote:
>>
>>
>>
>> ___
>> 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: Better approach for announcements, forums?

2016-12-30 Thread Diego Boscá
I'm pretty sure discord can notify you by email of every post or even
mention you have in your subscribed channels

El 30/12/2016 12:27, "Karsten Hilbert"  escribió:

> On Fri, Dec 30, 2016 at 12:16:25PM +0200, Pekka Pesola wrote:
>
> > I agree - moving to some kind of a forum would in overall work much
> better
> > than mailing lists.
>
> Certainly not. Lists are get/select, forums are go/browse.
>
> Many people don't have time to waste for going browsing.
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ___
> 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: Could the specs group consider making uid mandatory?

2016-12-19 Thread Diego Boscá
I believe that ISO 13606 renewal has proposed uuid to be made optional, but
they are still there

El 18/12/2016 23:23, "Heath Frankel" 
escribió:

> I think it should be a strong recommendation rather than mandatory
> considering it is currently optional and the need for backward
> compatibility.
> I also think it maybe difficult to apply consistently in some cases such
> as feeder data. There are cases in CDA profiles where there are mandatory
> IDs and you have to populate it with something but then need to some how
> retain this same ID over revisions etc.
> I also think a uri should be an allowed type of UID to support ids that
> are not guids and possibly associated with real world ids such as lab
> result ids, etc.
>
> Regards
>
> Heath
>
>
>
>
> On Mon, Dec 19, 2016 at 8:35 AM +1030, "Thomas Beale" <
> thomas.be...@openehr.org> wrote:
>
>
>> I also think that would be a good idea, since ENTRY = clinical
>> statement. We could make it an openEHR rule.
>>
>> - thomas
>>
>>
>> On 14/12/2016 00:24, Ian McNicoll wrote:
>> > There may be some advantages in routine application of uid at ENTRY level.
>> >
>> > Ian
>> > Dr Ian McNicoll
>> > mobile +44 (0)775 209 7859 <+44%207752%20097859>
>> > office +44 (0)1536 414994 <+44%201536%20414994>
>> > skype: ianmcnicoll
>> > email: i...@freshehr.com
>> > twitter: @ianmcnicoll
>> >
>> >
>>
>>
>> ___
>> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

  1   2   3   4   >