Re: definition of custom fields in archetypes

[Ian McNicoll]

Hi Georg,

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

Ian

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



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


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

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

Re: API for adding data to an EHR

[Ian McNicoll]

That's worth saying Pablo. It is a common misunderstanding. Similarly there
are no archetypes in openehr instance data. Only patterns of data that are
valid against the archetype designs.

For no technical people we have been describing templates as recipes, with
archetypes as recipe components like a sauce which has its own recipe.

Thankfully my food recipes do not validate my cooking.

Ian

On Sat, 28 Sep 2019, 01:12 Pablo Pazos,  wrote:

> For the record: there is no concept of "instance of a template", there are
> instances of COMPOSITIONs that comply with a template. The information
> model class is COMPOSITION, the constraints to which instances of
> COMPOSITION should comply are defined in a template.
>
> On Fri, Sep 27, 2019 at 11:25 AM Georg Fette 
> wrote:
>
>> ah, cool, that was what I was looking for. Thank you
>>
>> Am 27.09.2019 um 13:52 schrieb Georg Fette:
>> > Hello,
>> > In which part of the openEHR API is the definition of how to add an
>> > instance of a template to an existing EHR ?
>> > Something like "add  to > > EHR>" ?
>> > 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
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter 
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: schema of .oet xml templates

[Ian McNicoll]

Hi Georg,

The .oet is a design-time format which underpins the Ocean Template
Designer tool. You should always regard the .opt format that is generated
as the AOM-compliant output, not the .oet which does some arbitrary stuff
under the hood for internal reasons.

Ian

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



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


On Thu, 19 Sep 2019 at 10:04, Georg Fette 
wrote:

> Hello,
> In the international CKM in the template "Demo with hide-on-form.oet"
> there is a tag named "activityDescription". I thought that only a fixed
> set of tags (e.g. "Content", "Item", "Rule") are allowed in template
> definitions. This tag looks like is a field name of the archetypes
> "openEHR-EHR-INSTRUCTION.imaging.v1". If arbitrary field names are
> allowed in template definitions, can there be at all a fixed template
> xml schema definition ?
> 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: usage of templates in AQL

[Ian McNicoll]

There are a bunch of AQL examples at

https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings

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



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


On Tue, 17 Sep 2019 at 14:56, Ian McNicoll  wrote:

> Yes that works. It is also common to use the name/value attribute of the
> Composition root to identify a specific composition.
> Normally the name/value attribute of a templated Composition defaults to
> the underlying Composition archetype croot concept name e.g 'Bericht' but
> it can be renamed at template level and then queried
>
> select a
> from EHR e contains COMPOSITION a
> where a/name/value ='My local composition name'
>
> I have tended to use name/value but am coming round to using the templateId - 
> both are valid.
>
> Ian
>
>
>
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> Director, freshEHR Clinical Informatics Ltd.
> CCIO inidus Ltd. i...@inidus.com
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Tue, 17 Sep 2019 at 12:44, Georg Fette 
> wrote:
>
>> Hi Ian,
>> Sorry, I did not mean specifically imaging data.
>> What I meant was that all our templates are based on the archetype
>> openEHR-EHR-COMPOSITION.report.v1.
>> My question therefore was, if the only possibility to retrieve all data
>> for a specific template type is by querying with something you described:
>>
>> select a
>> from EHR e contains COMPOSITION a
>> where a/archetype_details/template_id/value ='My lovely template'
>>
>> 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: usage of templates in AQL

[Ian McNicoll]

Yes that works. It is also common to use the name/value attribute of the
Composition root to identify a specific composition.
Normally the name/value attribute of a templated Composition defaults to
the underlying Composition archetype croot concept name e.g 'Bericht' but
it can be renamed at template level and then queried

select a
from EHR e contains COMPOSITION a
where a/name/value ='My local composition name'

I have tended to use name/value but am coming round to using the
templateId - both are valid.

Ian






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



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


On Tue, 17 Sep 2019 at 12:44, Georg Fette 
wrote:

> Hi Ian,
> Sorry, I did not mean specifically imaging data.
> What I meant was that all our templates are based on the archetype
> openEHR-EHR-COMPOSITION.report.v1.
> My question therefore was, if the only possibility to retrieve all data
> for a specific template type is by querying with something you described:
>
> select a
> from EHR e contains COMPOSITION a
> where a/archetype_details/template_id/value ='My lovely template'
>
> 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: usage of templates in AQL

[Ian McNicoll]

We are still working on Imaging but the current presumption is that we
would use a generic Imaging Result archetype
https://openehr.org/ckm/archetypes/1013.1.1494

which contains Examination result name and modality elements which we would
query on to find 'Echocardiography' data. The exact use of Examination name
and modality is likely to be somewhat dependent on local practice/
terminology use.

Ian

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



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


On Tue, 17 Sep 2019 at 11:54, Georg Fette 
wrote:

> Ah, I understand.
> I  just made the test to use the json_instance_generator of the CoboLabs
> openEHR Toolkit by creating an instance of one of my templates. The
> template name only appears in the archetype_details. The whole rest
> looks like a standard instance of the archetype the template is based on.
>
> When I have a system in which I have various templates for different
> kind of reports (e.g. echocardiography, anamnesis, etc.) and I would
> like to get all echocardiography data. Is it common practice to query
> using the archetype_details to identify the echocardiography reports,
> like you exemplified in your former answers ?
> 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: usage of templates in AQL

[Ian McNicoll]

Hi Georg,

You don't find the templates as such, you find compositions committed
against those templates definitions. Templates are just definitions of how
to aggregate archetypes to meet a specific use-case. It is the composition
instance that is committed and queried against. The data within that
instance is tagged to show which archetype was used to define the data
structure, and which overall template was used, but you are not
really querying archetypes or templates, you are querying openEHR instance
data marked-up to show how those data structures were defined and arranged
- that mark-up is what allows you to use the template and archetypes to
figure out how to query the data.

Ian


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



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


On Tue, 17 Sep 2019 at 11:21, Georg Fette 
wrote:

> Thanks for the answers.
>
> Is a template apart from being a container which aggregates archetypes,
> a semi-definition or a derivation of an archetype ? The .oet template
> definitions always state a derivation from a an existing archetype
> (archetype_id="openEHR-EHR-COMPOSITION.report.v1"), and the type from
> which this archetype is inherited from (xsi:type="COMPOSITION").
> So when I query with AQL for this archetype I should find those
> templates, is that correct ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: usage of templates in AQL

[Ian McNicoll]

Hi Georg,

There is no direct connection between AQL and templates.

What do I need to know about the data model structures of the templates
potentially containing this archetype ?

Nothing - you can use the CONTAINS statement to find your candidate
archetype regardless of the enclosing composition/ template

When there are multiple templates that contain this archetypes, will
they all be found by this query, no matter where the archetype is
contained in their structure?

Yes, as above

How can I constrain my query so that I only get those of a specific
template ?

The templateID is carried in the parent composition (optionally though not
normally at entry level)

select a_a, a/name/value, a/archetype_details/template_id/value
from EHR e
contains COMPOSITION a
contains EVALUATION a_a[openEHR-EHR-EVALUATION.problem_diagnosis.v1]
where a/archetype_details/template_id/value ='My lovely template'

Do templates have to be specifically mentioned in the queries or are
they handled as if they were archetypes as well ?

No - you can ignore the templateId - templates are just 'design-time
recipes' - the name of the recipe ids carried in the
''archetype_details/template_id/value' attribute but otherwise this is just
pure archetypes.


How could I change my query so that (when I receive results from
different template types) that I also get the surrounding information in
which template my archetype has been found in

select a, a_a, a/name/value, a/archetype_details/template_id/value
from EHR e
contains COMPOSITION a
contains EVALUATION a_a[openEHR-EHR-EVALUATION.problem_diagnosis.v1]
where a/archetype_details/template_id/value ='My lovely template'

In that example 'a' will return the whole containing composition - you
probably do not want to do that but you get the idea.

Ian

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



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


On Mon, 16 Sep 2019 at 12:52, Georg Fette 
wrote:

> Hello,
> I have some question related to the coupling of AQL and templates:
> Imagine I want to write an AQL query containing a certain archetype and
> that archetype is used in multiple templates in the openEHR system.
> What do I need to know about the data model structures of the templates
> potentially containing this archetype ?
> When there are multiple templates that contain this archetypes, will
> they all be found by this query, no matter where the archetype is
> contained in their structure?
> How can I constrain my query so that I only get those of a specific
> template ?
> Do templates have to be specifically mentioned in the queries or are
> they handled as if they were archetypes as well ?
> How could I change my query so that (when I receive results from
> different template types) that I also get the surrounding information in
> which template my archetype has been found in ?
> 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: templates in .oet and .opt

[Ian McNicoll]

Agree with Pablo's description.

The Better Archetype Designer (AD) uses a new json format that takes the
place of the .oet and is closely aligned to ADL2. AD also imports and
exports .oet formats and exports .opt.

.opt is the critical 'technical' junction point from which most other
technical artefacts are derived - flattened data formats, server/ client
side validation, HTML visualisation, form rendering blah blah!

Once I have generated an .opt that is me handing the clinical models over
to the tech guys.

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



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


On Fri, 6 Sep 2019 at 15:11, Pablo Pazos  wrote:

> Hi, OET is the source format for templates on Ocean tools, that is the one
> that can be edited. Other tools might have a different source format or
> support the OET.
>
> The OPT is the final form, exported from different tools, like a big
> archetype for full documents. Depending on the tool, those can or can't be
> edited directly without the source format.
>
> Best,
> Pablo.
>
> On Fri, Sep 6, 2019 at 9:15 AM Georg Fette 
> wrote:
>
>> Hi,
>> I am not yet very familiar with templates and I only recently started
>> digging into the documentation.
>> One thing I encountered is the distiguishment between template (.oet)
>> and operational templates (.opt).
>> I played a bit using the oceans-toolbox and transformed some .oets into
>> .opts.
>> Although the oceans-toolbox seems not capable to reimport the exported
>> .opts, it looks like both representations can be transformed into the
>> other without loss of information. E.g. in the .opt some parts of the
>> archetypes can be set to 0..0, but they still exist if needed to
>> recreate the constrain that was used to model this 0..0 (which perhaps
>> formerly was a 0..1).
>> So my questions are:
>> - Are the two representation really bidirectionally transformable into
>> each other ?
>> - For which tasks is which representations mostly used for ? Is it
>> correct to say that the former is more appropriate for modeling purposes
>> and the latter more for technical processing.
>> Greetings
>> Georg
>>
>> --
>> -
>> Dipl.-Inf. Georg Fette  Raum: B001
>> Universität WürzburgTel.: +49-(0)931-31-85516
>> Am Hubland  Fax.: +49-(0)931-31-86732
>> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
>> -
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL for all specializations of an archetype

[Ian McNicoll]

I assume so, and possibly for specialisations. I would be a bit wary about
using it for different major versions of an archetype since by definition
at least some of the paths may have changed.

Ian

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



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


On Thu, 30 May 2019 at 12:37, Dileep V S  wrote:

> Thanks Ian,
>
> Can the wildcard(*) be used for different versions of the archetype also
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
> <http://ayushehr.com> e: dil...@healthelife.in
>
>
> On Thu, May 30, 2019 at 2:42 PM Ian McNicoll  wrote:
>
>> It should do - something like this works on ThinkEhr. I'm not sure if
>> other AQls support it
>>
>> SELECT o FROM EHR e CONTAINS ACTION a[openEHR-EHR-ACTION.procedure.v1]
>> CONTAINS OBSERVATION o[openEHR-EHR-CLUSTER.device-invasive*]
>>
>> Ian
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>>
>> Director, freshEHR Clinical Informatics Ltd.
>> CCIO inidus Ltd. i...@inidus.com
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Thu, 30 May 2019 at 09:57, Dileep V S  wrote:
>>
>>> Hi,
>>> Does AQL allow defining containment so that the basic archetype and all
>>> it's specializations can be included in the query? f yes can somebody share
>>> the syntax?
>>>
>>> regards
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
>>> <http://ayushehr.com> e: dil...@healthelife.in
>>> ___
>>> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL for all specializations of an archetype

[Ian McNicoll]

It should do - something like this works on ThinkEhr. I'm not sure if other
AQls support it

SELECT o FROM EHR e CONTAINS ACTION a[openEHR-EHR-ACTION.procedure.v1]
CONTAINS OBSERVATION o[openEHR-EHR-CLUSTER.device-invasive*]

Ian

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



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


On Thu, 30 May 2019 at 09:57, Dileep V S  wrote:

> Hi,
> Does AQL allow defining containment so that the basic archetype and all
> it's specializations can be included in the query? f yes can somebody share
> the syntax?
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
> <http://ayushehr.com> e: dil...@healthelife.in
> ___
> 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: Retrieving healthcare facility ID details using aql

[Ian McNicoll]

Hi Dileep

GERT /composition format=RAW

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 Fri, 17 May 2019 at 06:06, Dileep V S  wrote:

> Iam testing with Ethercis
> Thomas's pointers were very useful. However I tried all the following
> options and still getting error
>
> c/context/health_care_facility/identifiers/id/value as orgID
> c/context/health_care_facility/identifiers/id as orgID
> c/context/health_care_facility/identifiers/value as orgID
>
> I will try Ian's suggestion of getting the RAW JSON of the composition to
> try and figure out, but am not sure how to get the JSON file. Is there an
> API for this in Ethercis?
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
> <http://ayushehr.com> e: dil...@healthelife.in
>
>
> On Thu, May 16, 2019 at 8:14 PM Ian McNicoll  wrote:
>
>> I was about to say the same thing. The other helpful approach is just to
>> return the whole composition as a RAW JSON or XML file and see how the
>> paths work out - they will normally be very close tothintended AQL.
>>
>> Thomas's suggestion may be correct for Ethercis but I think that
>> Think!Ehr actually maps that FLAT JSON construct to  the external_ref in
>> PARRTY_IDENTIFED rather  then the identifiers attribute that is a PARTY_REF
>> class which has an id attribute which has a value attribute which is a
>> String
>>
>>
>> c/context/health_care_facility/external_ref/id/value as facilityId  should
>> work on ThinkEhr
>>
>> 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, 16 May 2019 at 13:07, Thomas Beale 
>> wrote:
>>
>>> Hi Dileep,
>>>
>>> Here the UML site is your friend. This is the part of the model
>>> <https://specifications.openehr.org/releases/UML/latest/#Diagrams___18_1_83e026d_1433773264253_175551_6601>you
>>> are referring to.
>>>
>>> Click through PARTY_IDENTIFIED and you will see that the relevant
>>> property is 'identifiers', not 'identifier'.
>>>
>>> Alternatively, see here in the RM Common IM spec
>>> <https://specifications.openehr.org/releases/RM/latest/common.html#_party_identified_class>
>>> .
>>>
>>> - thomas
>>> On 16/05/2019 13:00, Dileep V S wrote:
>>>
>>> Hi,
>>> I am committing the heatcare facility id context details n my
>>> compositions as below
>>>
>>> "clinical_notes/context/health_care_facility|id": "123456-123",
>>>
>>> "clinical_notes/context/health_care_facility|id_scheme": "UUID",
>>>
>>> "clinical_notes/context/health_care_facility|id_namespace": "EHR.NETWORK
>>> ",
>>>
>>> "clinical_notes/context/health_care_facility|name": "HealtheLife",
>>>
>>> Trying to retrieve this in aql using
>>>
>>> c/context/health_care_facility/id/value as orgID
>>> andc/context/health_care_facility/identifier/value as orgID
>>>
>>> both returns error "Could not interpret
>>> field:context/health_care_facility/identifier/value"
>>>
>>> What is the aql syntax to retrieve healthcare facility ID
>>>
>>> regards
>>>
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
>>> <http://ayushehr.com> e: dil...@healthelife.in
>>>
>>> ___
>>> openEHR-technical mailing 
>>> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lis

Re: Retrieving healthcare facility ID details using aql

[Ian McNicoll]

I was about to say the same thing. The other helpful approach is just to
return the whole composition as a RAW JSON or XML file and see how the
paths work out - they will normally be very close tothintended AQL.

Thomas's suggestion may be correct for Ethercis but I think that Think!Ehr
actually maps that FLAT JSON construct to  the external_ref in
PARRTY_IDENTIFED rather  then the identifiers attribute that is a PARTY_REF
class which has an id attribute which has a value attribute which is a
String


c/context/health_care_facility/external_ref/id/value as facilityId  should
work on ThinkEhr

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, 16 May 2019 at 13:07, Thomas Beale  wrote:

> Hi Dileep,
>
> Here the UML site is your friend. This is the part of the model
> <https://specifications.openehr.org/releases/UML/latest/#Diagrams___18_1_83e026d_1433773264253_175551_6601>you
> are referring to.
>
> Click through PARTY_IDENTIFIED and you will see that the relevant property
> is 'identifiers', not 'identifier'.
>
> Alternatively, see here in the RM Common IM spec
> <https://specifications.openehr.org/releases/RM/latest/common.html#_party_identified_class>
> .
>
> - thomas
> On 16/05/2019 13:00, Dileep V S wrote:
>
> Hi,
> I am committing the heatcare facility id context details n my compositions
> as below
>
> "clinical_notes/context/health_care_facility|id": "123456-123",
>
> "clinical_notes/context/health_care_facility|id_scheme": "UUID",
>
> "clinical_notes/context/health_care_facility|id_namespace": "EHR.NETWORK",
>
> "clinical_notes/context/health_care_facility|name": "HealtheLife",
>
> Trying to retrieve this in aql using
>
> c/context/health_care_facility/id/value as orgID
> andc/context/health_care_facility/identifier/value as orgID
>
> both returns error "Could not interpret
> field:context/health_care_facility/identifier/value"
>
> What is the aql syntax to retrieve healthcare facility ID
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
> <http://ayushehr.com> e: dil...@healthelife.in
>
> ___
> 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>
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Problem with Pulse/Heart beat archetype

[Ian McNicoll]

My guess is that you have not constrained the Runtime name constraint
(Rate) to be either Heart Rate or Pulse Rate in the template - you must
choose one or the other.

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, 16 May 2019 at 12:34, Dileep V S  wrote:

> Hi,
>
> The Pulse/Heart beat archetype from CKM,(
> https://www.openehr.org/ckm/archetypes/1013.1.170 ) when inserted into
> any template is giving error in Template designer (Node ID must not be
> null). Has any body faced this problem?
>
> I think the problemis with the newer updates as I had used the same a year
> back with out any problem.
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com
> <http://ayushehr.com> e: dil...@healthelife.in
> ___
> 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: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

Ah sorry. Yes that is incorrect.

On Thu, 2 May 2019, 12:13 Thomas Beale,  wrote:

> I'm confused... are you saying the value/value path is not a typo in the
> spec?
> On 02/05/2019 12:01, Ian McNicoll wrote:
>
> Thomas this is not a problem. The aql works as designed
>
> On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:
>
>> Georg,
>>
>> can you please raise a PR for this problem on the Jira PR tracker
>> <https://openehr.atlassian.net/projects/SPECPR/issues>?
>>
>> thanks
>> On 29/04/2019 22:49, Georg Fette wrote:
>>
>> Hello,
>> I have a problem with the interpretation of an AQL query from the AQL
>> documentation. In section 6.3 the path to the value of the systolic blood
>> pressure is
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
>> The first part until
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
>> denotes a DV_QUANTITY.
>> Where is the additional field 'value' of the type DV_QUANTITY defined ?
>> The class itself defines the fields 'magnitude', 'precision', 'units',
>> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
>> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
>> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
>> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
>> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
>> fields.
>> Has this field access to be 'magnitude' instead of 'value' or am I
>> missing something ?
>> Greetings
>> Georg
>>
>>
> ___
> 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: automatic demotion of lists in AQL ?

[Ian McNicoll]

Yes that at codes are always effectively namespaced by their parent
archetype.

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

Re: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

The replies that seref and I gave address the issue. The vast majority of
lab imports will use the generic analyte cluster.

On Thu, 2 May 2019, 12:01 Ian McNicoll,  wrote:

> Thomas this is not a problem. The aql works as designed
>
> On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:
>
>> Georg,
>>
>> can you please raise a PR for this problem on the Jira PR tracker
>> <https://openehr.atlassian.net/projects/SPECPR/issues>?
>>
>> thanks
>> On 29/04/2019 22:49, Georg Fette wrote:
>>
>> Hello,
>> I have a problem with the interpretation of an AQL query from the AQL
>> documentation. In section 6.3 the path to the value of the systolic blood
>> pressure is
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
>> The first part until
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
>> denotes a DV_QUANTITY.
>> Where is the additional field 'value' of the type DV_QUANTITY defined ?
>> The class itself defines the fields 'magnitude', 'precision', 'units',
>> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
>> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
>> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
>> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
>> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
>> fields.
>> Has this field access to be 'magnitude' instead of 'value' or am I
>> missing something ?
>> Greetings
>> Georg
>>
>> --
>> 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
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

Thomas this is not a problem. The aql works as designed

On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:

> Georg,
>
> can you please raise a PR for this problem on the Jira PR tracker
> ?
>
> thanks
> On 29/04/2019 22:49, Georg Fette wrote:
>
> Hello,
> I have a problem with the interpretation of an AQL query from the AQL
> documentation. In section 6.3 the path to the value of the systolic blood
> pressure is
> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
> The first part until
> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
> denotes a DV_QUANTITY.
> Where is the additional field 'value' of the type DV_QUANTITY defined ?
> The class itself defines the fields 'magnitude', 'precision', 'units',
> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
> fields.
> Has this field access to be 'magnitude' instead of 'value' or am I missing
> something ?
> Greetings
> Georg
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> 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: constraining of laboratory_test_analyte Analyte result

[Ian McNicoll]

Hi Georg

The instance data will actually have been subclassed to have a specific
datatype and therefore the relevant attributes.

Therefore if you know that a particular analyte is a quantity, you can use
aql to access the data just as if it had originally been modelled
specifically as a quantity.

If you do not know the datatype you should still be able to pull back the
whole element as an object and process it further after figuring out the
datatype.

I'll try to an example when I get to my laptop. Too hard on the phone.

Ian


On Mon, 29 Apr 2019, 23:46 Georg Fette, 
wrote:

> Hello,
> How do I constrain the Analyte result of a laboratory_test_analyte.v1 ?
> The Analyte result are defined as an ELEMENT that is only constrained by
> a node predicate (i.e. ELEMENT[at0001]). Therefore the results cannot be
> bound with a specialized type and an alias within the FROM part, as in
> the FROM part only archetypeID-predicates are allowed and no node
> predicates. As the result is defined with the abstract ELEMENT type,
> which has an abstract DATA_VALUE as its content, no paths can be defined
> that constrain specific aspects of subclasses of DATA_VALUE that are
> actually stored in the ELEMENT[at0001] field of the test_analyte.
> How can this problem be resolved ?
> 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: FHIR-like terminology 'binding strengths'?

[Ian McNicoll]

Hi Heath,

I agree with you, other than that use of required may be helpful for some
local archetypes, or for some safety-critical valuesets, so I would keep it
in. 'Example' has been useful for us in the UK, in that looking at the FHIR
resource examples, even though rejected, has given us a clearer idea of the
intended purpose of the node.  I think I also prefer the flat-list
instead of introducing boolean but will think about that a little more.

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 Tue, 16 Apr 2019 at 00:16, Heath Frankel <
heath.fran...@oceanhealthsystems.com> wrote:

> Hi Tom,
>
> I agree with Grahame, in over 20 years of implementing real systems, I
> don’t think I recall having seen one value-set that hasn’t been extended at
> some point when locally implemented. Even HL7 defined tables in V2 that
> were supposed to not be extended have been extended.
>
>
>
> There is a big difference between best-practice and reality and we don’t
> want to be putting any more barriers to adoption.
>
>
>
> To be honest, I am not sure that using required at an archetype level
> would be wise, it may be something that can be used at a template level.
>
>
>
> You could argue that preferred covers extensible and I agree that example
> may not be useful in models, but has proven to be useful as a guide for
> FHIR readers.
>
>
>
> Therefore, I think we still have Boolean option, either required or
> preferred/extensible/example.
>
>
>
> Having said that, using a Boolean doesn’t allow for us to support a valid
> use case in the future and I see some value in aligning with the FHIR
> options (if HL7 allow us to do that) even if we only support a subset.
>
>
>
> Regards
>
>
>
> Heath
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Grahame Grieve
> *Sent:* Tuesday, 16 April 2019 7:03 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: FHIR-like terminology 'binding strengths'?
>
>
>
> hi Tom
>
>
>
> We did not define extensible bindings because we like it. Using it creates
> many issues and it's problematic. We defined it because it's a very real
> world requirement, in spite of it's apparent 'unreliability'.
>
>
>
> The use cases arises naturally when
>
> - the approval cycle of changes to the value set is slower than
> operational requirements
>
> - the value set is large, and a community can only get partial agreement
> in the space. This is actually pretty common - typically, clinical code
> sets may need to contain 5000-5 concepts, but most of that is a very
> lng tail, and 95%+ of the use comes from 200-400 common codes. There's
> plenty of clinical communities investing time in requiring common agreed
> codes with fixed granularity for the head of the distribution.
>
>
>
> Neither of these things are an issue if openEHR is just targeting single
> application functionality. But as soon as the community that maintains the
> value set is wider than the users of a single system, then extensible
> bindings are inevitable.
>
>
>
> You can consider it bad... but that doesn't make it go away. Nor does it
> reduce the value of the agreements that do exist.
>
>
>
> Grahame
>
>
>
>
>
> On Tue, Apr 16, 2019 at 1:27 AM Thomas Beale 
> wrote:
>
> Last week, we had a workshop on ADL2 in Germany, to try to sort out a few
> issues on the way to making ADL2 mainstream in openEHR implementations. See
> here for the wiki page
> <https://openehr.atlassian.net/wiki/spaces/ADL/pages/382599192/ADL2%2BTooling%2BWorkshop%2B2019>
> .
>
> One of the issues discussed was on what basis terminology code constraints
> (value sets, generally) in archetypes (or templates) could be considered
> optional, recommended etc (discussion page here
> <https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007225/Local+Value-set+Replacement>).
> Some here will recognise this question as roughly the one that FHIR's
> 'binding strengths' <http://hl7.org/fhir/R4/terminologies.html#strength>
> tries to solve. I can understand two of the settings:
>
>- *required*: thou shalt use one of these here codes
>- *preferred*: we recommend these codes but you can use what you like
>
> I don't know how useful it is to put 'example' value sets in a content
> model, since there might be many possible examples, differing across the
> world. If there i

Re: Rules in archetypes - what are the requirements?

[Ian McNicoll]

Hi Pieter,

"But why would I need a function to calculate a score that is just a sum of
a number of values, instead of a few +-operators?"

It is an open question but one advantage of using the function approach,
with simple values is that it can encapsulate the algorithm without too
much dependency on understanding openEHR paths or path -bindings. That
should allow broader engagement with non-openEHR specialists.

My preference is to support use of openEHR datatypes within the expression
(albeit perhaps in reduced format), as otherwise passing units etc as
scalars starts to get cumbersome.

e.g

$apgar_heartrate, $apgar_breathing, $apgar_reflex, $apgar_muscle, $
apgar_colour)

where each of these is actually an ordinal, rather than a scalar value.

Not such a good example but think of a BMI calc, where the units used for
height and weight are critical
We can learn a lot from GDL experience in this regard.

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 Fri, 1 Feb 2019 at 14:53, Pieter Bos  wrote:

> About the calculation:
>
>
>
> Ah, I see, the assignment seems like a good solution. But why would I need
> a function to calculate a score that is just a sum of a number of values,
> instead of a few +-operators?
>
>
> Multiplicities/data binding:
>
> The there exists case is clear. However, what if I have four events, all
> having four elements, each with dv_quantity as value. Say I want the
> magnitude of the last of these quantities to be larger than the sum of the
> first three. Before I could write something like:
>
> for_all $event in /data/events[id3]
>  $event/data/items/element[id6]/value/magnitude >
> $event/data/items/element[id4]/value/magnitude +
> $event/data/items/element[id5]/value/magnitude +
> $event/data/items/element[id6]/value/magnitude
>
>
>
> (I omitted a few node ids here that are not important for the example)
>
> Not the most readable -  but it does the job. With data binding, how do I
> express this? There no longer seems to be a path lookup outside of data
> binding, so I can’t write:
>
> for_all $event in $events
>  $event/data/items/element[id6]/value/magnitude >
> $event/data/items/element[id4]/value/magnitude +
> $event/data/items/element[id5]/value/magnitude +
> $event/data/items/element[id6]/value/magnitude
>
>
>
> And binding all the separate paths to variables doesn’t work either – they
> will be bound as lists, and there is no way to iterate over four lists of
> values at once.
>
>
>
> Note that a path that points to a single typed dvquantity in an archetype
> can still point to many items in the RM if somewhere up the tree there is a
> list or a set, for example more than one observation. So if you really want
> them to be typed on validation time, you need to check every attribute in
> the path to see if it can point to more than one value, then either make it
> a List> or define in which order to add it as a single list.
>
> I implemented it by determining type at runtime, but it’s possible
> otherwise. This means that very often you need a for all statement, in
> which case data binding doesn’t really help. I defined some tricks with the
> basic operators also working on equally sized lists to make things a bit
> easier to understand for modelers. That’s why I asked about the execution
> rules. The tricks I did can be easily rewritten into for_all statements if
> we need to have them removed.
>
>
>
> This leads to more interesting cases when you flatten rules to an OPT 2
> template, to obtain a single artifact that can be used for many things,
> including rule evaluation. That is very doable right now by prepending some
> paths and adding some for_all statements. I’m not sure how to do that with
> data binding.
>
>
>
> Regards,
>
>
> Pieter Bos
>
>
>
> *From: *openEHR-technical 
> on behalf of Thomas Beale 
> *Reply-To: *For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Date: *Friday, 1 February 2019 at 14:16
> *To: *"openehr-technical@lists.openehr.org" <
> openehr-technical@lists.openehr.org>
> *Subject: *Re: Rules in archetypes - what are the requirements?
>
>
>
> Thanks Pieter,
>
> this is very useful.
>
> On 01/02/2019 12:54, Pieter Bos wrote:
>
> For us the main requirement of the rules is to calculate the value of
> other fields based on other fields. Only the checking of assertions has
> 

Re: DV_PROPORTION vs DV_QUANTITY for %

[Ian McNicoll]

Sorry - the reason is that O2% is also described as FIO2 which is directly
mathematically equivalent.

FiO₂
Proportion
Optional

Fraction of oxygen in inspired air.
Comment: For example: '0.28'.

Unitary

Numerator: 0.0..1.0
Percent O₂
Proportion
Optional
Percentage of oxygen in inspired air.
Comment: For example: '24 %'

Percent

Numerator: 0.0..100.0


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, 14 Jan 2019 at 12:08, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> 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
>
___
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 %

[Ian McNicoll]

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

Re: DV_PROPORTION vs DV_QUANTITY for %

[Ian McNicoll]

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.

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 12:02, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> I think maybe actual modelling practice should be taken into account here.
> Since these guidelines haven't been available, several important
> percentages in published archetypes have been modelled as DV_PROPORTION:
> openEHR-EHR-CLUSTER.inspired_oxygen.v1
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.393
> openEHR-EHR-OBSERVATION.pulse_oximetry.v1
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.3084
>
> The way I understand the arguments here, there isn't a good one for
> changing these data types and going to v2 for these archetypes?
>
> Regards,
> Silje
>
> -Original Message-
> From: openEHR-technical  On
> Behalf Of Thomas Beale
> Sent: Saturday, January 5, 2019 3:36 PM
> To: openehr-technical@lists.openehr.org
> Subject: Re: DV_PROPORTION vs DV_QUANTITY for %
>
>
> On 05/01/2019 12:56, Ian McNicoll wrote:
> > There is a very clear use-case for having it there - O2 levels
> > variably and equivalently described a FiO2 which is a unitary
> > proportion or percent.
> >
> > I think we need to keep it for that reason if no other.
>
> So in that case we need to upgrade the documentation for when to choose a
> DV_QUANTITY percent, and when a DV_PROPORTION %.
>
> - 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: DV_PROPORTION vs DV_QUANTITY for %

[Ian McNicoll]

There is a very clear use-case for having it there - O2 levels variably and
equivalently described a FiO2 which is a unitary proportion or percent.

I think we need to keep it for that reason if no other.

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, 5 Jan 2019 at 12:07, Thomas Beale  wrote:

> Hi Silje,
>
> See here
> <https://specifications.openehr.org/releases/RM/latest/data_types.html#_ratios_and_proportions>.
> But I think the % case may have been there since early 2000s and either %
> was not in UCUM, or perhaps it was, but we did not realise it. So ideally
> we should change the documentation to obsolete it in DV_PROPORTION.
>
> - thomas
> On 04/01/2019 20:40, Bakke, Silje Ljosland wrote:
>
> In that case, I don't understand the use case for the 'percent' and 'unitary' 
> variants of the DV_PROPORTION data type. What are they for?
>
> Regards,
> Silje
>
> -Original Message-
> From: openEHR-technical  
>  On Behalf Of Thomas Beale
> Sent: Friday, January 4, 2019 8:38 PM
> To: openehr-technical@lists.openehr.org
> Subject: Re: DV_PROPORTION vs DV_QUANTITY for %
>
>
> On 03/01/2019 08:37, David Moner wrote:
>
> 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."
>
> David is right on all counts - use DV_QUANTITY, but we should fix that line 
> in the specification. Can someone raise a PR on that please.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> 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
>
___
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 %

[Ian McNicoll]

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

Re: Coding the DV_IDENTIFIER 'type'

[Ian McNicoll]

Hi Silje,

You can't turn a string into a DV_TEXT but you can use something like a
namespace which is sort of hinted at in the description, which refers to
the type being structured

e.g "uk.gov/dvla/driving-licence"

I think this is actually a better solution than formal coding as most of
these types will be very local/national.

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, 20 Dec 2018 at 10:40, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi,
>
>
>
> In the documentation for the DV_IDENTIFIER data type (
> https://specifications.openehr.org/releases/RM/Release-1.0.3/data_types.html#_dv_identifier_class),
> the attribute ‘type’ is described as “Optional identifier type, such as
> prescription , or Social Security Number . *One day a controlled
> vocabulary might be possible for this.*” (my emphasis). Is it possible to
> code this at the moment, given that the data type for ‘type’ is String and
> not for example DV_TEXT?
>
>
>
> 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 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: Christmas cleaning of the openEHR wiki...

[Ian McNicoll]

Go for it. I trust you. A spruce up is a good start.

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 Wed, 19 Dec 2018 at 11:15, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi everyone,
>
>
>
> Sorry for the crossposting, but I thought this would concern everyone.
>
>
>
> I believe the openEHR wiki is an important documentation tool that has
> probably been a bit neglected(?). The default Confluence theme isn’t super
> pretty, and the site is difficult to navigate, in my opinion because of the
> large number of spaces and the lack of a proper front page for the site as
> a whole.
>
>
>
> I’d like to suggest reducing the number of spaces by
> removing/merging/archiving the spaces that are empty and/or abandoned.
> Those are:
>
>
>
> Effectively empty:
>
>- https://openehr.atlassian.net/wiki/spaces/healthcare (mostly empty
>pages, last edit in 2011)
>- https://openehr.atlassian.net/wiki/spaces/ds (Demo default
>Confluence space?)
>- https://openehr.atlassian.net/wiki/spaces/CQ
>- https://openehr.atlassian.net/wiki/spaces/WEB
>
>
>
> Apparently abandoned:
>
>- https://openehr.atlassian.net/wiki/spaces/ADL (last three edits 338,
>965 and 1631 days ago)
>- https://openehr.atlassian.net/wiki/spaces/CIMI (last activity in
>2015)
>- https://openehr.atlassian.net/wiki/spaces/edu (two pages, the most
>recent edited in 2012)
>- https://openehr.atlassian.net/wiki/spaces/ontol (only one page,
>edited in 2012)
>- https://openehr.atlassian.net/wiki/spaces/projects (last real
>contribution 720 days ago)
>- https://openehr.atlassian.net/wiki/spaces/stds (last real
>contribution 950 days ago)
>- https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)
>- https://openehr.atlassian.net/wiki/spaces/term (last activity 2014)
>- https://openehr.atlassian.net/wiki/spaces/oecom (last real
>contribution 805 days ago)
>
>
>
> I suggest the empty spaces are deleted, and the abandoned ones are
> archived.
>
>
>
> This will leave us with:
>
>- https://openehr.atlassian.net/wiki/spaces/dev
>- https://openehr.atlassian.net/wiki/spaces/healthmod
>- https://openehr.atlassian.net/wiki/spaces/resources
>- https://openehr.atlassian.net/wiki/spaces/spec
>
>
>
> …which in my opinion is a much more manageable selection of spaces.
>
>
>
> I’m not sure what to do about the look of the page though. Maybe making a
> simple front page for the entire wiki with links and short descriptions
> about each space would solve a lot for now?
>
>
>
> Thoughts?
>
>
>
> 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-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

Re: openEHR on FHIR and vice versa

[Ian McNicoll]

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 
> 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
>> 0653785650
>>
>>
>> Op vr 14 dec. 2018 om 11:49 schreef 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)

Re: ADL specification question

[Ian McNicoll]

I might just add that I am not aware of experienced clinical modellers ever
making use of cardinality constraints. It has just proven too hard for
people to get their head around, even when there are some potential uses
e.g expressing an XSD-type 'choice'.

There was also a known feature of the original Archetype Editor which
(correctly) incremented the cardinality minimal constraint whenever an item
within the container was made mandatory. However, it did not decrement the
cardinality constraint if a child item was subsequently made non-mandatory.
This is probably correct behaviour, since the intention of the modeller in
this case cannot be known but it has meant that cardinality minimal
constraints have appeared unintentionally.

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, 29 Nov 2018 at 10:54, Thomas Beale  wrote:

> Hi Georg,
>
> the other answers are right, but for reference you may want to read the
> relevant part of the ADL specification (ADL2 version
> <https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_constraints_on_complex_types>;
> ADL1.4 version
> <https://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_structure_3>).
> The main thing to understand is that 'cardinality' applies to container
> attributes, and that 'occurrences' defines how often an object node may
> appear in the data.
>
> The ADL2 version gives the clearer explanation, and the main semantics of
> cardinality and occurrences have not changed from one to the other.
>
> - thomas
> On 29/11/2018 10:09, Georg Fette wrote:
>
> --
>
> 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  ><http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>>
>
> >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
>
>
> --
> 

Re: Postcoordinated terminology expressions in openEHR

[Ian McNicoll]

Yes agree laterality is another potentially high value case.

They should probably talk to the CIMI folks. Stan Huff has a good an idea
as anyone of both the potential and pitfalls of complex terminology
handling. I suspect that really held CIMI back at a critical moment but at
least they have a good understanding of te challenges.

In spite of decades of attempts, I don't know of any national program that
is using post-coordination to any extent.

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, 19 Nov 2018 at 15:38, Thomas Beale  wrote:

> I mostly agree with Ian, but with the small caveat that for very specific
> and well-known cases such as body laterality, you just *might consider*
> post-coordination on body site e.g.
>
>- 56459004 |foot structure| : 272741003 |laterality| = 7771000 |left|)
>
> However, even here, laterality often seems to be divided out in various
> ways depending on what you are talking about. E.g. anything to do with
> eyes, the whole exam is per-eye rather than each finding being marked as
> being on the 'eye, left' or 'eye, right'. In other places, 'left' and
> 'right' don't even have symmetrical meanings e.g. the heart (think
> left-branch bundle etc).
>
> Nevertheless, for those body sites where findings are reported as being on
> some X+left or right, I think we probably should consider post-coordination
> of the site and the laterality at some point. For everything else, it's a
> nice idea but forget it in data models.
>
> Where it could be used is via a *mapping formula *for multiple data
> points, e.g. in an archetype. The archetype data would be defined populated
> as a structure (as today), but a 'post-coordination formula' that indicates
> how to bind the values of particular coded elements together to obtain a
> Snomed expression could be used to generate such expressions from the data,
> for consumption by inference engines. This is the only place where they can
> be usefully computed with, in my opinion.
>
> Such a formula might look like this:
>
>- 47933007 |$pain_finding| : 363698007 |finding_site| = (
>$finding_site: 272741003 |laterality| =  $laterality)
>
> where $pain_finding, $finding_site and $laterality are bound to paths in
> the archetype.
>
> If the formula were evaluated, it might give this:
>
>- 22253000 |pain| : 363698007 |finding site| = ( 56459004 |foot
>structure| : 272741003 |laterality| = 7771000 |left| )
>
> With minor adjustments in the binding part of the ADL2 grammar, such
> formula bindings could be accommodated fairly easily I would think.
>
> Note: this is speculation, and has never been tried as far as I know. Even
> if it does, it's only for SNOMED, unless the SNOMED model of
> post-coordinated expressions is adopted by other terminologies...
>
> - thomas
>
> On 19/11/2018 13:32, Ian McNicoll wrote:
>
> Basically - don't!!
>
> The UK has been trying to do this for over 20 years without success. It is
> a terminologists dream but implementers nightmare.
>
> Make a start with high-value use cases e.g Allergy agent "Allergic to +
> causative agent" - so that you do not have to generate a new Snomed code
> for every potential allergen.
>
> Perhaps consider laterality. Beyond that, you risk delaying SNOMED CT
> implementation, as has happened in the UK.
>
> Post-coordination is like nuclear fusion - a damned good idea but tricky
> to do without blowing everything up.
>
> Ian
> 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, 19 Nov 2018 at 13:20, Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no> wrote:
>
>> Hi everyone,
>>
>>
>>
>> We’ve recently started an informal and practically oriented regular
>> contact with the Norwegian SNOMED CT NRC. One of the things they were
>> interested in discussing was how to use postcoordinated SNOMED CT
>> (expression constraint language) expressions with openEHR, which I know
>> nothing about. Does anyone have any knowledge about or experience with this?
>>
>>
>>
>> Kind regards,
>> *Silje Ljosland Bakke*
>>
>>
>>
>> Information Architect, RN
>&

Re: Postcoordinated terminology expressions in openEHR

[Ian McNicoll]

Basically - don't!!

The UK has been trying to do this for over 20 years without success. It is
a terminologists dream but implementers nightmare.

Make a start with high-value use cases e.g Allergy agent "Allergic to +
causative agent" - so that you do not have to generate a new Snomed code
for every potential allergen.

Perhaps consider laterality. Beyond that, you risk delaying SNOMED CT
implementation, as has happened in the UK.

Post-coordination is like nuclear fusion - a damned good idea but tricky to
do without blowing everything up.

Ian
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, 19 Nov 2018 at 13:20, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi everyone,
>
>
>
> We’ve recently started an informal and practically oriented regular
> contact with the Norwegian SNOMED CT NRC. One of the things they were
> interested in discussing was how to use postcoordinated SNOMED CT
> (expression constraint language) expressions with openEHR, which I know
> nothing about. Does anyone have any knowledge about or experience with this?
>
>
>
> 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 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: AQL on versioned compositions

[Ian McNicoll]

Hi Dileep,

It should be possible to query on versioned compositions but I feel a bit
uncomfortable about using versioned data this way. For event-type
compositions, I would only expect versions to be created as a result of an
error correction, not as part of routine recording. For persistent-type
compositions, new versions are routinely created but only when the previous
version is reallyof little interest e.g summaries, status-tracking.

I'm uneasy about your suggested approach. Can you spell out an example/

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 Tue, 30 Oct 2018 at 08:45, Dileep V S  wrote:

> Hi,
> We are implementing virtual folders to organize compositions as per
> episodes of care and encounters. The plan is to keep track of versioned
> compositions in encounters to capture the change of information(Complaints
> and diagnosis getting resolved across encounters inside an episode).This
> will allow us to view the compositions as they were in any encounter and
> not the latest version always.
>
> For this we need to be able to query specific versions of compositions
> using aql. Can some body point me to the documentation or examples of how
> to do this?
>
> 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
>
___
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

[Ian McNicoll]

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, if annotations are used on a path like this, these annotations
>> would automatically be applied to both Requester and Receiver.
>>
>>
>>
>> For example, the path for BOTH the Requester and Receiver, once filled
>> with a service_request_information CLUSTER archetype is:
>>
>>
>> [openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]
>>
>>
>>
>> Is anybody already using this archetype (or a similar one) in their
>> systems and is encountering this issue? Is anybody using workarounds for
>> this?
>>
>> One way this issue could be avoided/dodged is if the archetype wraps
>> these slots in additional clusters, so that the resulting path is unique
>> even if the same archetype is used inside slots on the same level.
>>
>> It seems perfectly reasonable to me to construct archetypes the way this
>> one has b

Re: AW: Seeking clarification regarding Assumed value

[Ian McNicoll]

"It is still in ADL2, but harmless, so I would leave it in the specs and
advise tool developers to ignore it, if that is the consensus."

That would be my preference. Perhaps add a note to the specs explaining why
it is being deprecated (if others agree).

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 Tue, 9 Oct 2018 at 14:47, Thomas Beale  wrote:

> It is still in ADL2, but harmless, so I would leave it in the specs and
> advise tool developers to ignore it, if that is the consensus.
>
> - t
>
> On 09/10/2018 06:29, Sebastian Garde wrote:
>
> Assumed value was a slick idea at the time, but I do agree with your
> sentiments now:
>
>- it is hardly or not at all processable,
>- where there is widespread consensus on something it may well be
>assumed automatically by clinicians – but this is not because someone put
>the assumed value in the archetype or not.
>- Elements where such consensus exists across professions/sectors are
>probably rare anyway and universal consensus on an assumption is hard to
>ascertain
>- challenges for UI
>- challenges for querying (assuming you even dare)
>- challenges for anybody to understand it, including the difference to
>a default value (and what happens if there is both).
>
>
>
> Not sure about the implications for dropping/deprecating this at this stage
>
>
>
> Sebastian
>
>
>
>
> ___
> 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: Seeking clarification regarding Assumed value

[Ian McNicoll]

Thanks Sebastian,

You summarised my views much better than me.

As policy, I think we should stop using it for future archetypes, and
simply use the metadata to declare 'assumptions' where they make sense,
although I agree it is very risky to assert 'x' where data is simply
missing.

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 Tue, 9 Oct 2018 at 10:29, Sebastian Garde <
sebastian.ga...@oceaninformatics.com> wrote:

> Assumed value was a slick idea at the time, but I do agree with your
> sentiments now:
>
>- it is hardly or not at all processable,
>- where there is widespread consensus on something it may well be
>assumed automatically by clinicians – but this is not because someone put
>the assumed value in the archetype or not.
>- Elements where such consensus exists across professions/sectors are
>probably rare anyway and universal consensus on an assumption is hard to
>ascertain
>- challenges for UI
>- challenges for querying (assuming you even dare)
>- challenges for anybody to understand it, including the difference to
>a default value (and what happens if there is both).
>
>
>
> Not sure about the implications for dropping/deprecating this at this stage
>
>
>
> Sebastian
>
>
>
> *Von:* openEHR-technical  *Im
> Auftrag von *Ian McNicoll
> *Gesendet:* Montag, 8. Oktober 2018 14:43
> *An:* For openEHR clinical discussions  >
> *Cc:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Betreff:* Re: Seeking clarification regarding Assumed value
>
>
>
> I asked for this to be changed as we had dropped inspired oxygen into a
> cluster archetype (intended to sit in state and wanted to be able to state
> the assumed value of 23% (or whatever).
>
>
>
> I have come round to thinking that Assumed value is actually unhelpful. It
> is only a statement on the archetype and never ends up in the data, and
> completely non-processable. I think it can be easily misunderstood and is
> often very difficult to assert reliably. I would not be unhappy it see it
> dropped.
>
>
>
> We will however definitely need default values in specialisations e.g the
> lab series.
>
>
>
> Ian
>
>
>
>
>
> 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, 8 Oct 2018 at 13:23, Peter Gummer  wrote:
>
> > On 8 Oct 2018, at 23:09, Peter Gummer  wrote:
> >
> > ...Attached to this email is the CLUSTER that Ian attached to the Jira
> issue.
>
> Hmmm, I don’t think this mailing list accepts attachments. Here is the
> CLUSTER as ADL.
>
> Peter
>
>
> archetype (adl_version=1.4)
> openEHR-EHR-CLUSTER.ambient_oxygen.v1
>
> concept
> [at]-- Ambient oxygen
> language
> original_language = <[ISO_639-1::en]>
> translations = <
> ["de"] = <
> language = <[ISO_639-1::de]>
> author = <
> ["organisation"] = <"University of
> Heidelberg, Central Queensland University">
> ["name"] = <"Jasmin Buck, Sebastian Garde">
> >
> >
> >
> description
> original_author = <
> ["name"] = <"Ian McNicoll">
> ["organisation"] = <"Ocean Informatics">
> ["email"] = <"ian.mcnic...@oceaninformatics.com">
> ["date"] = <"08/06/2009">
> >
> details = <
> ["en"] = <
> language = <[ISO_639-1::en]>
> purpose = <"To record the amount of oxygen being
> delivered to the subject at the time of observation.  Assumed values of 21%
> O2, Fi02 of 0.21 and Oxygen flow rate of zero.">
> use = <"May be used with

Re: Seeking clarification regarding Assumed value

[Ian McNicoll]

I asked for this to be changed as we had dropped inspired oxygen into a
cluster archetype (intended to sit in state and wanted to be able to state
the assumed value of 23% (or whatever).

I have come round to thinking that Assumed value is actually unhelpful. It
is only a statement on the archetype and never ends up in the data, and
completely non-processable. I think it can be easily misunderstood and is
often very difficult to assert reliably. I would not be unhappy it see it
dropped.

We will however definitely need default values in specialisations e.g the
lab series.

Ian


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, 8 Oct 2018 at 13:23, Peter Gummer  wrote:

> > On 8 Oct 2018, at 23:09, Peter Gummer  wrote:
> >
> > ...Attached to this email is the CLUSTER that Ian attached to the Jira
> issue.
>
> Hmmm, I don’t think this mailing list accepts attachments. Here is the
> CLUSTER as ADL.
>
> Peter
>
>
> archetype (adl_version=1.4)
> openEHR-EHR-CLUSTER.ambient_oxygen.v1
>
> concept
> [at]-- Ambient oxygen
> language
> original_language = <[ISO_639-1::en]>
> translations = <
> ["de"] = <
> language = <[ISO_639-1::de]>
> author = <
> ["organisation"] = <"University of
> Heidelberg, Central Queensland University">
> ["name"] = <"Jasmin Buck, Sebastian Garde">
> >
> >
> >
> description
> original_author = <
> ["name"] = <"Ian McNicoll">
> ["organisation"] = <"Ocean Informatics">
> ["email"] = <"ian.mcnic...@oceaninformatics.com">
> ["date"] = <"08/06/2009">
> >
> details = <
> ["en"] = <
> language = <[ISO_639-1::en]>
> purpose = <"To record the amount of oxygen being
> delivered to the subject at the time of observation.  Assumed values of 21%
> O2, Fi02 of 0.21 and Oxygen flow rate of zero.">
> use = <"May be used within an ACTION archetype to
> specificy oxygen therapy , or within OBSERVATION archetypes such as Blood
> gases or Respirations, as part of patient state, where knowledge of ambient
> oxygen status is critical to interpretation of the observation.
>
>
> ">
> keywords = <"breathing", "oxygen">
> misuse = <"">
> copyright = <"copyright (c) 2009 openEHR
> Foundation">
> >
> >
> lifecycle_state = <"AuthorDraft">
> other_contributors = <"Heather Leslie Ocean Informatics",
> "Sebastian Garde Ocean Informatics", "Andrew James University of Toronto",
> "Sundarasan Jaganathan NHS Scotland", "Omer Hotomargolu Turkey", "Marja
> Buur Medisch Centrum Alkmaar Netherlands", "Gregory Caulton PatientOS
> Inc.", "Anne Harbison CPCER", "Sam Heard Ocean Informatics">
> other_details = <
> ["references"] = <"">
> ["MD5-CAM-1.0.1"] = <"1FCF286B5D47164C5D89907DF332BC65">
> >
>
> definition
> CLUSTER[at] matches {   -- Ambient oxygen
> items cardinality matches {0..*; unordered} matches {
> ELEMENT[at0051] occurrences matches {0..1} matches
> {-- Oxygen flow rate
> value matches {
> C_DV_QUANTITY <
> property = <[openehr::126]>
> list = <
> ["1"] = <
> units =
> <"l/m">
> magnitude
> = <|0.0..50.0|>
>

Re: DV_DURATION and magnitude_status?

[Ian McNicoll]

Hi Slije,

Duration *should* support magnitude_status - it is alreqady defined as such
in the RM. The issue is about how to archetype this, not represent in data.

However  I am not exactly sure if current CDRs support storing
magnitude_status for Duration. Suggest you give it a go!!

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 Tue, 25 Sep 2018 at 09:07, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Thanks for all your replies! 
>
>
>
> Attempt at summarising:
>
>- DV_DURATION doesn’t support <>=~ at the moment, but there’s some SEC
>work underway to fix this.
>- For now, using DV_QUANTITY with a property of time could do the
>trick.
>
>
>
> Is this a good summary?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Diego Boscá
> *Sent:* Tuesday, September 25, 2018 9:32 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: DV_DURATION and magnitude_status?
>
>
>
> 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
>
___
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?

[Ian McNicoll]

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

Re: DV_DURATION and magnitude_status?

[Ian McNicoll]

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

Re: Identifying archetype nodes in AQL via terminology code

[Ian McNicoll]

Hi Thomas,

Would it not at least in theory be possible to ignore the atCode? We can
already do searches that ignore archetype node Ids at a higher level. It
would be challenging to implement but I can certainly see some value.

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, 6 Sep 2018 at 09:42, Thomas Beale  wrote:

>
> In openEHR as it stands now, the answer would be no, because the
> snomed-ct:263495000 code is just one binding to at0017. What is reliable in
> the data is the at0017 internal code.
>
> In future, it is not out of the question that different types of OPTs
> would be generated that would treat bound terminology codes as if they were
> the structural ones, but this is probably a long way off. Some further
> ideas about this in the ADL2 spec
> <https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_terminology_integration>,
> and also the OPT2 spec
> <https://www.openehr.org/releases/AM/latest/OPT2.html>.
>
> It also might not be hard to preprocess AQL queries written like this into
> the standard form, but that would require that the code snomed-ct:263495000
> be bound uniquely to at0017, and no other node code e.g. at0015. So doing
> this would require stricter binding rules than we currently have, and which
> I think are not semantically justifiable.
>
> - thomas
>
> On 06/09/2018 09:21, Georg Fette wrote:
>
> Hello,
> In AQL it is possible to constrain the value of a node to one of the codes
> that are allowed for that value (as specified in the respective archetype).
> To find patients with gender (snomed-ct:248153007) male
> (snomed-ct:248153007) I could write something like this:
>
> SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
>
> WHERE d.items[at0017].value = 'snomed-ct:248153007'
>
>
> Is it possible to identify the node of an archetype instead of its path
> parts (e.g. d.gender or d.items[at0017]) also with a terminology code, so
> the query would rather look like something like that:
>
> SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
>
> WHERE d.items['snomed-ct:263495000'].value = 'snomed-ct:248153007'
>
>
> I am not very experienced with AQL so the queries are probably already
> syntactically wrong.
> Greetings
> Georg
>
>
> --
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Identifying archetype nodes in AQL via terminology code

[Ian McNicoll]

Hi Georg,

I'm about to slightly disagree with Birger (or at least clarify!!) but it
is taking me longer and I need to be offline for a bit!! Watch this space!

It is definitely possible to search on SNOMED terms both on the name and
value attributes of the Element. What is more tricky is using the
subsumption capablities of a terminology like  SNOMED *(which is what I
think Birger was saying). - that requires coordination between AQL and the
underlying terminology server. This has been done by individual
implementers but not in a generic way to date.

Back soon with more details!!


 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, 6 Sep 2018 at 09:21, Georg Fette 
wrote:

> Hello,
> In AQL it is possible to constrain the value of a node to one of the codes
> that are allowed for that value (as specified in the respective archetype).
> To find patients with gender (snomed-ct:248153007) male
> (snomed-ct:248153007) I could write something like this:
>
> SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
>
> WHERE d.items[at0017].value = 'snomed-ct:248153007'
>
>
> Is it possible to identify the node of an archetype instead of its path
> parts (e.g. d.gender or d.items[at0017]) also with a terminology code, so
> the query would rather look like something like that:
>
> SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
>
> WHERE d.items['snomed-ct:263495000'].value = 'snomed-ct:248153007'
>
>
> I am not very experienced with AQL so the queries are probably already
> syntactically wrong.
> 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: AQL on specific list of compositions

[Ian McNicoll]

Thanks Karsten,

Very helpful. I'd suggest one other minor tweak to differentiate 'episode'
which is one or more encounters associated with a particular problem or
issue, and 'period of care' which is administrative idea that
roughly equates to an admission or series of outpatient appointments. In
hospital care the two are often conflated.

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 18:42, Karsten Hilbert 
wrote:

> Thomas,
>
> sorry for the late reply.
>
> > Out of interest, is there a diagram or other GNUmed documentation /
> > explanation of all this. It's pretty close to what I think openEHR is or
> > should be doing; you have formalised more of this than we have so far, so
> > it's good to have some reference points available.
>
> Some details are in my head, but the big picture on the Wiki,
> say, in the User Guide:
>
> http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept
>
> The reason this aligns fairly well with the thinking
> in OpenEHR is that I've been following this list for
> far too long :-)
>
> Regards,
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Ian McNicoll]

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

Re: Recommended versioning strategy for Templates

[Ian McNicoll]

We have informally started to add major version number to our template
names. Our assumption is that major and minor changes to any component,
which are not constrained out, should bubble-up to the template. e.g if we
switched from blood_pressure.v1 to blood_pressure.v2 that would require a
template major change. OTOH if we went from blood_pressure.v1.1 -> 1.2 but
none of the 1.2 changes impacted the template we would not change the
template minor version.

Not sure if that is fully thought through but it follows the spirit of the
archetype id scheme, I think.

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 18:12, Pablo Pazos  wrote:

> In the EHRServer the implementation of queries allow to express a specific
> version of an archetype a.b.v1 or all versions a.b.*
>
> We don't use filters based on templates yet.
>
> Not sure how that is implemented in AQL but maybe there is a matches
> operation that can match a regex for any archetype version.
>
> On Sat, Sep 1, 2018 at 2:03 PM Thomas Beale 
> wrote:
>
>> Dileep,
>>
>> the Archetype Identification specification
>> <https://www.openehr.org/releases/AM/latest/Identification.html> may
>> provide some answers. It undoubtedly needs further development in this area.
>>
>> - thomas
>>
>> On 01/09/2018 15:04, Dileep V S wrote:
>>
>> Hi,
>>
>> As an EHR solution evolves, the templates also tend to evolve to an
>> acceptable level, especially since the archetypes themselves are evolving.
>> However, all the data recorded using different versions of the OPT should
>> remain consistently and easily query-able with out the AQL becoming overly
>> complex and difficult to manage.
>>
>> So is there any best practices in versioning the templates as they evolve
>> so that the incremental evolution does not break the AQLs. The question is
>> do we use the OPT filename(visually identifiable), Name filed in template
>> properties or any of the fields in authorship metadata for indicating the
>> template version?
>>
>> Secondly, is there any template best practices document?
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> *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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL support for an array of ehr_id

[Ian McNicoll]

It seems to work on Ethercis for this

{
"executedAQL": "SELECT e/ehr_id/value FROM EHR e WHERE e/ehr_id/value
matches { 'cd8abecd-9925-4313-86af-93aab4930eae' ,
'3a579ae0-0cbe-425b-9ac9-f15b83750481' }",
"resultSet": [
{
"ehr_id/value": "3a579ae0-0cbe-425b-9ac9-f15b83750481"
},
{
"ehr_id/value": "cd8abecd-9925-4313-86af-93aab4930eae"
    }
]
}

Certainly should be legal AQL .
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 Fri, 31 Aug 2018 at 17:44, Dileep V S  wrote:

> Dear Ian,
>
> Thanks. Is this part of the AQL spec or a feature that THinkEhr has
> implemented?
>
> Given the emerging importance of patient consent, given the GDPR and
> similar rules coming our across the world (DISHA in India), this may become
> a basic requirement in any EHR systems of the future. A static mapping of
> an EHR to the creator organization, as is normal in provider centric
> systems, may not be good enough.
>
> 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, Aug 30, 2018 at 11:11 PM, Ian McNicoll  wrote:
>
>> Hi Dileep - this is supported by THinkEhr...
>>
>> SELECT
>>e/ehr_id/value, a/data[at0001]/events[at0006]/time,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value --
>> diastolic
>>  FROM EHR e CONTAINS OBSERVATION
>> a[openEHR-EHR-OBSERVATION.blood_pressure.v1]
>> WHERE e/ehr_id/value MATCHES { 'e241715b-3ca7-435e-a474-718579aadaa2',
>> '0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1',
>> 'ed74f788-4bd6-4e47-ab98-211643cc4b0c'}
>>
>> 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, 30 Aug 2018 at 18:23, Dileep V S  wrote:
>>
>>> Hi,
>>>
>>> I am not sure if this has been asked before. I am asking again since I
>>> could not find an answer
>>>
>>> Does AQL support an array of EHRs? In AQL specs i can see examples to
>>> query any a single EHR and across all EHRs in the system. If I want to
>>> limit my query to a set of EHRs is it possible using AQL?
>>>
>>> Use case - As part of a dynamic consent management framework, we keep a
>>> dynamic mapping of EHRs to organizations. This is kept updated based on
>>> patient consent. So at any time a query is run by an organization, it
>>> should be limited to the EHRs that it has consent at that point of time.
>>>
>>> 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
>>>
>>
>> ___
>> 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: AQL on specific list of compositions

[Ian McNicoll]

Thanks Bjorn

That feels logical and the restriction to one layer of folders make sense.
I appreciate that under the hood 'CONTAINS' is implemented differently but
it feels natural to think in terms of logical containment.

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 Tue, 21 Aug 2018 at 08:54, Bjørn Næss  wrote:

> @ian – we have implemented the query you wrote:
>
>
>
> “select c from EHR e contains FOLDER f contains COMPOSITION c where c…..”
>
>
>
> You might even write:
>
>
>
> “select c from EHR e contains FOLDER f contains FOLDER child_folder
> contains COMPOSITION c where c…..”
>
>
>
>
>
> We made a restriction such that the COMPOSITION c MUST be referenced in
> FOLDER f and not any sub-folder. This was needed to avoid circular
> references and explosion in the result set.
>
>
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Product owner
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Ian McNicoll
> *Sent:* mandag 20. august 2018 11:22
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: AQL on specific list of compositions
>
>
>
> Yup but AQL is so cool for this kind of thing :)
>
> I still want to do
>
> Select c FROM EHR Contains folder x contains composition c
>
>
>
> since logically folder x contains compositions.
>
> 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, 20 Aug 2018 at 10:14, Thomas Beale 
> wrote:
>
> Well if you have access to a Folder, you don't need to do an AQL query,
> you can just retrieve the Folder structure and recurse through it,
> picking up direct refs to VERSIONED_COMPOSITIONs.
>
> Creating Folders from the data on the other hand requires writing some
> queries that look for admissions and discharges, matching them up, and
> generating a Folder for each pair, named after the institution and/or
> dates of the stay.  A bit messy, but not hard to do, if one wants to
> post hoc add Folders to 'old' EHRs that never had them.
>
> - thomas
>
>
> On 20/08/2018 10:07, Ian McNicoll wrote:
> > Thanks Thomas,
> >
> > What are your thoughts on the AQL example I foolishly guessed at :(
> > and that Seref quite correctly rejected!!
> >
> > How would/should we do...
> >
> > Select all compositions referenced by Folder x.
>
>
> ___
> 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: AQL on specific list of compositions

[Ian McNicoll]

Yup but AQL is so cool for this kind of thing :)

I still want to do

Select c FROM EHR Contains folder x contains composition c

since logically folder x contains compositions.

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, 20 Aug 2018 at 10:14, Thomas Beale  wrote:

> Well if you have access to a Folder, you don't need to do an AQL query,
> you can just retrieve the Folder structure and recurse through it,
> picking up direct refs to VERSIONED_COMPOSITIONs.
>
> Creating Folders from the data on the other hand requires writing some
> queries that look for admissions and discharges, matching them up, and
> generating a Folder for each pair, named after the institution and/or
> dates of the stay.  A bit messy, but not hard to do, if one wants to
> post hoc add Folders to 'old' EHRs that never had them.
>
> - thomas
>
>
> On 20/08/2018 10:07, Ian McNicoll wrote:
> > Thanks Thomas,
> >
> > What are your thoughts on the AQL example I foolishly guessed at :(
> > and that Seref quite correctly rejected!!
> >
> > How would/should we do...
> >
> > Select all compositions referenced by Folder x.
>
>
> ___
> 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: AQL on specific list of compositions

[Ian McNicoll]

@Gerard - I have always assumed that Contsys 'Health Issue' equates to
problem.

https://github.com/openehr-clinical/shn-contsys

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, 20 Aug 2018 at 10:04, Thomas Beale  wrote:

> Some of these Contsys definitions are problematic:
>
> On 20/08/2018 09:13, GF wrote:
>
> Hi Karsten,
>
> ISO System of Concepts for Continuity of Care (ContSys) defines all kinds
> of concepts related to care and its documentation.
> It would be. a good thing to harmonise terms we use.
> More info via: https://contsys.org
>
> ContSys is *NOT* a Data model but a way to define concepts and there
> relations using UML.
> It can/must inform the production of shared archetypes.
>
> ENCOUNTER
> Most certainly this is the case when a Healthcare Provider meets the
> patient and documents the care given.
> Meeting can be real and virtual via telephone, e-mail, a third party
>
> But there is an encounter when the HcP interacts with the EHR without a
> Patient (Virtually) present.
>
>
> that would certainly be a subversion of the usual meaning of 'encounter'
> (literally 'to meet') in English and all the latin languages at least...
> (in Portuguese and Brazil health system, the word is 'atendimento', i.e.
> attendance... - probably the same in Italian and Spanish).
>
> It would be better ontologically to call such an event something else - in
> openEHR it is a commit of a Contribution.
>
> There are also other health system actions with the patient absent, e.g.
> doing lab work on tissue samples - also real 'work', but not an encounter.
>
>
> So ENCOUNTER, in my terms, is any interaction of an Author (HcP, Patient,
> third Party/Proxy) with the Patient Record.
>
> The ISO standard System of Concepts for Continuity of Care uses the term
> and definition:
> *contact <https://contsys.org/concept/contact_period> perio
> <https://contsys.org/concept/contact_period>d- healthcare activity period
> <https://contsys.org/concept/healthcare_activity_period> during which
> a contact <https://contsys.org/concept/contact> occurs*
>
> EPISODE
> ContSys defines this as:
> *episode of care- health related period
> <https://contsys.org/concept/health_related_period> during which healthcare
> activities <https://contsys.org/concept/healthcare_activity> are performed
> to address one health issue <https://contsys.org/concept/health_issue> as
> identified by one healthcare
> <https://contsys.org/concept/healthcare>professional[*
>
>
> I would suggest that most people think an episode of care is not limited
> to one HCP, and is not always limited to one health issue, even if there is
> usually one main 'problem' on admission. An episode of care is usually
> thought of as care to resolve an issue for a patient by a team of HCPs
> working in an integrated environment, e.g. a hospital. If the resolution of
> the issue requires care that crosses institutions (usually the case), then
> a different term is probably needed for that.
>
> - thomas
>
> --
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Ian McNicoll]

Thanks Thomas,

What are your thoughts on the AQL example I foolishly guessed at :( and
that Seref quite correctly rejected!!

How would/should we do...

Select all compositions referenced by Folder x.

How else might we meet Dileep's use-case with AQL?


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, 17 Aug 2018 at 17:00, Thomas Beale  wrote:

>
> The easiest way to think about this question is: if someone trashed the
> Folder structure, could we (some admin app) rebuild it? The answer is
> interesting. It should normally be possible to rebuild the Folder /
> Composition association structure (it's not containment, just referencing),
> but of course, if you stored other information in the Folders, for example
> in the recently SEC-approved other_details structure, then you would lose
> that.
>
> So the Folder approach does two things:
>
>- represents a pre-built query result (the Folder/Composition
>associations) - giving instant access, and avoiding having to construct the
>query, which is usually somewhat messy.
>- allows other information to be stored directly about the thing the
>Folder represents, e.g. admission / stay in a facility.
>
> - thomas
>
> On 17/08/2018 16:20, Seref Arikan wrote:
>
> Hi Ian,
>
> When the fact that the Composition is associated to an encounter or
> episode of care is recorded by including a reference to that composition in
> a folder, some clinical context/information related to that composition is
> now stored outside the composition, by means of a refence in a folder
>
> Unless I'm missing an Aql feature that can help, you can no longer select
> those compositions via Aql (since Aql does not support/specify how to
> resolve refs)
>
> If you follow the encounter id approach you mentioned, then you could use
> Aql.
>
> In fact, if Ethercis had support for Folder, Dileep would still not be
> able to get those compositions with a singl query: he'd need to fetchs uids
> from a folder with one query, then perform a second query to get
> compositions in the way I suggested.
>
> I'm probably being unnecessarily picky here, just pointing at the
> difference between approaches and trying to put my finger on any downstream
> issues. I'm not doing a great job of it though :)
>
> On Friday, August 17, 2018, Ian McNicoll  wrote:
>
>> Hi Seref,
>>
>> I'm not sure I understand your concerns here. I think the use case is
>> where there is a need to group compositions by some other higher level
>> construct which usually reflect something like an admission, episode of
>> outpatient care or perhaps a community plan of care.
>>
>> As Dileep has indicated he probably would use folders if Ethercis
>> supported them. Another alternative is to create an Encounter ID for each
>> new encounter (which in Dileep's example, I think I would call an episode
>> of care, and simply tag each composition with that Encounter ID e.g create
>> a cluster archetype to hold this in every Composition/ other_context. I
>> have done that on other projects. So it is a case of looking of all
>> composition with EncounterId = x
>> Now I would probably go down the Folder route, if I could.
>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
>> serefari...@kurumsalteknoloji.com> wrote:
>>
>>> I'm used to thinking compositions as semantcally self contained units of
>>> information, at the very least using references to other means of
>>> expressing semantics (as in terminologies)
>>>
>>> What you're describing seems to take some clincal semantics out of the
>>> composion and if we have multiple ways of doing that, it may hurt
>>> reusability of queries and data.
>>>
>>> Do you think we can find a way of expressing this semantcs without
>>> losing its trace within the cmposition?
>>>
>>> (Sorry for the typos, on the phone..)
>>>
>>> On Friday, August 17, 2018, Thomas Beale 
>>> wrote:
>>>
>>>> There is a b

Re: AQL on specific list of compositions

[Ian McNicoll]

Hi Seref,

My understanding is that AQL can support FOLDER (assuming it is
implemented) with something like

Select c
FROM EHR e CONTAINS FOLDER f CONTAINS COMPOSITION c
Where folder f.name = "My lovely encounters"

but I may be wrong (both in principle and practice)

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 Fri, 17 Aug 2018 at 16:20, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Hi Ian,
>
> When the fact that the Composition is associated to an encounter or
> episode of care is recorded by including a reference to that composition in
> a folder, some clinical context/information related to that composition is
> now stored outside the composition, by means of a refence in a folder
>
> Unless I'm missing an Aql feature that can help, you can no longer select
> those compositions via Aql (since Aql does not support/specify how to
> resolve refs)
>
> If you follow the encounter id approach you mentioned, then you could use
> Aql.
>
> In fact, if Ethercis had support for Folder, Dileep would still not be
> able to get those compositions with a singl query: he'd need to fetchs uids
> from a folder with one query, then perform a second query to get
> compositions in the way I suggested.
>
> I'm probably being unnecessarily picky here, just pointing at the
> difference between approaches and trying to put my finger on any downstream
> issues. I'm not doing a great job of it though :)
>
> On Friday, August 17, 2018, Ian McNicoll  wrote:
>
>> Hi Seref,
>>
>> I'm not sure I understand your concerns here. I think the use case is
>> where there is a need to group compositions by some other higher level
>> construct which usually reflect something like an admission, episode of
>> outpatient care or perhaps a community plan of care.
>>
>> As Dileep has indicated he probably would use folders if Ethercis
>> supported them. Another alternative is to create an Encounter ID for each
>> new encounter (which in Dileep's example, I think I would call an episode
>> of care, and simply tag each composition with that Encounter ID e.g create
>> a cluster archetype to hold this in every Composition/ other_context. I
>> have done that on other projects. So it is a case of looking of all
>> composition with EncounterId = x
>> Now I would probably go down the Folder route, if I could.
>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
>> serefari...@kurumsalteknoloji.com> wrote:
>>
>>> I'm used to thinking compositions as semantcally self contained units of
>>> information, at the very least using references to other means of
>>> expressing semantics (as in terminologies)
>>>
>>> What you're describing seems to take some clincal semantics out of the
>>> composion and if we have multiple ways of doing that, it may hurt
>>> reusability of queries and data.
>>>
>>> Do you think we can find a way of expressing this semantcs without
>>> losing its trace within the cmposition?
>>>
>>> (Sorry for the typos, on the phone..)
>>>
>>> On Friday, August 17, 2018, Thomas Beale 
>>> wrote:
>>>
>>>> There is a bigger question of how best to model 'encounter' and
>>>> 'admission', which some implementers are doing with Folders, particularly
>>>> DIPS in Norway. I suspect that some version of using Folders (or else some
>>>> kind of tagging, which is semantically equivalent) will be the long term
>>>> approach to doing this.
>>>>
>>>> - thomas
>>>>
>>>> On 17/08/2018 10:54, Dileep V S wrote:
>>>>
>>>> Hi,
>>>>
>>>> Can you write an AQL to query only on a list of specific compositions?
>>>> Is there any sample for reference?
>>>>
>>>> I am trying to create the concept of clinical encounters and maintain a
>>>> collection of compositions per encounter. I am using AQL to retrieve data
>>>

Re: AQL on specific list of compositions

[Ian McNicoll]

Beat me to it :(

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 Fri, 17 Aug 2018 at 11:52, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Modifying Ian's example for a/uid/value and using uid values instead of
> names should do the trick
>
> On Friday, August 17, 2018, Dileep V S  wrote:
>
>> Thanks Ian,
>>
>> However my requirement is different. I seem to have confused you with the
>> way my question was framed.
>>
>> What I meant by composition ID was in fact Composition UID. I want to
>> query the same template (/name/value), but limited to specific commits
>> (compositionUIDs).
>>
>> I hope that helps
>>
>> 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 Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:
>>
>>> Hi Dileep,
>>>
>>> I do this by querying on the name attribute of the root composition
>>> archetype - see the examples in
>>>
>>>
>>> https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md
>>>
>>> You can of course query on multiple names.
>>>
>>> where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
>>>
>>> Going forward I would expect the list of allowable composition names to
>>> come from a controlled vocabulary or even a local terminology.
>>>
>>> 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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:
>>>
>>>> Hi,
>>>>
>>>> Can you write an AQL to query only on a list of specific compositions?
>>>> Is there any sample for reference?
>>>>
>>>> I am trying to create the concept of clinical encounters and maintain a
>>>> collection of compositions per encounter. I am using AQL to retrieve data
>>>> per encounter and need to pass the corresponding set of compositions.
>>>>
>>>> Thanks in advance
>>>>
>>>> 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
>>>>
>>>
>>> ___
>>> 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: AQL on specific list of compositions

[Ian McNicoll]

Hi Dileep,

I do this by querying on the name attribute of the root composition
archetype - see the examples in

https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md

You can of course query on multiple names.

where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}

Going forward I would expect the list of allowable composition names to
come from a controlled vocabulary or even a local terminology.

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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:

> Hi,
>
> Can you write an AQL to query only on a list of specific compositions? Is
> there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain a
> collection of compositions per encounter. I am using AQL to retrieve data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Drug dispense entry class question

[Ian McNicoll]

Hi Sam,

We modelled that as minor change (Active) / major change (Aborted) ,
without closely defining, what constiuted either...

Major change to order
Careflow step
A major change to the order was required, resulting in this order being
stopped and a replacement order being started.
Current state: aborted

Minor change to order
Careflow step
The medication order has been changed in a manner which does not require a
new instruction/order to be issued, according to local clinical rules.
Current state: active

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, 13 Aug 2018 at 13:45, Sam Heard 
wrote:

> Hi All
>
>
>
> There is the interesting situation as to what constitutes a stop/start and
> an amend for medication. Generally, if it is the same generic substance
> people will want to see it as an amend. This means they do not have to go
> through all the warnings and search again in the database. This is probably
> of no consequence from a data point of view, apart from the fact that you
> do not want to be warned that a patient has previously been on this
> medication (happens in our system).
>
>
>
> Cheers, Sam
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> --
> *From:* openEHR-technical 
> on behalf of Thomas Beale 
> *Sent:* Monday, August 13, 2018 9:07:18 PM
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: Drug dispense entry class question
>
>
>
> On 11/08/2018 20:50, Karsten Hilbert wrote:
> > On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote:
> >
> > I meant to say that some treatments will not end until the
> > patient dies meaning that the COMPLETED state will never be
> > reached if we take into account
>
> certainly true in theory, and maybe in reality. But drug treatments
> change and different variants may be tried over time - true even for
> basics like insulin - so at least for some chronic medication
> situations, it probably will be the case that one treatment finishes and
> another starts, based on a (?slightly) different order, with this
> repeating over time.
>
> - 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: Drug dispense entry class question

[Ian McNicoll]

Hi Pablo,

Yes. Sorry I misread your email but I think Karsten has helped you. We
regarded the dispense of a medication as part of the full medication
management cycle from initial order through to the patient being
administered the medication

It is possible to think of there being two parallel processes, as Gerard
has suggested.

1. The order -> administration of the medication to the patient
2. Physical Medication supply - prescription, authorisation, dispense,
refill

and we did consider using different archetypes for each but
after discussion and some practical experimentation decided to reflect
these as different pathway steps in the same archetype as in many health
systems, the separation is unclear.

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, 11 Aug 2018 at 20:52, Pablo Pazos  wrote:

>
>
> On Sat, Aug 11, 2018 at 4:50 PM, Karsten Hilbert 
> wrote:
>
>> On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote:
>>
>> > > > I'm inclined to think it as an ACTION if this task alters the state
>> of
>> > > the
>> > > > prescription INSTRUCTION ISM. On this case, as a parallel question,
>> I'm
>> > > not
>> > > > sure if the dispense ACTION should be a final "COMPLETED" state,
>> what
>> > > > happens if we want to record the patient's intake of the drug?
>> Where the
>> > > > real "COMPLETED" is when the treatment is finished.
>> > >
>> > > That might mean that some INSTRUCTIONs never get COMPLETED
>> > > until the patient dies.
>> > >
>> > >
>> > There is a state "EXPIRED", so that is covered IMO if an expiration
>> date is
>> > recorded, or even if the whole system has preconfigured expiration dates
>> > for drug treatments.
>>
>> I meant to say that some treatments will not end until the
>> patient dies meaning that the COMPLETED state will never be
>> reached if we take into account
>>
>
> Gotcha! Yes of course, chronic medication is never COMPLETED :)
>
>
>
>> >>> [...] the patient's intake of the drug [... where] the
>> >>> real "COMPLETED" is when the treatment is finished.
>>
>> Regards,
>> 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
>>
>
>
>
> --
> *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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Drug dispense entry class question

[Ian McNicoll]

Hi Pablo,

We have definitely modelled this into the ACTION.medication.v1 (Medication
management) archetype

https://openehr.org/ckm/#showArchetype_1013.1.123

Prescription dispensed
 Careflow step

The ordered medication has been dispensed, for example from a pharmacy to
the patient.

It has an active state.

Just note that this is not intended to support the internal pharmacy
dispensing process, just a note that the pharmacy has dispensed the product.

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, 11 Aug 2018 at 20:24, Pablo Pazos  wrote:

> Hi Karsten,
>
> On Sat, Aug 11, 2018 at 4:21 PM, Karsten Hilbert 
> wrote:
>
>> On Sat, Aug 11, 2018 at 04:03:28PM -0300, Pablo Pazos wrote:
>>
>> > How would you map a "pharmacy drug dispense" task, where the patient
>> comes
>> > with a prescription and a clerk delivers the medication packages?
>> >
>> > I was thinking this is clearly and ACTION, but also seems to be an
>> > ADMIN_ENTRY, since it is just a delivery of some product.
>> >
>> > I'm inclined to think it as an ACTION if this task alters the state of
>> the
>> > prescription INSTRUCTION ISM. On this case, as a parallel question, I'm
>> not
>> > sure if the dispense ACTION should be a final "COMPLETED" state, what
>> > happens if we want to record the patient's intake of the drug? Where the
>> > real "COMPLETED" is when the treatment is finished.
>>
>> That might mean that some INSTRUCTIONs never get COMPLETED
>> until the patient dies.
>>
>>
> There is a state "EXPIRED", so that is covered IMO if an expiration date
> is recorded, or even if the whole system has preconfigured expiration dates
> for drug treatments. This is very common, at least in the systems that I
> know.
>
>
>> It might help to think of shifts in responsibility: who is
>> primarily responsible for completion of a given action ?
>>
>> - write prescription -> doctor
>> - hand out drug based on prescription -> pharmacist
>> - take drug as instructed -> patient
>>
>> Each change of responsibility: doctor -> pharmacist ->
>> patient might warrant a COMPLETED state.
>>
>> 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
>>
>
>
>
> --
> *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
>
___
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.

[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

Re: Empty COMPOSITION.content is valid?

[Ian McNicoll]

I have certainly built templates where there is no expected content, only
additional other_contecxt and I can imagine situations where any/all data
could be carried by Composition RM attributes e.g in feeder_audit, so I
can't see a good reason for enforcing content.

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, 26 Jul 2018 at 09:59, GF  wrote:

> In the archetype the amount of constraints must be minimal.
> In the Template the amount of constraints must be optimal (maximal?)
>
> Archetypes are generic patterns.
> Templates are specific patterns.
>
> Generic meaning to be used in all systems at all points in time.
> Specific meaning to be used in a jurisdiction at a point in time.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 26 Jul 2018, at 10:46, Diego Boscá  wrote:
>
> 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
>
>
> ___
> 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: openEHR Education Program

[Ian McNicoll]

Hi all,

We all recognise the importance of education in this area but it has proven
difficult to find the right balance that allows an Educational program to
get off the ground, in a way that supports the small number of existing
providers, without over-burdening either the Foundation or those providers.
Evelyn and Pablo did some important groundwork a couple of years ago but we
felt that a simpler bootstrap process is required at this stage.

A small group of current education providers led by Heather Leslie, Hildi
McNicoll, Pablo Pazos and with Board representation from Koray Atalag are
putting the final touches on a proposal which should allow the Foundation
to start endorsing Education providers, who in turn can certify their
courses. The Mgt Board is looking at this proposal and although it might
need some small tweaks, we think this will be the best approach. We expect
to be able to share this more widely in the next few weeks once the new Mgt
Board has convened.

Please note that this first tranche of work is all about the endorsement of
Providers, and wholly focussed on 'vocational training', and not on higher
education. We are keen to start to pull together shared educational
material but we need to get these first steps in place.

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 Tue, 24 Jul 2018 at 12:37, David Moner  wrote:

> [Although this is a transversal topic to openEHR, I send it to the
> technical list, as it is the most active]
>
> Hello,
>
> Some time ago (I think it was in 2015), there was some movement towards
> formalizing an Education Program about openEHR. I thing Evelyn Hovenga
> and Pablo Pazos were involved.
> There have not been news about this, so I'm curious if it is still active.
> If not, I think it is more important than ever, and we should retake it.
>
> In the past I was responsible of (trying to) develop a similar program
> inside the EN 13606 Association, so I'm happy to share the strategies we
> had there, and to participate in developing an openEHR education and
> certification plan.
>
> Best regards,
> David
>
>
> --
> David Moner Cano
>
> Web: http://www.linkedin.com/in/davidmoner
> Twitter: @davidmoner
> Skype: davidmoner
> ___
> 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: Meaningful API's

[Ian McNicoll]

"The strong point of FHIR (where its success comes from) is that every
application can understand it. For this reason, I think that OpenAPI will
suffice for the purpose."

Which is not actually true, since every FHIR resource needs to be profiled
to be safely understood, often very heavily (see Observations). But I agree
that FHIR does represent (for some use-cases) a more business-oriented API
than openEHR which is deliberatly more low-level, However FHIR, in
practice, is itself much more complex (especially once you add in all the
extensions/ localisations/ terminology bindings and than say a locally
crafted API like Ripple.

The unique point of the openEHR API is that the receiving system (a CDR)
does not have to pull apart the incoming data structures (or at least it
does not require re-engineering for every new structure). This is harder
for newbies to understand but reduces the overall engineering effort
substantially especially for new data structures.

So there is a place for

lower-level API - openEHR service (or whatever, with varying content
representations)

Broad business API -FHIR (for openEHR based on common templates mapped to
local FHIR profiles) - see
https://github.com/Code4Health-Platform/openehr-care-connect-adaptor for an
example. The templates are designed to be UK wide.

Specific business API -  e.g Ripple

depending on your 'consumer'

The native data is complex, you cannot dodge that if you want
to deliver sophisticated health systems.

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 Tue, 17 Jul 2018 at 10:01, Bert Verhees  wrote:

> On 16-07-18 16:59, Thomas Beale wrote:
>
> well whether it is 'so good' is in the eye of the beholder, but it is
> 'good enough' for quite a lot of things, things for which we would once
> have expected to be able to use XMI. Anyway, the BMM introduction
> <https://www.openehr.org/releases/BASE/latest/docs/bmm/bmm.html#_introduction>
> provides some information on why it is there.
>
> BMM does not serve the purpose of describing API's. It serves the
> describing of software models.
>
> API's are communication-protocols. You can compare them with network
> protocols. There can be structures in them, and there are, in JSON, also in
> protobufs.
>
> But these structures do not serve the purpose of building an application
> around it. They only serve to communicate data. The receiving party must be
> able to recognize the structure, but the receiving side does not need to
> know that a list of structures is of a generic type. It will find out when
> reading the message that all the components of a list are from a specific
> type (if it is interested). Maybe for the receiving side, the fact that a
> specific list has generic data-items is not important, because in its own
> universe this is different. The same counts for hierarchy/inheritance. The
> receiving side does not need to know that a structure in message A is
> inherited from a structure in message B.
>
> The receiving side probably will tear apart the structures and reorder the
> data in its own structures.
>
> So any API design method which handles generics and inheritance
> communicates a lot of useless information, unless the other side is exactly
> the same machine, then they have a common center of the universe. However,
> this should never be the purpose of an API, nor the purpose of a message.
>
> The strong point of FHIR (where its success comes from) is that every
> application can understand it. For this reason, I think that OpenAPI will
> suffice for the purpose.
>
> 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: Meaningful API's

[Ian McNicoll]

Hi Bert,

Have a look at what Ripple is doing in terms of 'meaningful APIs'.

See
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html

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, 16 Jul 2018 at 15:06, Bert Verhees  wrote:

> On 16-07-18 15:56, Bert Verhees wrote:
> > But again, the starting point must be the API's defined, maybe in a
> > transformerable language like swagger, which seems to connect well to
> > the OpenAPI initiative.(I never liked swagger much, but my last
> > experience with it was from years ago, maybe it is better now)
> >
> > And then you mentioned BMM, I don't know about that. I should look at
> > it, I saw your other email. Do you have somewhere a document why BMM
> > is so good?
>
> The latest version of Open API (swagger became the Open API)
>
> https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md
>
>
> ___
> 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 nodes in multiple instances of one archetype in the same OPT

[Ian McNicoll]

Hi Dileep,

I'll check the AQL against Ethercis ASAP - Chrisitian has done a lot
of work in this area recently.

The issue of how best to distinguish different nodes on the same path is an
old and long conversation. There are quite a few different requirements/
use-cases.

What I suggested is perfectly legitimate, the AQL for each path will be
different as you can use a qualified name predicate in the AQL but I agree
it would be helpful to be able to carry the slot meaning (optionally) in
the patient data not just in the design-time definition.

I know Thomas has talked about this in the past. It would need a somewhat
significant change to the RM, I think.

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 Fri, 6 Jul 2018 at 14:55, Dileep V S  wrote:

> Thanks Ian/Silje,
>
> I will take a look at what Ian has suggested. But if Ethercis dos not
> support it, I will be back to square one. In that case would specializing
> the person_name and organisation archetypes for requester and receiver make
> sense?
>
> On further thought, I feel that what Ian has suggested is a work around
> and not part of the standard specs. Has there been any thoughts on a more
> elegant solution to be included in the standards? A more robust solution
> may be to include the slot id in the path and also in AQL so that same
> archetype in 2 different slots will have different paths. But then again
> this does not cover the situation where one slot is required to contain
> multiple instances of the same archetype.
>
> Silje,
> Thanks for the pointer to the new version of service request archetype.
> Will use that
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Jul 6, 2018 at 4:02 PM, Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no> wrote:
>
>> As a side note, the “Service request” archetype has just (yesterday, in
>> fact) been published as INSTRUCTION.service_request.v1.
>>
>> Regards,
>> *Silje*
>>
>>
>>
>> *From:* openEHR-technical [mailto:
>> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Ian McNicoll
>> *Sent:* Friday, July 06, 2018 11:16 AM
>> *To:* For openEHR technical discussions <
>> openehr-technical@lists.openehr.org>
>> *Subject:* Re: Unique paths for nodes in multiple instances of one
>> archetype in the same OPT
>>
>>
>>
>> Hi Dileep,
>>
>>
>>
>> The usual approach I take here is to rename the clustered archetype to
>> reflect local use, which works out as
>>
>>
>>
>> [openEHR-EHR-COMPOSITION.request.v1]
>> [openEHR-EHR-INSTRUCTION.request.v0]
>>
>> [openEHR-EHR-CLUSTER.organisation.v0, 'Requesting organisation']
>>
>> [openEHR-EHR-CLUSTER.person_name.v1]
>>
>> [openEHR-EHR-CLUSTER.organisation.v0, ' Receiving organisation']
>>
>> [openEHR-EHR-CLUSTER.person_name.v1]
>>
>>
>>
>> and is queryable on AQL.
>>
>>
>>
>> see
>> https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings/Referrals
>>
>> Note that the AQL described was not working correctly on Ethercis in the
>> past but that issue may have been fixed.
>>
>>
>>
>> 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 Fri, 6 Jul 2018 at 10:07, Dileep V S  wrote:
>>
>> Hi,
>>
>>
>>
>> We are trying to create a service request template using the following
>> structure
>>
>>
>>
>> [openEHR-EHR-COMPOSITION.request.v1]
>> [openEHR-EHR-INSTRUCTION.request.v0]
>>
>> [openEHR-EHR-CLUSTER.organisation.v0]
>>
>> [openEHR-EHR-CLUSTER.person_name.v1]
>>
>> [openEHR-EHR-CLUSTER.organisation.v0]
>>
>> [openEHR-EHR-CLUSTER.person_name.v1]
>>
>>
>>
>>

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

[Ian McNicoll]

Hi Dileep,

The usual approach I take here is to rename the clustered archetype to
reflect local use, which works out as

[openEHR-EHR-COMPOSITION.request.v1]
[openEHR-EHR-INSTRUCTION.request.v0]
[openEHR-EHR-CLUSTER.organisation.v0, 'Requesting organisation']
[openEHR-EHR-CLUSTER.person_name.v1]
[openEHR-EHR-CLUSTER.organisation.v0, ' Receiving organisation']
[openEHR-EHR-CLUSTER.person_name.v1]

and is queryable on AQL.

see
https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings/Referrals

Note that the AQL described was not working correctly on Ethercis in the
past but that issue may have been fixed.

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 Fri, 6 Jul 2018 at 10:07, Dileep V S  wrote:

> Hi,
>
> We are trying to create a service request template using the following
> structure
>
> [openEHR-EHR-COMPOSITION.request.v1]
> [openEHR-EHR-INSTRUCTION.request.v0]
> [openEHR-EHR-CLUSTER.organisation.v0]
> [openEHR-EHR-CLUSTER.person_name.v1]
> [openEHR-EHR-CLUSTER.organisation.v0]
> [openEHR-EHR-CLUSTER.person_name.v1]
>
> The first set of organization & person name archetypes are for the
> requester and the second set for the receiver.
>
> However in the template editor, the paths for the nodes of both these
> instances are the same(Eg. Orgaization name, Identifier, unstructured name
> etc). This, we feel, will create problems in the AQL as we cannot uniquely
> identify the nodes. How do we solve this problem. Is there any better way
> to model the template
>
> I m attaching the template file set for reference
>
> Regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR Toolkit

[Ian McNicoll]

Really nice work, Pablo.

Ian

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


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

On 28 March 2018 at 04:39, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:

> Hi all,
>
> I have released a humble pack of tools to help developers working with
> openEHR and the EHRServer.
>
> This is a pre-alpha version, I'm looking for feedback. Any service idea,
> improvements, comments, etc. are very welcome!
>
> Please give it a try: http://server001.cloudehrserver.com/cot/
>
> We have many areas of improvements :)
>
> --
> 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-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: Export via CDISC ODM or FHIR

[Ian McNicoll]

Hi Georg,

See https://github.com/inidus/openehr-care-connect-adaptor

for examples of exporting AQL resultsets as FHIR profile bundles.

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 6 March 2018 at 12:55, Georg Fette <georg.fe...@uni-wuerzburg.de> wrote:

> Hello,
> Are there already ideas about a future export API of AQL queries that
> support an export in CDISC ODM or FHIR ? It would be nice to have an export
> format that could be immediately consumed by other systems supporting the
> same specifications. I am not yet that much into either topic (ODM as well
> as FHIR), therefore I do not yet see if the desire itself makes not sense
> or if there are serious problems that would hinder such exports.
> 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: Archetype pattern

[Ian McNicoll]

Hi Bert,

A couple of quick observations...

1. You are correct that the flexibility of openEHR can lead to chaos. Or
more accurately it simply reflects the existing chaos. The idea of having
the CKM archetypes is to allow us to hold up a set of well-designed
patterns for folks to use, accepting that this is a huge and varied problem
space in which reduction of chaos will take a long time. Reducing the chaos
is a cultural and organisational problem, not just about technology and
semantics.

2. openEHR is not just about having interoperable, shared models. It is
just as much about being able to quickly develop and adapt datasets, even
if these use significant local content.

3. Deciding when to use 'standard' archetypes or when to roll your own is
not easy. It requires decent knowledge of openEHR but much more
importantly, detailed health informatics knowledge and expertise. This is
still like climbing Mt. Evert - you are better off hiring some local Sherpa
Guides, at least for the first few ascents. Ordinary clinicians do not have
this knowledge - their knowledge of their domain is critical but often
siloed.

4. The reason that SNOMED CT did not provide your solution is that it was
never designed to do so. It provides an excellent means of sematically
labelling the values of clinical questions "What was the name of a
diagnosis, procedure or medication?" but cannot handle the complexity of
how and where that question was asked - this is the role of the structural
information model repesenting documentaion of clinical care, not biological
entities.

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 16 February 2018 at 13:22, Thomas Beale <thomas.be...@openehr.org> wrote:

>
>
> On 16/02/2018 09:48, Bert Verhees wrote:
>
> On 16-02-18 12:41, Thomas Beale wrote:
>
>
>
> - Specific Local Templates/patterns used in a defined community for
> specific purposes
>
>
> specialisations of any archetype for local usage.
>
> I don think you should ever create an archetype in the idea that it is a
> local archetype. I think you can never guarantee that. Archetypes are a
> model of thinking, a semantic model, instead of a technical model, like
> Codd-normalization.
> So in an other situation there will also be the need to express the same
> way of thinking in an archetype, but they will probably structure it
> different.
> That is something were we should find a way to avoid that.
>
>
> the key word is 'specialisation'. In ADL, a specialised archetype is a
> computable technical artefact, and creates data reliably queryable just
> using the parent archetype. (Note that only ADL2 specifies this properly).
>
> The question of 'good' structuring is a separate one.
>
>
>
> - Specific Clinical Models/patterns for things like: the documentation of
> lab-test forms/panels, collections of meta-data for documentation of
> specific observations/test for abdominal complaints, etc.
>
>
> COMPOSITION archetypes, probably some SECTION archetypes
>
> Sections are, I think, a problem, they are part of the path, so they
> change query-paths and can make data invisible, because maybe no one
> thought of a section when searching in a database.
> I don't know if AQL has a wild-card to pass sections without paying
> attention to them. I think that is necessary.
>
>
> AQL does have a 'wildcard' - it is the CONTAINS operator - it's the
> equivalent of the '//' operator in Xquery and Xpath. That's why you can
> query for an Observation path (say, to systolic BP) regardless of how many
> layers of SECTIONs it might be under.
>
> - 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Ian McNicoll]

Hi Pieter,

Can I also express my thanks on behalf of the openEHR community.  Late in
life I am becoming a bit of a java-ninja (well , in my dreams), so I will
definitely give Archie a go. I can already think of a few really useful
bits of tooling we could develop.

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 31 January 2018 at 15:32, Seref Arikan <serefari...@kurumsalteknoloji.com
> wrote:

> Pieter,
>
> Allow me to express my appreciation and gratitude please: Archie is a
> fantastic piece of work, which has become my go-to library since I
> discovered it. Thanks a lot for all your hard work.
>
> Kind regards
> Seref
>
>
> On Wed, Jan 31, 2018 at 3:18 PM, Pieter Bos <pieter@nedap.com> wrote:
>
>> Hi,
>>
>> We’re pleased to announce Archie version 0.4! For those of you unfamiliar
>> with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a
>> basis for archetype modelling and EHR implementations with ADL 2.
>>
>> Version 0.4 is a big change from version 0.3. Many features have been
>> added that make Archie suitable as a library for modelling archetypes, and
>> the existing functionality has been improved.
>>
>> It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle
>> and Kurt Allen. This enables Archie to work with other reference models
>> than the included OpenEHR reference model. The BMM files and AOM profiles
>> that are in the ADL workbench are included in the library – of course you
>> can supply your own as well.
>>
>> We developed an archetype validator that implements nearly all of the
>> validations in the specification, and we improved the flattener and the
>> operational template creator to be compliant with the specifications. The
>> flattener, archetype validator and operational template creator work with
>> both the BMM models or with metadata derived from an actual java reference
>> model implementation.
>> Many tests were added to ensure better conformance with the specification
>> and many fixes have been introduced. We’d like to thank Thomas Beale for
>> giving advice about many details of the working of OpenEHR implementations
>> and for fixing mistakes in the specifications when they were found.
>>
>> Of course, Archie also contains a lot of other tools, many of which allow
>> it to be used as the basis for an EHR implementation as well as a modelling
>> tool: An ADL parser and serializer, the OpenEHR reference models, rule
>> evaluation, path lookup, JSON and XML (de)serialization, ODIN parsing and
>> RM object manipulation tools.
>>
>> Archie version 0.4.1 is available at Maven Central. See the instructions
>> and documentation in the readme at https://github.com/openehr/archie for
>> how to use the library.
>>
>> Regards,
>>
>> Pieter Bos
>> Nedap Healthcare
>> ___
>> 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: Process to follow for coding using Terminology server

[Ian McNicoll]

Hi Dileep,

As Pablo says, any DV_TEXT can be sub-classed as DV_CODED_TEXT.

How are you storing the composition data ,FLAT JSON?

If so you can save coded data for any DV_TEXT node as follows


"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|code":
"91936005",

"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|value":
"allergy to penicillin",

"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|terminology":
"SNOMED-CT",

 
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent":
"non-coded text",

The fulll RAW JSON equivalent is

{
"@class": "ELEMENT",
"name": {
"@class": "DV_TEXT",
"value": "Causative agent"
},
"archetype_node_id": "at0002",
"value": {
"@class": "DV_CODED_TEXT",
"value": "allergy to penicillin",
"defining_code": {
"@class": "CODE_PHRASE",
"terminology_id": {
"@class": "TERMINOLOGY_ID",
"value": "SNOMED-CT"
},
"code_string": "91936005"
}
}
    },

AQL to retreive is something like

  b_a/data[at0001]/items[at0002]/value/value as causative_agent_value,
b_a/data[at0001]/items[at0002]/value/defining_code/code_string as
causative_agent_code,
b_a/data[at0001]/items[at0002]/value/defining_code/terminology_id/value
as causative_agent_terminology,

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 20 December 2017 at 05:41, Dileep V S <dil...@healthelife.in> wrote:

> Hi,
>
> We are in the process of adding a terminology server to code the
> composition date. However many of the nodes that can be coded are text
> fields (Eg. Symptom/sign name in Symptom/sign archetype that we have used
> in Complaints template). As we understand, the data type has to be changed
> to CODED-TEXT before we can store coded data.
>
> What is the best practice to do this? Shall we go ahead and edit the
> archetypes, in which case our archetypes will no longer be same as the ones
> in CKM? Are there more robust mechanisms to achieve this without breaking
> compliance to CKM?
>
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM

[Ian McNicoll]

Does not work here either, Bert. The whole site is offline. Probably just a
tech snafu.

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 19 November 2017 at 08:24, Bert Verhees <bert.verh...@rosa.nl> wrote:

> Sorry for this message which has nothing to do with OpenEhr, but I have a
> problem and possible here someone knows how to help.
>
> I am trying since a few days to reach the UCUM site because I want to
> download the UCUM XML file
>
> This would be on the URL:
>
> http://unitsofmeasure.org/trac
>
> But it doesn't work anymore, not from my computer or phone (which is on
> another network)
>
> 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: AQL for multi-occurrence nodes

[Ian McNicoll]

Hi - agree with Thomas and more here

https://github.com/ethercis/ethercis/issues/69

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 2 November 2017 at 14:42, Thomas Beale <thomas.be...@openehr.org> wrote:

> Hi Dileep
>
> On 27/10/2017 04:15, Dileep V S wrote:
>
> Hi,
>
> What is the expected response to AQL on a node with multiple occurrences?
> Does it return all the occurrences or only the first one?
>
>
> querying is always about returning everything that matches - it's a
> declarative concept, not a procedural one.
>
>
> If it is expected to return all occurrences, what is the structure of the
> response? will the occurrences be returned as an array?
>
>
> In REST terms, see here
> <https://openehr.github.io/specifications-ITS/query.html>. If you want
> other structures, e.g. C# / Java / other language etc, please respond here,
> there are answers for that as well.
>
> - 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Does aql support multiple ehrids?

[Ian McNicoll]

Marand THinkEHR supports this ...

WHERE e/ehr_id/value MATCHES {

'e241715b-3ca7-435e-a474-718579aadaa2',

'0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1',

'ed74f788-4bd6-4e47-ab98-211643cc4b0c'}



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 27 October 2017 at 07:20, Dileep V S <dil...@healthelife.in> wrote:

> Hi,
>
> I have tested aql with single ehr and across all ehrs(without any ehrid).
> Can we pass an array of ehrids in an aql to limit the query to selected
> ehrs?
>
> 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
>
___
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

[Ian McNicoll]

It is indeed.

It is not called 'choice', it is just multiple datatype constraints on the
same element.

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 22 September 2017 at 12:14, Dileep V S <dil...@healthelife.in> wrote:

> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR in North Americas

[Ian McNicoll]

Hi

I am aware of some commercial interest in USA and Canada though nothing
visible as yet. I am not sure about Mexico. Pablo pazos might be more in
touch with interest there .

Ian

On Sat, 5 Aug 2017, 17:40 V Ramayya, <rama...@me.com> wrote:

> Hello,
>
> Are there any openEHR projects or efforts that are either planned or in
> progress in Canada, USA and/or Mexico?
>
> Ramayya
> ___
> 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

Re: standalone .opt parser open source

[Ian McNicoll]

Cheers Pablo,

I owe you a fine Dutch beer.

Ian
On Thu, 3 Aug 2017 at 21:38, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:

> https://github.com/ppazos/openEHR-OPT
>
> On Wed, Aug 2, 2017 at 11:44 AM, Ian McNicoll <i...@freshehr.com> wrote:
>
>> I am working with some UCL computer science students who are exploring
>> the use of an operational template to generate mappings.
>>
>> Can anyone point me to a reasonably standalone .opt parser, preferably
>> jajva-based?
>>
>> 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
>>
>> ___
>> 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

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

standalone .opt parser open source

[Ian McNicoll]

I am working with some UCL computer science students who are exploring the
use of an operational template to generate mappings.

Can anyone point me to a reasonably standalone .opt parser, preferably
jajva-based?

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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Questionnaires

[Ian McNicoll]

Hi all,

First of all, I largely agree with Heather re the current approach. At
freshEHR, we generally try to maximise the use of international 'semantic'
archetypes, including scales, scores etc  but accept that this is often not
necessary and that there is place for simply modelling aspects of the
questionnaire as-is.

Commercially, I am interested in how we might make use of , or at worst,
play nicely with the FHIR Questionnaire resources.

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 5 June 2017 at 10:05, GF <gf...@luna.nl> wrote:

> Hi,
>
> A few of generic ideas around the question-answer pair.
>
> There are several kinds of question-answer pairs:
> - The general generic pattern is the pair: question - answer;
> - The questionnaire can be one or more question-answer pairs;
> - The questions can be locally defined or regionally, nationally,
> internationally used;
> - Answers can be* free text*, *quantitative* (number, code),
> *semi-quantitative* (derived from a categorised set of possible answers
> using inclusion and exclusion criteria) or *qualitative* (present, not
> present);
> - Answers can be aggregated by means of category, mathematical formula.
>
> This list of kinds of questionnaires ranges from simple to very complex
> patterns.
> Some are simple statements others are very complex scales and
> questionnaires in between.
> They are all variations on a theme.
> Any answer can expressed in the in-line local form and/or with a reference
> to an external source.
>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 5 Jun 2017, at 07:59, Grahame Grieve <grahame@healthintersections.
> com.au> wrote:
>
> hi Heather
>
> > A generic question/answer pattern is next to useless - interoperability
> is really not helped
>
> I think you should rather say "A generic question/answer pattern is only
> useful for exchanging the questions and answers, and does not allow re-use
> of data". This is not 'next to useless for interoperability', just not fit
> for any wider purpose
>
> Grahame
>
>
>
> ___
> 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: SNOMEDCT - correct representation

[Ian McNicoll]

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"] =
> 
> >
> >
> >
>
>
>
> 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

Re: Random / Synthetic Data Generation over Templates

[Ian McNicoll]

Would there be any interest in making these services available if we could
find some free uk hosting? I guess ideally we should post the template and
get back a sample composition without any actual persistence of either.


On Thu, 13 Apr 2017 at 18:39, Diego Boscá <yamp...@gmail.com> wrote:

> Yeah, LinkEHR can do that
>
> Regards
>
> El 13/4/2017 17:37, "Anastasiou A." <a.anastas...@swansea.ac.uk> 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

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

Re: Including reference range in archetypes

[Ian McNicoll]

Hi Dileep,

This is a common scenario, that right now is mostly handled in application
code.

My understanding of normal_range/reference_ranges (part of the quantity
model) is that these are intended to carry the normal ranges that apply to
a biological observation such as lab_test or perhaps imaging_ exam, rather
than (as in your case) a sort of rule that is applied to caclulate or
categorise risk.

The most high profile comparable example I know of , is the NEWS score.

Archetype at NEWS (UK RCP), Published archetype [Internet]. openEHR
Foundation, openEHR Clinical Knowledge Manager [cited: 2017-04-13].
Available from: http://openehr.org/ckm/#showArchetype_1013.1.2423

Rules at https://www.mdcalc.com/national-early-warning-score-news

I would expect a UI to colour-code each component in a similar fashion, to
indicate potential risk.

You might want to explore GDL, which is an extension to openEHR that acts
as a glue layer between archetypes and those sort of rules.

http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html

There is also some interest in folding aspects of GDL inside archetypes as
part of the 'rules' aspect of ADL. One of the barriers to getting this
working at scale, is deciding what 'vendor-neutral' rules definition
language to use. Not everyone is a fan of javascript but I do see some
potential in this space given its ubiquity in the market.

I'm not sure I have answered your question!!

Regards,

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 12 April 2017 at 11:36, Dileep V S <dil...@healthelife.in> wrote:

> Hi,
>
> I am trying to create an archetype that screens for health risks. All the
> questions have ordinal data. Based on the values selected for the
> questions, the consolidate risk value is calculated.
>
> I want the UIi to display appropriate warnings (coloring the risk value
> etc) based on a reference range for the value. How can I include the
> reference range in the archetype so that the UI can read that and display
> the warnings?
>
> thanks for the help
> 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Ian McNicoll]

Hi Pieter,

Thanks for the update. This kind of innovation is why I am so keen to make
the jump to this brave new world.

I'd love to hear more about your main project but will contact you
separately.

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 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:

> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com<mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
>
> [https://docs.google.com/uc?export=download=
> 0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtM
> DJ0bkdUcUQxM2dqSVdrPQ]
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl ert.verh...@rosa.nl>> wrote:
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
> Good news Thomas, but don't bring it with disdain.
>
> I don't know what the words means ;)
>
> I got it from google translate, in French it is dedain.
> that appears to be a PR about GDL?
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as 

Re: inheritance of archetypes

[Ian McNicoll]

Hi Thomas / Bert,

I think you will find a significant pain point in the modelling community.
Agree that for now 1.4 .opt is going to be best for implementers but as I
understand things a 2.0 .opt and related RM changes would not be radically
different, in any case.

The big difference, and gain (once we get over the line) is much easier
handling of design-time artefacts, and potential extensibility.

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 1 March 2017 at 12:26, Thomas Beale <thomas.be...@openehr.org> wrote:

>
>
> On 01/03/2017 10:00, Bert Verhees wrote:
>
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
> Good news Thomas, but don't bring it with disdain.
>
>
> I don't know what the words means ;)
>
>
> I got it from google translate, in French it is dedain.
>
>
> c'était une blague...
>
>
> that appears to be a PR about GDL?
>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
>
> ah - probably you wanted to show these issues
> <https://openehr.atlassian.net/issues/?filter=-4=status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Analysis%2C%20%22In%20Review%22%29%20AND%20component%20in%20%28ADL2%2C%20AOM2%29%20order%20by%20created%20DESC>.
> There are issues (always), but not with the specialisation representation.
>
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
>
>
> well, it has a stable release here
> <http://www.openehr.org/releases/AM/Release-2.0.6/docs/index>. As noted
> above, there are issues, but there are issues outstanding on everything -
> they get worked on and the results get added to later releases. I'm not
> sure of what the alternative to that is.
>
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
>
> well CKM is a problem in one sense, but people could work with ADL2 tools
> and save the results as ADL 1.4, which  you can do in the ADL-designer, for
> upload to CKM. That's not ideal, I agree - it would be better if CKM
> upgraded to ADL2.
>
> Data storage is generally based on OPT 1.4, and I think that is also a
> save format of the ADL-designer.
>
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
>
> well you are pointing out some pain, and I am pointing out the solution.
> If you are not in enough pain, you may not want the solution ;)
>
> - 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: inheritance of archetypes

[Ian McNicoll]

Hi Bert,

Marand are about to release a major interim update to their ADL-2 Archetype
tooling. I am told sometime in March).

One of the major design criteria is to be able to create ADL1.4 artefacts
and, critically, ADL 1.4 .opts so we can use the new tools with existing
systems, but take advantage of better handling of specialisations etc.
@Birger - This will also help with transition in tooling like CKM, where we
should be able to create ADL 1.4 flat forms for review purposes.

We expect this first release to need a bit of work and user-feedback. We
(freshEHR) have committed to give it a good workout on real-world project
so that we can rapidly iterate and get it ready for proper release.

This is the year we make the jump, at least in the design space!! I expect
back-end CDRs and other tooling to be working with ADL1.4 artefacts for
some time. The impact on CDRs is not actually very significant if we mange
the transition carefully.

I would be delighted to hear from any developers or companies who might be
prepared to make a contribution to this project (open-source of course). We
have had a couple of interesting offers of support already. Good tooling is
essential to openEHR, and if we get a good set of baseline tools, there are
all sorts of interesting extensions that could be developed.


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 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl> wrote:

> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
>> Good news Thomas, but don't bring it with disdain.
>>>
>>
>> I don't know what the words means ;)
>>
>
> I got it from google translate, in French it is dedain.
>
> that appears to be a PR about GDL?
>>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
>> is to use the new version of ADL-designer.
>>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
> But the discussion on this technical list can be closed as the point I
> wanted to make is planned to be solved (and maybe soon).
>
> Best regard
>
> 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: INFORMATION ABOUT THE SYSTEM

[Ian McNicoll]

Hi,

If this seems scary and confusing, that is normal

Essentially openEHR is a specification that allows people to build health
data repositories that are vendor and technology-neutral. openEHR CDRs are
very flexible health datastores that can immediately store and query new
kinds of clinical data, without any re-programming or database
reconfiguration.

As an implementer of e.g a rare disease registry application, you would
upload definitions of the data you need using 'templates' themselves built
of open-source 'archetypes' e.g blood pressure, lab test.

We are actually involved in helping build a very extensive Rare disease
register in the UK as part of a Genomics England project and are starting
to share our models at
http://clinicalmodels.org.uk/ckm/#showProject_1051.61.28. The whole of this
http://www.xmind.net/m/ZvDB dataset has now been modelled in openEHR and we
will be uploading it to the UK CKM site over the next couple of weeks.

To make use of these you need to get access to an openEHR CDR (Clinical
data repository). There are a number of commercial products available and
at least two high quality open-source engines.

You should definitely explore Pablo's Cabolabs CDR
https://github.com/ppazos/ and
the EtherCis CDR https://github.com/ethercis/ethercis

I can also arrange access to a free cloud-hosted CDR via the NHS
Code4Health program, for demo use only.
https://code4health.org/platform

For an overview of openEHR
https://www.slideshare.net/OceanInformatics/smart-data-smarter-healthcare

For an overview of  the clinical modelling aspects:
https://www.slideshare.net/OceanInformatics/smart-data-smarter-healthcare

and Pablo has some great presentations on the technical aspects of CDRs but
you almost certainly do not want to try to build your own
https://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr?qid=87811c0b-44fb-434d-9123-79793add44ba==_search=1

Hope this helps - more information on your project would help us point you
in the right direction.

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 21 February 2017 at 19:34, STAMATAKI-LOUKATOU GERASIMOULA <
gstam...@uth.gr> wrote:

> Thank you all for your immediate response.
>
> For example can I use openEHR to build a database for a rare disease ?
> So, I can use whatever language suits my need if I understand correct?
> I really do not have any experience.
>
> Quoting Alejandro Benavides <alejan...@acronymcr.com>:
>
> It totally validates your questions, more when you enter the world of
>> standards, and the lack of experts with assertive answers (something that
>> is weak in this group), but that "another topic."
>>
>> Really openEHR as other standards do not have specified which programming
>> language, database, network infrastructure, etc. should be used, this
>> depends on the type of need you present.
>>
>> I agree to ask the question to the group as there is very little
>> documentation on what it means to bring the standard into practice. The
>> first thing is to understand what the standard is used for, in what
>> clinical domain you want to implement it and see what is available (open
>> source or private). I think it could help you a lot more by being a bit
>> more specific in what you want to know.
>>
>>
>>
>>   <https://mailtrack.io/> Enviado con Mailtrack
>> <https://mailtrack.io/install?source=signature=es
>> ral=alejan...@acronymcr.com=23>
>>
>> 2017-02-21 12:49 GMT-06:00 Pablo Pazos <pablo.pa...@cabolabs.com>:
>>
>> Hi,
>>>
>>> openEHR is a specification, not a software system.
>>>
>>> There are many implementations. Like https://github.com/ppazos/
>>> cabolabs-ehrserver
>>>
>>> Regards,
>>> Pablo.
>>>
>>> On Tue, Feb 21, 2017 at 3:43 PM, STAMATAKI-LOUKATOU GERASIMOULA <
>>> gstam...@uth.gr> wrote:
>>>
>>> Good evening,
>>>>
>>>> I am a postgraduate student in Bioinformatics and it may seem stupid but
>>>> I would like to ask you a few questions about openEHR , as I was unable
>>>> to
>>>> find or understand them.
>>>>
>>>> What database openEHR uses and what programming language?
>>>> Is it possible to alter the schema in order to fit to my needs?
>>>>
>>>> Thank you in advance,
>>>> Mema Stamataki.
>>>>
>>>>
>>>> __

Re: Hand coding templates in ADL 1.4

[Ian McNicoll]

Thanks Pieter/ Diego,

and hi Dileep.

AFAIK Demographics archetypes/ templates are currently only handled by
LinkEhr and Tom Beale's ADL workshop tool. This is partly because ,
to-date, (at least publicly) only a couple of companies have made use of
the openEHR Demographics service - Code24 and Ocean.

Hopefully with the upcoming release of the latest Marand ADL tools and
others, we are quickly reaching a point where we can start the transition
to ADL2. The first step, in my view, is to make sure that ADL-based tools
can readily create ADL 1.4 .opt files, as virtual all of the current,
publicly available back-end CDR's use this. The real advantages of ADL2 are
in the design-time space with relatively little impact on back-end, so we
can probably live with ADL 1.4 .opt for a while until the tools settle
down.As Pieter has said, moving from .oet to ADL 2 will actually make life
easier since we use ADL2 fpr templates too. The quicker we can make that
jump the better.

.oet in an internal Ocean format, and I'm not sure if there are any normal
published specs but a few people ... LinkEHR, Marand and others appear to
support .oet parsing. The upcoming Marand tools, are I understand
open-source so that should provide you with some practical guidance but my
own intention is to move to ADL2 templates for projects ASAP.

Kind regards,

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 12 February 2017 at 12:11, Pieter Bos <pieter@nedap.com> wrote:

> The editing tools for adl 2 are still limited. However the template
> editing by hand is easier in adl 2 than the earlier template xml formats
> because it's the same adl with a few extra language constructs for
> templates.
>
> And you can convert the ckm to adl 2 quite easily.
>
> Pieter Bos
>
>
> Op 12 feb. 2017 om 12:04 heeft Diego Bosc? <yamp...@gmail.com<mailto:yamp
> e...@gmail.com>> het volgende geschreven:
>
> 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" <dil...@healthelife.in dil...@healthelife.in>> 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<mailto:openEHR-
> techni...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
> ___
> 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
>
> ___
> 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: ELEMENT.null_reason proposal

[Ian McNicoll]

Hi Diego,

That's a pretty good suggestion, although in that case we are really
abandoning the idea of the current fixed base set of 'technical'
null-flavours and allowing them to be replaced by local terms, while I was
suggesting something more like the ISM_TRANSITION setup where
archetype-specific 'clinical overlays' can be provided via the archetyped
careflow_steps but are always associated with the underlying state_machine
and current_status attribute.

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 25 January 2017 at 11:54, Diego Boscá <yamp...@gmail.com> wrote:

> If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
> specialized archetype (directly from an rm class) that has the texts
> (+ codes) needed in a given country/use case?
> This probably should work even if set of null_flavour codes is fixed.
> I don't know if this would be enough, but in theory it provides a
> workaround for all issues (except the cluster one)
>
> 2017-01-25 12:33 GMT+01:00 Thomas Beale <thomas.be...@openehr.org>:
> >
> > Silje has just pinged me again on the question of whether we should have
> an
> > ELEMENT.null-reason or similar attribute to accommodate specific reasons
> for
> > null_flavour being set. There are 3 PRs on this as follows:
> >
> > SPECPR-41 - Enable content specific flavours of null to be specified per
> > archetype
> > SPECPR-62 - Add a 'reason for null' text attribute in the Reference model
> > SPECPR-119 - CLUSTER also needs a Null_flavour
> > SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
> >
> > These are all reporting the same problem. (The last one can probably be
> > closed as a direct duplicate of SPECPR-62). Having re-read the comments
> on
> > all, my inclination is to propose the simple addition of an attribute
> > null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional
> and
> > will not invalidate any existing data, but on the downside it will be a
> data
> > field that will often be emtpy (i.e. Void, or 'null' in the Java/C
> sense).
> >
> > What would the general reaction to proposing this change be?
> >
> > - 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: ELEMENT.null_reason proposal

[Ian McNicoll]

Hi Thomas,

I agree that we should go ahead with this ASAP. However it might be worth a
slight pause to think about the wider problem in handling 'clinical nulls'.

To summarise, 'null flavours' have limited value in a great deal of
clinical models because the standard set of null flavours, although
expressing the 'reason for null' from a technical perspective 'not
appropriate', 'unavailable' etc is not clinician/context friendly enough
for actual use-cases.

I think there is strong parallel here with the need to overlay the
technical state machine current_state attribute with archetype_specific
careflow_steps as per SPECPR-41
<https://openehr.atlassian.net/browse/SPECPR-41> .

Now we will probably always need extra free text as per SPECPR-62/151 but
if we are thinking about this, I suggest putting a little effort into
progressing ( or ditching) those other PRs.

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 25 January 2017 at 11:33, Thomas Beale <thomas.be...@openehr.org> wrote:

>
> Silje has just pinged me again on the question of whether we should have
> an ELEMENT.null-reason or similar attribute to accommodate specific reasons
> for null_flavour being set. There are 3 PRs on this as follows:
>
>- SPECPR-41 <https://openehr.atlassian.net/browse/SPECPR-41> - Enable
>content specific flavours of null to be specified per archetype
>- SPECPR-62 <https://openehr.atlassian.net/browse/SPECPR-62> - Add a
>'reason for null' text attribute in the Reference model
>- SPECPR-119 <https://openehr.atlassian.net/browse/SPECPR-119> -
>CLUSTER also needs a Null_flavour
>- SPECPR-151 <https://openehr.atlassian.net/browse/SPECPR-151> - Add
>an attribute to ELEMENT to record 'null reason'
>
> These are all reporting the same problem. (The last one can probably be
> closed as a direct duplicate of SPECPR-62). Having re-read the comments on
> all, my inclination is to propose the simple addition of an attribute 
> null_reason:
> DV_TEXT[0..1] to the ELEMENT class
> <http://www.openehr.org/releases/RM/latest/docs/data_structures/data_structures.html#_element_class>.
> This would be optional and will not invalidate any existing data, but on
> the downside it will be a data field that will often be emtpy (i.e. Void,
> or 'null' in the Java/C sense).
>
> What would the general reaction to proposing this change be?
>
> - 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: Context in persistent COMPOSITION archetypes?

[Ian McNicoll]

Sorry,
I didn't reply to the question about context in persistent compositions.
Actually right now this is not possible because there is a rule in the rm
which says that persistent compositions cannot have context. This has been
recognised as unhelpful and there was a change request in to remove that
rule which may now have gone through. I'll check.

In fact it really does not matter too much right now since setting
persistent does not actually do anything technically. I.e. It is still up
to tbe implementer to save the data in the right way.

Actually the suggestion to store each entry in its own separate composition
is very similar to what we are doing in the ripple project, albeit for
slightly different reasons. Essentially we are treating the problem list as
a virtual document which does mean that each entry carries its own
composition context metadata.

Still think synchronisation is scary!

Ian
On Wed, 18 Jan 2017 at 23:18, Bjørn Næss <b...@dips.no> wrote:

> Hi
>
>
>
> To the first question – technical: Is it possible to have context on a
> persistent composition?
>
> Yes – I think that should be possible. Some will argue that the context is
> an EVENT_CONTEXT and such context should only be used for event based
> Compositions. I think it makes sense to have some context also for the
> persistent ones.
>
>
>
> Then to Ian’s follow up –what is the underlying use-case here?
>
> The use-case seems to be based on a distributed environment where several
> healthcare providers commit their data for a given EHR (subject of care).
> This seems to be a asynchronous messaging architecture where they send
> messages (as Compositions) to update a central repository.
>
> If this is true – then I agree with Ian that the synchronization of the
> underlying data will be hard .
>
>
>
> The idea seems to be to keep a clinical concept within one persistent
> composition. I guess the intention by this is to be able to update a single
> source for the information about a specific concept. Then the central
> service must do some bookkeeping to make sure that each concept is updated
> by creating a new version of the specific persistent composition.
>
>
>
> Another approach would be a more synchronized architecture. Where you
> first query for the concepts and get back all the LOCATABLE’s . Then the
> client will be able to create new versions of each entry (by creating new
> versions of the surrounding container). And when doing this – why would you
> like to constraint the model to only have one ENTRY for each COMPOSITION?
> This question leads me to suggest that the context you would like to add
> should be on the ENTRY – being an EVALUATION, OBSERVATION, etc.  Could this
> be a solution?
>
>
>
> BTW: We (DIPS) are implementing openEHR FOLDER to support use-cases like
> this. We will use FOLDER to realize a “FOLDER DOCUMENT”. This is kind of a
> persistent composition – but since it is a FOLDER it can combine several
> autonomous COMPOSITIONS in a shared view. I think this actually is
> PERSISTENT COMPOSITION done the right way. I think it would be used for all
> use-cases where we today create a PERSISTENT Template to model i.e. Social
> Summary, Previous Diseases. We will post some specifications/descriptions
> on this soon.
>
>
>
> /Bjørn
>
>
>
>
>
> *Fra:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *På vegne av* Ian McNicoll
> *Sendt:* 18. januar 2017 17:22
> *Til:* For openEHR technical discussions
> *Emne:* Re: Context in persistent COMPOSITION archetypes?
>
>
>
> Hi Silje,
>
>
>
> Can you tell us more about the background? Are you trying to provide the
> model for the message, or to store the data when it is received (or both)?
>
> Where does the data come from and how is it managed / curated? Does it
> come from a single clinician (presumably GP) or from multiple sources? Is
> it curated/managed by the GP or is it managed by the recipient.
>
>
>
> In the UK, all of the emergency summaries are essentially copies of
> summaries managed and curated by the GP, so there is no need to synchronise
> lists, as it appears you are trying to do here. That is pretty difficult
> and even with simpler, safer labs messages, my understanding is that people
> have stopped sending 'diffs' i.e just a note of updates/changes in favour
> of re-sending the current full version of the message again.
>
>
>
> 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.
> Direct

Re: Context in persistent COMPOSITION archetypes?

[Ian McNicoll]

Hi Silje,

Can you tell us more about the background? Are you trying to provide the
model for the message, or to store the data when it is received (or both)?

Where does the data come from and how is it managed / curated? Does it come
from a single clinician (presumably GP) or from multiple sources? Is it
curated/managed by the GP or is it managed by the recipient.

In the UK, all of the emergency summaries are essentially copies of
summaries managed and curated by the GP, so there is no need to synchronise
lists, as it appears you are trying to do here. That is pretty difficult
and even with simpler, safer labs messages, my understanding is that people
have stopped sending 'diffs' i.e just a note of updates/changes in favour
of re-sending the current full version of the message again.

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 18 January 2017 at 15:10, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi,
>
>
>
> Is is possible to add context, ie actual text or other data types, to a
> persistent composition. The Archetype Editor doesn’t seem to support this.
> The use case is entries to the Norwegian national summary records, where
> each entry needs to be given a code (of course using a specific, National
> code set) about whether this is a new entry, a change to an existing entry,
> a verification or an refutation. Our hypothesis is to use a specific
> persistent COMPOSITION archetype for these entries, with only one entry per
> composition, and a coded text element to hold the code for the type of
> entry.
>
>
>
> Is there a better way of achieving what we need to do here?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF
>
> Tel. +47 40203298 <+47%20402%2003%20298>
>
> Web: 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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Runtime name suggestions?

[Ian McNicoll]

Thanks Diego,

I was hoping you would confirm that.

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 17 January 2017 at 12:50, Diego Boscá <yamp...@gmail.com> wrote:

> 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 <i...@freshehr.com>:
>
>> 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 <thomas.be...@openehr.org>
>> 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"] = <http://snomed.info/123456789> -- 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 <openehr-technical-boun...@lists.openehr.org>] *On
>>> Behalf Of *Ian McNicoll
>>> *Sent:* Tuesday, January 17, 2017 12:17 PM
>>> *To:* For openEHR technical discussions <openehr-technical@lists.opene
>>> hr.org> <openehr-technical@lists.openehr.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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Use of RM:provider

[Ian McNicoll]

Hi Bjorn,

Thanks - it makes much more sense in the context of Adverse reaction but
TBH I still doubt very much if this 'provenance' source metadata is
captured or known reliably. I asked a couple of UK GP colleagues and they
agreed. I would argue that this data a) often not available b) unreliable
c) a pain in the neck to manage and d) not something you ever want to do
decision support on.

If an allergy has been asserted, it needs to be regarded as positive and
kick decision support into life, no matter how vague the provenance or
potentially unreliable the witness.

But hey, that's what the extension slot in the archetype is for :)

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 18 January 2017 at 10:24, Bjørn Næss <b...@dips.no> wrote:

> Hi
>
> The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of
> information) ) is defined as  “*options to specify the source of data for
> an allergic reaction*” (my translation).
>
>
>
> Which means this is specific for adverse reaction – and I think it should
> be archetyped to model this requirement. If it is only national then there
> should be some extension slots in the Archetypes – or we need some
> specialization of the Archetype to handle this.
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> *Fra:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *På vegne av* Ian McNicoll
> *Sendt:* tirsdag 17. januar 2017 13.43
> *Til:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Emne:* Re: Use of RM:provider
>
>
>
> Hi Thomas,
>
>
>
> I'm not convinced as yet that this is a universally useful requirement,
> particularly as we carry much of this source/ provenance metadata already.
>
>
>
> @Silje - are the GPs expected to add this extra information to every Entry
> in the summary? That seems like a significant burden, and actually in many
> cases unknowable.
>
>
>
> Ian
>
>
>
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <07752%20097859>
> office +44 (0)1536 414994 <01536%20414994>
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> [image:
> https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
>
> 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:34, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>
>
> Ideally there would be one or more classifiers at the ENTRY level,
> something that does not exist today. There are some others that we will
> include, e.g. relating to epistemic_status.
>
> I would follow Ian's suggestion on the extension slot; it may be that the
> coding recorded there may need to be adjusted to a new place in relevant
> archetypes later on. Not ideal, but not a big problem either, assuming they
> are not used to create data before that is done.
>
> Ian - do we have a related PR mooted for RM Release-1.0.4?
>
> - thomas
>
>
>
> On 17/01/2017 11:22, Bakke, Silje Ljosland wrote:
>
> Thank you Thomas and Ian!
>
>
>
> This is indeed a national requirement, and one where we do need to
> represent the chosen value in a coded text element. The background here is
> an entry in the critical information part of the national summary record,
> ie an adverse reaction, complication from anaesthesia, critical condition,
> ongoing treatment, implant, change of treatment routine, or infection. Each
> of these will be either an EVALUATION.adverse_reaction_risk,
> EVALUATION.problem_diagnosis, or EVALUATION.precaution. The patient’s GP
> normally records the information, and this code set is supposed to be used
> to specify where the GP got the information about each of the entries from.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 11:36 AM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org> <openehr-technical@lists.openehr.org>
> *Subject:* Re: Use of RM:p

Re: Runtime name suggestions?

[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
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 17 January 2017 at 12:36, Thomas Beale <thomas.be...@openehr.org> 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"] = <http://snomed.info/123456789> -- 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...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 12:17 PM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org> <openehr-technical@lists.openehr.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.bakke@
> 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

Re: Use of RM:provider

[Ian McNicoll]

Hi Thomas,

I'm not convinced as yet that this is a universally useful requirement,
particularly as we carry much of this source/ provenance metadata already.

@Silje - are the GPs expected to add this extra information to every Entry
in the summary? That seems like a significant burden, and actually in many
cases unknowable.

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 17 January 2017 at 12:34, Thomas Beale <thomas.be...@openehr.org> wrote:

>
> Ideally there would be one or more classifiers at the ENTRY level,
> something that does not exist today. There are some others that we will
> include, e.g. relating to epistemic_status.
>
> I would follow Ian's suggestion on the extension slot; it may be that the
> coding recorded there may need to be adjusted to a new place in relevant
> archetypes later on. Not ideal, but not a big problem either, assuming they
> are not used to create data before that is done.
>
> Ian - do we have a related PR mooted for RM Release-1.0.4?
>
> - thomas
>
> On 17/01/2017 11:22, Bakke, Silje Ljosland wrote:
>
> Thank you Thomas and Ian!
>
>
>
> This is indeed a national requirement, and one where we do need to
> represent the chosen value in a coded text element. The background here is
> an entry in the critical information part of the national summary record,
> ie an adverse reaction, complication from anaesthesia, critical condition,
> ongoing treatment, implant, change of treatment routine, or infection. Each
> of these will be either an EVALUATION.adverse_reaction_risk,
> EVALUATION.problem_diagnosis, or EVALUATION.precaution. The patient’s GP
> normally records the information, and this code set is supposed to be used
> to specify where the GP got the information about each of the entries from.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, January 17, 2017 11:36 AM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org> <openehr-technical@lists.openehr.org>
> *Subject:* Re: Use of RM:provider
>
>
>
> Hi Silje,
>
>
>
> I would agree with your and Thomas's assessment. This codeset does not
> really fit with provider, or indeed with any other RM attributes, although
> many but not all of these items could be calculated/ derived from existing
> attributes.
>
>
>
> I guess this is part of a national requirement, and is a similar issue to
> the one we faced in Sweden, where the V-TIM standard was largely aligned
> with openEHR but had some extra specific metadata around Contsys-2 that
> needed to be captured.
>
>
>
> This was exactly the purpose for the Extension slot that we are adding to
> new archetypes, so that would be my suggestion. Having said that, I do
> wonder about the purpose of this data -where is the value, over and above
> what is already captured by native openEHR RM. This feels like largely a
> derived set of data for reporting purposes
>
> e,g,
>
>
>
> ___
> 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?

[Ian McNicoll]

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:

> Thank you Thomas, to the extent I understand the ADL, this looks like what
> we’re looking for. How would the corresponding syntax look in ADL 1.4?
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Thomas Beale
> *Sent:* Tuesday, January 17, 2017 11:50 AM
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: Runtime name suggestions?
>
>
>
> Hi Silje,
>
> I'm not sure enough of the requirement, but this ADL logic
> 
> may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before
> the following heading after that section.
>
> The basic logic of this is described here
> 
> .
>
> Although these are references from ADL2, they should apply in ADL 1.4 as
> well.
>
> - thomas
>
> On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
>
> Hi,
>
>
>
> We’re trying to finalise the pattern for exclusion archetypes, and would
> like to use the element names to carry some flavor differences such as “no
> known history of …” and “no evidence of …”. We’ve considered adding a
> runtime name constraint to make some level of standardization of these
> statements, but at the same time we recognize that there will be
> considerable variation in what will be required as statements in different
> use cases. So what we’d like to do is to use a kind of “optional runtime
> name constraint”, or “runtime name suggestion”. We know this isn’t
> supported by tooling atm, but is it allowed by the specs? If so, how can it
> be done?
>
>
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
>
> ___
> 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: Use of RM:provider

[Ian McNicoll]

Hi Silje,

I would agree with your and Thomas's assessment. This codeset does not
really fit with provider, or indeed with any other RM attributes, although
many but not all of these items could be calculated/ derived from existing
attributes.

I guess this is part of a national requirement, and is a similar issue to
the one we faced in Sweden, where the V-TIM standard was largely aligned
with openEHR but had some extra specific metadata around Contsys-2 that
needed to be captured.

This was exactly the purpose for the Extension slot that we are adding to
new archetypes, so that would be my suggestion. Having said that, I do
wonder about the purpose of this data -where is the value, over and above
what is already captured by native openEHR RM. This feels like largely a
derived set of data for reporting purposes

e,g,

1. Result of test/analysis

We know that from the archetype name

2.   Observed by treating physician

Captured potentially by provider

3.   Patient’s own information
Party = Self

4.   Information from next of kin
Party = carer

5.   Obtained from other records

Can use Feed_audit but practically very difficult to manage.

6.   Other

7.   Reported by responsible clinician

Captured by composer

Can you tell us more about the background?


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 17 January 2017 at 10:14, Thomas Beale <thomas.be...@openehr.org> wrote:

> Hi Silje,
>
> there is no immediate equivalent of these codes, which have indirect
> equivalents, i.e.
>
>1. Result = OBSERVATION; provider = lab; limited to certain
>archetypes; also comes under SOAP 'O' Heading
>2. Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED
>(physician); limited to certain archetypes; also comes under SOAP 'O'
>Heading
>3. Patient information = OBSERVATION, with provider = PARTY_SELF,
>possibly limited to specific archetypes ; also comes under SOAP 'S' heading
>4. Info from next of kin = OBSERVATION, with provider =
>PARTY_IDENTIFIED (next of kin)
>5. Info from other records = any ENTRY, with FEEDER_AUDIT set
>appropriately
>6. ??
>7. Reported by responsible clinician could be 1, 2, most EVALUATIONs,
>most/all INSTRUCTIONs some or many ACTIONs; provider = PARTY_IDENTIFIED
>(clinician)
>
> I'd say it can be mostly set by using ENTRY.provider. 5 is a different
> thing - it's about provenance of data obtained from elsewhere. Presumably 6
> means 'not any of 1-5 or 7'.
>
> I'd also say it isn't a very well designed code-set, and I don't know what
> use it would be in real life...
>
> - thomas
>
> On 16/01/2017 13:14, Bakke, Silje Ljosland wrote:
>
> Hi everyone,
>
>
>
> I’ve got a problem about where to put non-identifying information about
> the source of information for an ENTRY. The value set we need to store is
> the code set identified by the OID 2.16.578.1.12.4.1.7498 (Source of
> information), as following:
>
>
>
> 1.   Result of test/analysis
>
> 2.   Observed by treating physician
>
> 3.   Patient’s own information
>
> 4.   Information from next of kin
>
> 5.   Obtained from other records
>
> 6.   Other
>
> 7.   Reported by responsible clinician
>
>
>
> Our first hypothesis was that the reference model element “provider”
> should be used for this, but then someone pointed out that the “provider”
> should be an identifiable person or entity, and not just a generalised
> coded text like this. So, where should this information go, if not in
> RM:provider?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF
>
>
>
> ___
> 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?

[Ian McNicoll]

Hi Bert,

Sorry - I should have made that clearer - it is also on the agenda.

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 4 January 2017 at 12:18, Bert Verhees <bert.verh...@rosa.nl> wrote:
> Please, Ian, also discuss an announcementlist for free and open source
> software (my favour is read-only, announcements only), and, also your own
> suggestion, to have a low fee membership for single person or low income
> business
>
> Thanks
> Bert
>
> Op wo 4 jan. 2017 om 13:02 schreef Ian McNicoll <i...@freshehr.com>:
>>
>> Thanks for the input everyone. My feeling is that Discourse is worth a
>> small experiment but we will discuss at the Mgt Board meeting in a
>> couple of weeks.
>>
>> 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 2 January 2017 at 10:35, Pekka Pesola <pekka.pes...@gmail.com> wrote:
>> > I agree that the channels need to be well thought but i also think the
>> > community needs the best available platform for communication. I don't
>> > find
>> > the current solution inviting to new members at all. Web archive lacks a
>> > good search and replying to old threads is not possible trough web
>> > archive.
>> >
>> > That is in the end what implementers will do. When the specs don't
>> > explicitly cover something they will search for information on how
>> > others
>> > have done the same thing and ask if required - this should be super easy
>> > and
>> > usable.
>> >
>> > -Pekka
>> >
>> > On Fri, Dec 30, 2016 at 4:41 PM, Pablo Pazos <pablo@gmail.com>
>> > wrote:
>> >>
>> >> IMO we are over-engineering things that can be solved by agreeing on a
>> >> set
>> >> of rules. We even have two lists technical and implements and there
>> >> might be
>> >> just one.
>> >>
>> >> The active members of the community that participate in these channels
>> >> is
>> >> low. Adding more communication channels will just disperse the
>> >> community.
>> >>
>> >> We need less channels and usage rules.
>> >>
>> >>
>> >>
>> >> On Dec 30, 2016 6:18 AM, "Thomas Beale" <thomas.be...@openehr.org>
>> >> wrote:
>> >>>
>> >>>
>> >>> Following from what you and Bert have said, it seems that the
>> >>> following
>> >>> could make sense:
>> >>>
>> >>> Foundation announcements list / channel (= openehr-announce list we
>> >>> have
>> >>> now)
>> >>> software / libraries / tools announcements (= web home page news items
>> >>> with cog icon, also here)
>> >>>
>> >>> this includes open source software libs / projects
>> >>>
>> >>> commercial product offerings - currently we don't really have a way of
>> >>> doing this, but Industry Partners can post on web home page (factory
>> >>> icon)
>> >>>
>> >>> I'm not sure what the right approach is, since there are many
>> >>> technical
>> >>> possibilities.
>> >>>
>> >>> Marcus Baw has proposed moving to Discourse as a forum platform -
>> >>> maybe
>> >>> this is the kind of thing we should look at?
>> >>>
>> >>> - thomas
>> >>>
>> >>>
>> >>> On 29/12/2016 17:16, Diego Boscá wrote:
>> >>>
>> >>> Well, we will provide for free a product that was behind a paywall
>> >>> before (LinkEHR lite was the free version we had, and now the 'basic'
>> >>> and free version is the equivalent to the past LinkEHR editor). I'm
>> >>> curious what kind of announcement we could make :)
>> >>>
>> >>>
>&

Re: Better approach for announcements, forums?

[Ian McNicoll]

Thanks for the input everyone. My feeling is that Discourse is worth a
small experiment but we will discuss at the Mgt Board meeting in a
couple of weeks.

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 2 January 2017 at 10:35, Pekka Pesola <pekka.pes...@gmail.com> wrote:
> I agree that the channels need to be well thought but i also think the
> community needs the best available platform for communication. I don't find
> the current solution inviting to new members at all. Web archive lacks a
> good search and replying to old threads is not possible trough web archive.
>
> That is in the end what implementers will do. When the specs don't
> explicitly cover something they will search for information on how others
> have done the same thing and ask if required - this should be super easy and
> usable.
>
> -Pekka
>
> On Fri, Dec 30, 2016 at 4:41 PM, Pablo Pazos <pablo@gmail.com> wrote:
>>
>> IMO we are over-engineering things that can be solved by agreeing on a set
>> of rules. We even have two lists technical and implements and there might be
>> just one.
>>
>> The active members of the community that participate in these channels is
>> low. Adding more communication channels will just disperse the community.
>>
>> We need less channels and usage rules.
>>
>>
>>
>> On Dec 30, 2016 6:18 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote:
>>>
>>>
>>> Following from what you and Bert have said, it seems that the following
>>> could make sense:
>>>
>>> Foundation announcements list / channel (= openehr-announce list we have
>>> now)
>>> software / libraries / tools announcements (= web home page news items
>>> with cog icon, also here)
>>>
>>> this includes open source software libs / projects
>>>
>>> commercial product offerings - currently we don't really have a way of
>>> doing this, but Industry Partners can post on web home page (factory icon)
>>>
>>> I'm not sure what the right approach is, since there are many technical
>>> possibilities.
>>>
>>> Marcus Baw has proposed moving to Discourse as a forum platform - maybe
>>> this is the kind of thing we should look at?
>>>
>>> - thomas
>>>
>>>
>>> On 29/12/2016 17:16, Diego Boscá wrote:
>>>
>>> Well, we will provide for free a product that was behind a paywall
>>> before (LinkEHR lite was the free version we had, and now the 'basic'
>>> and free version is the equivalent to the past LinkEHR editor). I'm
>>> curious what kind of announcement we could make :)
>>>
>>>
>>>
>>> ___
>>> 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

___
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?

[Ian McNicoll]

Hi Karsten

As Diego has suggested, discourse can be used in news server mode both to
receive and respond to posts. That is mostly how I use it for the uk ccio
lists.

Ian
On Fri, 30 Dec 2016 at 11:31, Diego Boscá  wrote:

> 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
___
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?

[Ian McNicoll]

Discourse has certainly worked pretty well for the Uk CCIO network.

Any objections to us giving it a trial, perhaps initially for 'general
discussion' and 'community news' tracks.

Picking up on Bert's earlier suggestion, is there room for a
'professional' membership category, costing just under 100 euro per
annum? Essentially the same as individual membership but giving very
small commercial entities, the ability to post news of software and
educational 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 30 December 2016 at 10:16, Pekka Pesola <pekka.pes...@gmail.com> wrote:
> I agree - moving to some kind of a forum would in overall work much better
> than mailing lists.
>
> -Pekka
>
> On Fri, Dec 30, 2016 at 11:17 AM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>>
>>
>> Following from what you and Bert have said, it seems that the following
>> could make sense:
>>
>> Foundation announcements list / channel (= openehr-announce list we have
>> now)
>> software / libraries / tools announcements (= web home page news items
>> with cog icon, also here)
>>
>> this includes open source software libs / projects
>>
>> commercial product offerings - currently we don't really have a way of
>> doing this, but Industry Partners can post on web home page (factory icon)
>>
>> I'm not sure what the right approach is, since there are many technical
>> possibilities.
>>
>> Marcus Baw has proposed moving to Discourse as a forum platform - maybe
>> this is the kind of thing we should look at?
>>
>> - thomas
>>
>>
>> On 29/12/2016 17:16, Diego Boscá wrote:
>>
>> Well, we will provide for free a product that was behind a paywall
>> before (LinkEHR lite was the free version we had, and now the 'basic'
>> and free version is the equivalent to the past LinkEHR editor). I'm
>> curious what kind of announcement we could make :)
>>
>>
>>
>> ___
>> 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: Cloud EHRServer is about to be launched

[Ian McNicoll]

First of all best wishes to everyone in 2017 and congratulations to Pablo.

For clarification, the Announce list is indeed for Foundation use only, and
we would generally discourage postings of a commercial nature on these
lists.

Having said that, I think we can cut Pablo, and other similar community
projects, a little slack.  I'd just ask posters to try to keep the
commercial aspects of any similar announcement e.g. any fees/ conditions,
out of the main post and just put in a link for those who want to purse it.

And, of course anyone who is moving into a more commercial space, might
want to consider becoming an Industry partner and taking advantage of the
new 'Micro Startup' rates http://members.openehr.org/join-us !! That allows
us to give your project/company much more visibility on the openEHR site
and access to the Industry News page.

Ian

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


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

On 28 December 2016 at 08:04, Bert Verhees <bert.verh...@rosa.nl> wrote:

> > there is no other way to reach the community and the announcing list is
> used by the openEHR Foundation Board, not by community members
>
> Great Pablo, congratulations. Good work. Important for the community.
>
> I think this issue needs to be repaired soon. It must be the Christmas
> period that there is no reaction from the Foundation now.
>
> Best regards
> Bert
>
> Op wo 28 dec. 2016 07:18 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:
>
>> Dear friends,
>>
>> First thanks a lot for all your private emails supporting me on this new
>> challenge and for the people that believes that initiatives like this one
>> are of a great value to our community, since clinical data storage is an
>> open problem in the openEHR world.
>>
>>
>> Some updates!
>>
>> The website is up and running: https://cloudehrserver.com/
>>
>> If you detect any errors please let me know.
>>
>> It has some basic information and guides. I'll be adding more guides and
>> tech docs soon.
>>
>> In the community section you can find client libraries I created for PHP,
>> Javascript and Groovy. Basically are helpers and sample code to help you on
>> using the EHRServer REST API. If you want to create a client for another
>> language, please let me know!
>>
>> Also there is a project called openEHR-OPT: a command line tool that
>> allows to 1. generate HTML GUI from an OPT, 2. generate XML instances from
>> an OPT (VERSION or just COMPOSITION), 3. validate XML instances using the
>> openEHR XSD.
>>
>> All the aforementioned tools are open source, as the EHRServer itself,
>> designed & developed by me in the last couple of years.
>>
>>
>> For know the full documentation is the EHRServer guide that can be found
>> here: http://cabolabs.com/en/projects
>>
>> Please let me know if you have any questions.
>>
>>
>> Happy new year for everyone!
>>
>> Kind regards,
>> Pablo.
>>
>> PS: yes, I use these lists because there is no other way to reach the
>> community and the announcing list is used by the openEHR Foundation Board,
>> not by community members. I though a lot about this, and I firmly believe
>> this is of value to the openEHR community as a whole and that is the most
>> important aspect than if I charge money to use the service. As I mentioned,
>> this is an open source development and the fee is to maintain
>> infrastructure and allow further development of the tool. Without this
>> support the project will just die, since it is just me designing and
>> developing, staying up late at night, using my weekends to work on the
>> project, etc. and it has been that way since 2009 when I started with my
>> first PoC for an openEHR backend. Please consider this and I ask for a
>> little understanding. Thanks.
>>
>>
>>
>> On Mon, Dec 26, 2016 at 2:22 AM, Pablo Pazos <pablo.pa...@cabolabs.com>
>> wrote:
>>
>> Dear friends,
>>
>> I'm about to launch the Cloud EHRServer, a clinical data repository /
>> health information system backend as a service. I'm very excited about
>> this, since I invested a lot on the EHRServer development and now it seems
>> natural to take this next step to make further development sustainable in
>> time.
>>
>> This SaaS is based on the EHRServer, the first open source openEHR
>> clinical data repository, I've been d

Re: SV: Could the specs group consider making uid mandatory?

[Ian McNicoll]

In the context of exposing a unique Identifier at Entry level e.g for
FHIR mapping, I wondered about concatenating the composiitonUid (inc.
version) with an Entry UID. i.e Versioning (as now) is handled at
composition/contribution level.

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 19 December 2016 at 08:30, Thomas Beale <thomas.be...@openehr.org> wrote:
>
> On 16/12/2016 02:37, Bjørn Næss wrote:
>
> If you add UID on ENTRY level and you want to use that for some
> referencing/look up functionality:
> How do you handle versioning of Compositions and its content?  Is it a new
> entry UID for each version ?
>
>
> same UID across versions. There is a way to identify versions of things,
> explained here (mainly), and a less detailed overview here.
>
> - 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