Re: data element type from the RM

[Pablo Pazos]

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

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

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


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://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

Re: API for adding data to an EHR

[Pablo Pazos]

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

Re: templates in .oet and .opt

[Pablo Pazos]

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

Modeling tool: current version and latest release date

[Pablo Pazos]

Hi all, when looking at the modeling tools page, I think it would be good
to add more information like:

1. current version number
2. latest release date (we have very old tools there and some that are
currently being updated)
3. RM versions supported (also different tools support different RM
versions and some only one version, like the AE)

This information will be useful to pick the right tool for each project,
and if we have tools that are not longer being maintained, it is also good
to mention that there.

That info is also useful for newcomers.

What do others think?

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

Re: AQL query for blood pressure from the AQL documentation

[Pablo Pazos]

it's a typo in the spec, should be value/magnitude

On Mon, Apr 29, 2019 at 6:50 PM 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
>
> --
> -
> 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

Re: Automation with openEHR & SNOMED-CT ontology reasoning

[Pablo Pazos]

BTW, the querying we use is not AQL, is what we call path-based queries,
that is explained here
https://docs.google.com/document/d/1pGJXIWHCgjyiofLmNHRTG7UFuB-tVWzm625X5rkiHiw/edit?usp=sharing

On Tue, Mar 26, 2019 at 9:22 AM Pablo Pazos 
wrote:

> If the idea is to get openEHR data based on the SNOMED CT structure, we
> have been doing that for a while
> https://www.youtube.com/watch?v=JIolq3b_Gkw=5=PL-4c1WHznyulrf8wPhaOq7T0E2QWQMCHH
>
> On Mon, Mar 25, 2019 at 1:03 AM Erik Sundvall 
> wrote:
>
>> Hi all openEHR+Snomed CT hackers!
>>
>> Doing the inference described below using a reasoner and openEHR with
>> AQL+api calls as a bridge to EHR content would be pedagogical.
>>
>> Who in the openEHR community will get a demo video out first?
>>
>> Good luck with this little challenge!
>>
>> Best regards,
>> Erik Sundvall
>>
>> --
>> *Från:* Yosemite Project 
>> *Skickat:* måndag, mars 25, 2019 3:25 fm
>> *Till:* yosemiteproj...@googlegroups.com; i...@lists.hl7.org; w3c semweb
>> HCLS
>> *Ämne:* Tutorial on FHIR/RDF with SNOMED-CT ontology, including
>> 90-second video
>>
>> I am pleased to announce a short hands-on tutorial on using FHIR/RDF
>> with the SNOMED-CT ontology:
>> http://tinyurl.com/fhir-rdf-snomed-tut
>>
>> Try it out! A 90-second video also demonstrates the steps:
>> https://youtu.be/NjNdo0GyieU
>>
>> The tutorial is based on a previous webinar by Harold Solbrig:
>> https://goo.gl/6WYH1C
>>
>> P.S. We are also interested in hearing about other projects that are
>> using or planning to use FHIR/RDF. Please email da...@dbooth.org .
>>
>> Enjoy!
>> David Booth
>> Yosemite Project
>>
>> ___
>> 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
>
>

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

Re: Automation with openEHR & SNOMED-CT ontology reasoning

[Pablo Pazos]

If the idea is to get openEHR data based on the SNOMED CT structure, we
have been doing that for a while
https://www.youtube.com/watch?v=JIolq3b_Gkw=5=PL-4c1WHznyulrf8wPhaOq7T0E2QWQMCHH

On Mon, Mar 25, 2019 at 1:03 AM Erik Sundvall  wrote:

> Hi all openEHR+Snomed CT hackers!
>
> Doing the inference described below using a reasoner and openEHR with
> AQL+api calls as a bridge to EHR content would be pedagogical.
>
> Who in the openEHR community will get a demo video out first?
>
> Good luck with this little challenge!
>
> Best regards,
> Erik Sundvall
>
> --
> *Från:* Yosemite Project 
> *Skickat:* måndag, mars 25, 2019 3:25 fm
> *Till:* yosemiteproj...@googlegroups.com; i...@lists.hl7.org; w3c semweb
> HCLS
> *Ämne:* Tutorial on FHIR/RDF with SNOMED-CT ontology, including 90-second
> video
>
> I am pleased to announce a short hands-on tutorial on using FHIR/RDF
> with the SNOMED-CT ontology:
> http://tinyurl.com/fhir-rdf-snomed-tut
>
> Try it out! A 90-second video also demonstrates the steps:
> https://youtu.be/NjNdo0GyieU
>
> The tutorial is based on a previous webinar by Harold Solbrig:
> https://goo.gl/6WYH1C
>
> P.S. We are also interested in hearing about other projects that are
> using or planning to use FHIR/RDF. Please email da...@dbooth.org .
>
> Enjoy!
> David Booth
> Yosemite Project
>
> ___
> 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

Re: serialization syntax of openEHR instance data

[Pablo Pazos]

Please let me know if you find any issues when using it:
https://github.com/ppazos/openEHR-OPT/issues

On Fri, Feb 22, 2019 at 8:28 AM Georg Fette 
wrote:

> Hello,
> Thank you all. The .xsds are already very useful. And the Toolkit also
> looks beneficial for what I want to do.
> 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

Re: serialization syntax of openEHR instance data

[Pablo Pazos]

Adding to Thomas comments,

1. Yes, XML XSDs should be the source of truth here
2. You can use the openEHR Toolkit to generate instances in XML from an OPT
http://server001.cloudehrserver.com/cot/

That helps testing and verifying formats.

On Thu, Feb 21, 2019 at 5:45 AM Thomas Beale 
wrote:

> You may want to look at the XSDs here on Github
> <https://github.com/openEHR/specifications-ITS-XML/tree/master/components>
> and JSON schemas (emerging) here
> <https://github.com/openEHR/specifications-ITS-JSON>.
> On 21/02/2019 08:14, Georg Fette wrote:
>
> Hello,
> Is there a documentation of the syntax how openEHR EHR data is serialized
> ? I would be interested in a concrete example of an EHR-API-GET-call and
> the returned String in XML or JSON which can be used as transfer medium
> between applications or as a storage format. It would be beneficial if the
> example EHR would contain some commonly used archetypes and some usual
> demographics data.
> I have taken a look at
> https://openehr.github.io/specifications-ITS-REST/ehr.html and at the
> "EHR Extract Information Model" but I haven't found something that satified
> me in this matter.
> Greeting
> 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
>


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

Re: openEHR on FHIR and vice versa

[Pablo Pazos]

A library of mappings sounds like a great idea, another type of artifact
for the CKM maybe?

I believe the LinkEHR mapper has the ability of constructing such mappings
in a processable format that can be shared. Diego? :)

On Tue, Dec 18, 2018 at 7:04 PM Heath Frankel <
heath.fran...@oceanhealthsystems.com> wrote:

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

Re: openEHR on FHIR and vice versa

[Pablo Pazos]

On Tue, Dec 18, 2018 at 2:50 PM Thomas Beale 
wrote:

>
> On 18/12/2018 17:04, Pablo Pazos wrote:
>
> Yes, in fact the closest we can get to automatic transformations is just
> defining the mappings between openEHR classes and the correspondent FHIR
> resources, and feed that to a system that, for a specific openEHR instance,
> provides a mapper user with constrained options of FHIR resources to choose
> from, and vice-versa, given a FHIR resource, provide the options of openEHR
> classes to map to. Then will end up mapping fields of correspondent types.
> No magic here for now :(
>
> this will not generally work. There is no logic to what is in FHIR
> resources. For example, there is no openEHR class matching the FHIR
> resource 'MedicationAdministration'. The latter has attributes mostly
> matching various Medication archetypes, but is more like a template than an
> archetype. But it also has some attributes matching openEHR context (RM)
> attributes, e.g. subject, context, performer etc. And some things that
> really just should not be there, like eventHistory. And things unlikely to
> work, e.g. 'instantiates'. And some strange things like the pair reasonCode
> (reason why administration performed) and statusReason (reason why the
> administration was not performed).
>
I'm not implying each FHIR resource has a correspondent openEHR class or
vice-versa. To be correct, I should add "create the mappings that can be
done at the IM level", other mappings, might be done between a FHIR
resource and an openEHR archetype or archetypes (like
MedicationAdministration), and others might be done between a FHIR profile
and an openEHR archetype/s. The point was: without this, the
transformations are 100% manual, with this, the transformations can be
assisted at some point, but this is far from automatic transformations.



> But then go have a look at FHIR Observation, and you see it is much more
> generic, but very inflexible. To find e.g. Blood Pressure (measurement) you
> have to find a profile, like this one on simplifier.net
> <https://simplifier.net/coreprofilesstu3/bp>. This gets rid of the main
> valueQuantity and then packs in the required BP structure (or at least a
> bit of it) as a free-tree 'component' at the bottom.
>
> I have been unable to ascertain any scientific or formal principles on
> which FHIR modelling is based, which is something you need in order to
> write a model converter (unless your converter just has new code for every
> single model).
>
> I don't claim that openEHR RM or archetypes are perfect by any means, but
> they have many underpinning principles which are generally followed, and
> that enables one to write the openEHR side of any converter based on those
> principle, with exceptional handling for places where we made a mistake or
> there is an anomaly.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: openEHR on FHIR and vice versa

[Pablo Pazos]

Yes, in fact the closest we can get to automatic transformations is just
defining the mappings between openEHR classes and the correspondent FHIR
resources, and feed that to a system that, for a specific openEHR instance,
provides a mapper user with constrained options of FHIR resources to choose
from, and vice-versa, given a FHIR resource, provide the options of openEHR
classes to map to. Then will end up mapping fields of correspondent types.
No magic here for now :(

But I believe this process can be more intelligent, if we add extra
metadata to the definitions (like SNOMED CT annotations with concept ids
and expressions), and we have a lot of instance samples where AI algorithms
can run on and detect semantic matches. Still, a human needs to do some
manual work, but maybe less with the extra help of metadata+AI.

Thinking of 100% automatic generic transformations between any instance of
two different information models is currently just science fiction IMHO :),
or for a political correct answer: it is an open problem.

On Tue, Dec 18, 2018 at 7:58 AM Ian McNicoll  wrote:

> I agree Pablo and we have to remember that the number of high-quality,
> truly interoperable FHIR profiles is going to be very small for a long time.
>
> @Dileep V S  - we have started to put FHIR
> bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will
> between local FHIR profiles
>  and local templates - see
> https://github.com/inidus/openehr-care-connect-adaptor
>
> There are various attempts at automation including the Ripple QEWD Jumper
> work https://www.youtube.com/watch?v=iaGGGgJdWvM but it will still need
> quite a lot of manual input.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Mon, 17 Dec 2018 at 18:26, Pablo Pazos 
> wrote:
>
>> I also did some mapping work FHIR -> openEHR using Mirth, but this is
>> ad-hoc, no automatic mapping yet, for that you need to define a lot of
>> constraints to make it work automatically. Maybe some semi-automatic tool
>> come out in the future, assisting architects on doing such mappings, either
>> way some kind of human intervention will be needed to define mapping
>> criteria when there are  1 to * mapping possibilities.
>>
>> On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden 
>> 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,
>&

Re: openEHR on FHIR and vice versa

[Pablo Pazos]

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


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

Re: openEHR-technical Digest, Vol 80, Issue 12

[Pablo Pazos]

Hi Ricardo,

Yes, I've integrated SNOMED Expressions into our path-based queries, that
is basically another syntax for openEHR queries, alternative to AQL.

What I did was adding the operator in_snomed_exp associated to
DV_CODED_TEXT, so you can say something like "retrieve all the compositions
that contain a path to a DV_CODED_TEXT, such as the code value on that is
in a expression e. This is at the syntax / query building level.

At the query evaluation level, if the evaluator finds a in_snomed_exp
operator, it resolves the expression e against a SNOMED CT expression
expansion service, provided by our partner VeraTech, and the expanded
expression is integrated into an SQL query, generated from the path-based
query evaluation. This mixed with complex conditions on other nodes, gives
a lot of possibilities on what can be done with the query results. Our
focus is CDS, so we mainly want those results to feed CDS rules.

Hope this helps to understand our approach.

Best,
Pablo.


On Mon, Nov 19, 2018 at 4:56 PM Ricardo Gonçalves 
wrote:

> Hi all,
>
> It's been a while since I've seen it but I think Pablo Pazos has some
> quite good work for that topic on EHRServer, at least for subsumption [
> https://ppazos.github.io/cabolabs-ehrserver/ mentions "Support of SNOMED
> CT Expressions on openEHR queries (simplifies complex queries)"]. There is
> also a demonstration video on YouTube. With regards to binding to the
> model, though, things might be tricky.
>
> Cheers,
> Ricardo Gonçalves.
>
> Em seg, 19 de nov de 2018 às 17:21, <
> openehr-technical-requ...@lists.openehr.org> escreveu:
>
>> Send openEHR-technical mailing list submissions to
>> openehr-technical@lists.openehr.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>> or, via email, send a message with subject or body 'help' to
>> openehr-technical-requ...@lists.openehr.org
>>
>> You can reach the person managing the list at
>> openehr-technical-ow...@lists.openehr.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openEHR-technical digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Postcoordinated terminology expressions in openEHR
>>   (Thomas Beale)
>>2. Re: Postcoordinated terminology expressions in openEHR
>>   (Ian McNicoll)
>>
>>
>> --
>>
>> Message: 1
>> Date: Mon, 19 Nov 2018 15:38:52 +
>> From: Thomas Beale 
>> To: openehr-technical@lists.openehr.org
>> Subject: Re: Postcoordinated terminology expressions in openEHR
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> 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 archetyp

Re: AQL on versioned compositions

[Pablo Pazos]

Hi Dileep, from your description of complaint/diagnosis usage, it feels
that should be a persistent composition. And as I see it, for clinical use,
the last version is the one that should be used. Review of previous
versiosn of data is more for audit IMO.


Best,
Pablo.

On Tue, Oct 30, 2018 at 8:44 AM Dileep V S  wrote:

> Hi Ian,
>
> If we take an OP episode, it will consist of possibly a screening
> encounter, then a consult encounter and one or more revisit encounters. We
> will start with recording data such as complaints, diagnosis, medication
> order etc . This data will be reviewed and updated in every subsequent
> encounters. So a complaint/diagnosis recorded in the consult may get marked
> as resolved during one of the subsequent revisits or sometimes something
> new gets added. A medication order made during the consult may get
> discontinued and another added later
>
> The folders representing each of the encounters maintain a pointer to the
> corresponding versions of the composition so that the snapshot of the
> patient status is preserved and can be accessed(using an aql of versioned
> composition) any time into the future.
>
> We are not using persistent compositions anywhere. To display a persistent
> status(Active complaints, diagnosis or medications), we use an aql to
> filter on status to display the relevant information. We expect that the
> doctor will review and update status of active items during an encounter.
> This is important for us as we are approaching the problem from a person
> centric view where the health status of the person concerned is evolving
> with every health encounter. Our patient summary is thus, always the last
> known status of the person.
>
> By default the clinical information view is limited to an episode using
> virtual folders. But a summary view across episodes is also possible if we
> run the query outside the virtual folder context. Also in our case the
> compositions can get versioned as an episode progresses.
>
> I hope that helps. Do feel free to point out any problems with our approach
>
> 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 Tue, Oct 30, 2018 at 3:02 PM, Ian McNicoll  wrote:
>
>> 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
>> 

Re: DV_DURATION and magnitude_status?

[Pablo Pazos]

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

Re: DV_DURATION and magnitude_status?

[Pablo Pazos]

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


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

Re: Inconclusive lab results coding

[Pablo Pazos]

You are awesome :)

On Mon, Sep 17, 2018, 04:32 David Moner  wrote:

> You should contact your national representative, since Uruguay is a member
> country. It is AGESIC (sno...@salud.uy)
>
> El lun., 17 sept. 2018 a las 5:34, Pablo Pazos ()
> escribió:
>
>> Need to check how to contact HITSDO, I already contacted LOINC about
>> missing codes related to this topic :)
>>
>> On Mon, Sep 17, 2018 at 12:20 AM Heather Leslie <
>> heather.les...@atomicainformatics.com> wrote:
>>
>>> Terrific, Pablo. Didn’t want to run the risk of you missing the cervical
>>> cytology codes that are present.
>>>
>>>
>>>
>>> A post coordinated solution is a good work around, but wonder if it is
>>> worth requesting SNOMED for the addition of new codes for the ones that
>>> you’ve identified as missing. If you need them, then there is a very good
>>> chance that others might as well.
>>>
>>>
>>>
>>> And if there is a better solution then SNOMED Intl might be able to
>>> point us to them.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> Heather
>>>
>>>
>>>
>>>
>>>
>>> *From:* openEHR-technical  *On
>>> Behalf Of *Pablo Pazos
>>> *Sent:* Monday, 17 September 2018 12:31 PM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@lists.openehr.org>
>>> *Subject:* Re: Inconclusive lab results coding
>>>
>>>
>>>
>>> Thanks Heather, I got those codes in the cervical cytology findings,
>>> found the "normal" and the "abnormal" concepts, but not a code for the grey
>>> area in the middle of those, that, from my research, seems to be a valid
>>> outcome from a PAP test with something like "Not clear (not conclusive)".
>>>
>>>
>>>
>>> On Tue, Sep 11, 2018 at 2:57 AM Heather Leslie <
>>> heather.les...@atomicainformatics.com> wrote:
>>>
>>> Hi Pablo,
>>>
>>>
>>>
>>> There is a hierarchy specifically for cervical cytology findings – see
>>> Cervical smear result (finding)
>>>
>>> SCTID: 269957009 and below.
>>>
>>>
>>>
>>> So for CEASI o ASCUS the code from that hierarchy would likely be
>>> 441087007
>>>
>>>
>>>
>>> I haven’t had time to look at all, but I suspect this is a better
>>> hierarchy and there may not be all options available for you. There are
>>> lots of gaps in SNOMED!
>>>
>>>
>>>
>>> Hope this helps
>>>
>>> Heather
>>>
>>>
>>>
>>> *From:* openEHR-technical  *On
>>> Behalf Of *Pablo Pazos
>>> *Sent:* Tuesday, 11 September 2018 2:26 PM
>>> *To:* For openEHR technical discussions <
>>> openehr-technical@lists.openehr.org>
>>> *Subject:* Inconclusive lab results coding
>>>
>>>
>>>
>>> Hi all, lately I've been modeling different types of lab results.
>>>
>>>
>>>
>>> Now I'm modeling cervical cytology, and there is a kind of result that
>>> is "inconclusive or not clear", for other results I've found SNOMED CT
>>> codes but not for this one. That is the only one that I can't code right
>>> now, maybe others with more experience on this area can help me find a code.
>>>
>>>
>>>
>>> This is what I have right now, sorry rubrics are in spanish (but is easy
>>> to just put the codes in the SNOMED browser to see the concept in english
>>> http://browser.ihtsdotools.org/?perspective=full=404684003=en-edition=v20180731=http://browser.ihtsdotools.org/api/v1/snomed=9000509007
>>> ):
>>>
>>>
>>>
>>> + Normal (negativo): SNOMED-CT::5559008
>>> + Poco claro (no concluyente)
>>> + Anormal (positivo)
>>>   + CEASI o ASCUS (células escamosas atípicas de signigicado
>>> indeterminado): SNOMED-CT::39035006
>>>   + CGA (células grandulares atípicas): SNOMED-CT::4476003
>>>   + LIEBG (lesiones intraepiteliales escamosas de grado bajo):
>>> SNOMED-CT::112662005
>>>   + LIEAG (lesiones intraepiteliales escamosas de grado alto):
>>> SNOMED-CT::22725004
>>>   + CEA (células escamosas atípicas, no se pueden excluir las LIEAG):
>>> SNOMED-CT::373878001
>>>   + AIS (adenocarcinoma in situ): SNOMED-CT::51642000
>>> 

Re: Inconclusive lab results coding

[Pablo Pazos]

Need to check how to contact HITSDO, I already contacted LOINC about
missing codes related to this topic :)

On Mon, Sep 17, 2018 at 12:20 AM Heather Leslie <
heather.les...@atomicainformatics.com> wrote:

> Terrific, Pablo. Didn’t want to run the risk of you missing the cervical
> cytology codes that are present.
>
>
>
> A post coordinated solution is a good work around, but wonder if it is
> worth requesting SNOMED for the addition of new codes for the ones that
> you’ve identified as missing. If you need them, then there is a very good
> chance that others might as well.
>
>
>
> And if there is a better solution then SNOMED Intl might be able to point
> us to them.
>
>
>
> Regards
>
>
>
> Heather
>
>
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Pablo Pazos
> *Sent:* Monday, 17 September 2018 12:31 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: Inconclusive lab results coding
>
>
>
> Thanks Heather, I got those codes in the cervical cytology findings, found
> the "normal" and the "abnormal" concepts, but not a code for the grey area
> in the middle of those, that, from my research, seems to be a valid outcome
> from a PAP test with something like "Not clear (not conclusive)".
>
>
>
> On Tue, Sep 11, 2018 at 2:57 AM Heather Leslie <
> heather.les...@atomicainformatics.com> wrote:
>
> Hi Pablo,
>
>
>
> There is a hierarchy specifically for cervical cytology findings – see
> Cervical smear result (finding)
>
> SCTID: 269957009 and below.
>
>
>
> So for CEASI o ASCUS the code from that hierarchy would likely be 441087007
>
>
>
> I haven’t had time to look at all, but I suspect this is a better
> hierarchy and there may not be all options available for you. There are
> lots of gaps in SNOMED!
>
>
>
> Hope this helps
>
> Heather
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Pablo Pazos
> *Sent:* Tuesday, 11 September 2018 2:26 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Inconclusive lab results coding
>
>
>
> Hi all, lately I've been modeling different types of lab results.
>
>
>
> Now I'm modeling cervical cytology, and there is a kind of result that is
> "inconclusive or not clear", for other results I've found SNOMED CT codes
> but not for this one. That is the only one that I can't code right now,
> maybe others with more experience on this area can help me find a code.
>
>
>
> This is what I have right now, sorry rubrics are in spanish (but is easy
> to just put the codes in the SNOMED browser to see the concept in english
> http://browser.ihtsdotools.org/?perspective=full=404684003=en-edition=v20180731=http://browser.ihtsdotools.org/api/v1/snomed=9000509007
> ):
>
>
>
> + Normal (negativo): SNOMED-CT::5559008
> + Poco claro (no concluyente)
> + Anormal (positivo)
>   + CEASI o ASCUS (células escamosas atípicas de signigicado
> indeterminado): SNOMED-CT::39035006
>   + CGA (células grandulares atípicas): SNOMED-CT::4476003
>   + LIEBG (lesiones intraepiteliales escamosas de grado bajo):
> SNOMED-CT::112662005
>   + LIEAG (lesiones intraepiteliales escamosas de grado alto):
> SNOMED-CT::22725004
>   + CEA (células escamosas atípicas, no se pueden excluir las LIEAG):
> SNOMED-CT::373878001
>   + AIS (adenocarcinoma in situ): SNOMED-CT::51642000
>   + Células de cáncer cervical (carcinoma de células escamosas o
> adenocarcinoma): SNOMED-CT::285432005
>
>
>
>
>
> Thanks!
>
>
> --
>
> *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>
>
> [image:
> https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]
> <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
>
>
>
> --
>
> *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>
>
> [image:
> https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]
> <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
>


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

Re: Re: Generic modeling and issues for querying

[Pablo Pazos]

Solution is easy, just created specific structures for the results of some
test that I needed to store and query so I have different node ids on each
analyte. That will allow me to query, create some CDS rules and some fancy
indicators for reports :)

On Sun, Sep 16, 2018 at 7:36 AM Karsten Hilbert 
wrote:

> > openEHR data representation and querying are founded upon this
> > fundamental principle - store how you like, query how you like.
>
> OK, as long as "store how you like" does not impede
> "query how you like", the principle seems reasonable.
>
> Karsten
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
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

Re: Inconclusive lab results coding

[Pablo Pazos]

That makes me think that I can create a post coordinated expression with
the inconclusive and the cervical cytology (procedure) or (findings)
concepts :)

On Sun, Sep 16, 2018 at 10:16 PM Seung Jong Yu  wrote:

> Hi Pablo Pazos
>
> I searched "inconclusive or not clear" (with/without cervical cytology) in
> my mapping tool (http://term.infoclinic.co/map.html)
>
> There may be not terms of "inconclusive or not clear" confined to
>  "Cervical Cytology".
>
> Some general terms were searched.
>
> In qualifier value, related terms are below
>
>  419984006 |Inconclusive (qualifier value)|
>  373068000 |Undetermined (qualifier value)|
>  82334004 |Indeterminate (qualifier value)|
>
> In finding, I think below is proper
>
>  442754001 |Inconclusive evaluation finding (finding)|
>
> I hope this will help you.
>
> Best regards
>
> From Seung-Jong Yu
>
>
> 2018년 9월 11일 (화) 오후 1:27, Pablo Pazos 님이 작성:
>
>> Hi all, lately I've been modeling different types of lab results.
>>
>> Now I'm modeling cervical cytology, and there is a kind of result that is
>> "inconclusive or not clear", for other results I've found SNOMED CT codes
>> but not for this one. That is the only one that I can't code right now,
>> maybe others with more experience on this area can help me find a code.
>>
>> This is what I have right now, sorry rubrics are in spanish (but is easy
>> to just put the codes in the SNOMED browser to see the concept in english
>> http://browser.ihtsdotools.org/?perspective=full=404684003=en-edition=v20180731=http://browser.ihtsdotools.org/api/v1/snomed=9000509007
>> ):
>>
>> + Normal (negativo): SNOMED-CT::5559008
>> + Poco claro (no concluyente)
>> + Anormal (positivo)
>>   + CEASI o ASCUS (células escamosas atípicas de signigicado
>> indeterminado): SNOMED-CT::39035006
>>   + CGA (células grandulares atípicas): SNOMED-CT::4476003
>>   + LIEBG (lesiones intraepiteliales escamosas de grado bajo):
>> SNOMED-CT::112662005
>>   + LIEAG (lesiones intraepiteliales escamosas de grado alto):
>> SNOMED-CT::22725004
>>   + CEA (células escamosas atípicas, no se pueden excluir las LIEAG):
>> SNOMED-CT::373878001
>>   + AIS (adenocarcinoma in situ): SNOMED-CT::51642000
>>   + Células de cáncer cervical (carcinoma de células escamosas o
>> adenocarcinoma): SNOMED-CT::285432005
>>
>>
>> Thanks!
>>
>> --
>> *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
>>
>
>
> --
> ---
> Seung-Jong YuMD
>
> Certified Board of Family Medicine
> CEO, InfoClinic Co., Ltd. (i...@infoclinic.co​
> ​ , ​
> http://infoclinic.co
> ​
> )
> Administrator, openEHR Korea (
> ​mas...@openehr.kr , ​
> http://www.openehr.kr)
>
> Mobile : 82-10-4752-5435
> seungjong...@gmail.com
> ggoj...@gmail.com ( for mailing list )
> ___
> 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

Re: Inconclusive lab results coding

[Pablo Pazos]

Thanks Heather, I got those codes in the cervical cytology findings, found
the "normal" and the "abnormal" concepts, but not a code for the grey area
in the middle of those, that, from my research, seems to be a valid outcome
from a PAP test with something like "Not clear (not conclusive)".

On Tue, Sep 11, 2018 at 2:57 AM Heather Leslie <
heather.les...@atomicainformatics.com> wrote:

> Hi Pablo,
>
>
>
> There is a hierarchy specifically for cervical cytology findings – see
> Cervical smear result (finding)
>
> SCTID: 269957009 and below.
>
>
>
> So for CEASI o ASCUS the code from that hierarchy would likely be 441087007
>
>
>
> I haven’t had time to look at all, but I suspect this is a better
> hierarchy and there may not be all options available for you. There are
> lots of gaps in SNOMED!
>
>
>
> Hope this helps
>
> Heather
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Pablo Pazos
> *Sent:* Tuesday, 11 September 2018 2:26 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Inconclusive lab results coding
>
>
>
> Hi all, lately I've been modeling different types of lab results.
>
>
>
> Now I'm modeling cervical cytology, and there is a kind of result that is
> "inconclusive or not clear", for other results I've found SNOMED CT codes
> but not for this one. That is the only one that I can't code right now,
> maybe others with more experience on this area can help me find a code.
>
>
>
> This is what I have right now, sorry rubrics are in spanish (but is easy
> to just put the codes in the SNOMED browser to see the concept in english
> http://browser.ihtsdotools.org/?perspective=full=404684003=en-edition=v20180731=http://browser.ihtsdotools.org/api/v1/snomed=9000509007
> ):
>
>
>
> + Normal (negativo): SNOMED-CT::5559008
> + Poco claro (no concluyente)
> + Anormal (positivo)
>   + CEASI o ASCUS (células escamosas atípicas de signigicado
> indeterminado): SNOMED-CT::39035006
>   + CGA (células grandulares atípicas): SNOMED-CT::4476003
>   + LIEBG (lesiones intraepiteliales escamosas de grado bajo):
> SNOMED-CT::112662005
>   + LIEAG (lesiones intraepiteliales escamosas de grado alto):
> SNOMED-CT::22725004
>   + CEA (células escamosas atípicas, no se pueden excluir las LIEAG):
> SNOMED-CT::373878001
>   + AIS (adenocarcinoma in situ): SNOMED-CT::51642000
>   + Células de cáncer cervical (carcinoma de células escamosas o
> adenocarcinoma): SNOMED-CT::285432005
>
>
>
>
>
> Thanks!
>
>
> --
>
> *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
>


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

Re: Generic modeling and issues for querying

[Pablo Pazos]

Thanks Thomas, that in fact seems to generate different nodeIDs for each
analyte, thus avoids the querying issue.

BTW, to be generic is not a requirement on my side, just wanted to reuse
what is published on the CKM, I can create specific archetypes per panel or
analyte, but that approach seems to diverge from the editor's modeling
style. But my idea is the same as yours: try to distribute pre-built OPTs
for specific panels.

I think I need to evaluate the cost of migrating to ADL2 since I see this
as a blocker for 1.4 ADL and OPTs. Also I might need to adopt the workbench
as modeling tools since there is no other tools available that can be
installed easily or is open.

Thanks!



On Sat, Sep 15, 2018 at 6:22 PM Thomas Beale 
wrote:

> Pablo,
>
> I have also seen a need for queries that distinguish analyte level
> objects, within the new lab archetypes. The original reason was to be able
> to distribute pre-built panel templates (or even archetypes) to EMR (=PEP)
> locations in Brasil, but your need is generic.
>
> This wiki page
> <https://openehr.atlassian.net/wiki/spaces/healthmod/pages/91139266/Implementing+Laboratory+Tests+in+openEHR>
> discusses the question; in this solution, you do create distinct archetype
> paths, and use normal queries. IN ADL2, this can be done with templtes,
> since templates are archetypes, and AQL works the same with them. The way
> to do it in ADL2 is shown by the examples here
> <https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/laboratory>.
> If you load these archetypes you will see:
>
> The point here is that you can just specialise the eixsting
> laboratory_test_analyte archetype into the specific analytes you want and
> then template the group to get a panel. On the basis that probably 100-200
> analytes covers the vast majority of lab tests, I think this is
> sustainable.
>
> I have not tried it in ADL1.4 / OET.
>
> - thomas
>
> On 15/09/2018 22:08, Pablo Pazos wrote:
>
> Hi all,
>
> Lately I've been working a lot with lab test reports. Current CKM modeling
> for this relies on a generic model that applies to any kind and structure
> of result in this way:
>
> - COMPO.report-result // any result document
>   - OBSERVATION.laboratory_test_result// results container, can be
> used as a panel
> - CLUSTER.laboratory_test_analyte  // single result
>
>
> This kind of generic model relies on specific structures to be set at
> runtime, and also to use specific codes to know which type of result is
> contained in the analytes (which remembers me of the way CDAs are modeled).
>
> *An example*
>
> For a lipids panel result, which contains analytes for cholesterol,
> triglyceride, HDL and LDL, we need systems to create that structure and use
> specific codes like:
>
> - COMPO
>   - OBSERVATION
>  - CLUSTER = cholesterol, LOINC::14647-2
>  - CLUSTER = triglyceride, LOINC::14927-8
>  - CLUSTER = HDL, LOINC::2085-9
>  - CLUSTER = LDL, LOINC::39469-2
>
> That is 4 occurrences of the same CLUSTER, and inside each CLUSTER, the
> same ELEMENTS (name, result, comment, etc).
>
>
> *Issues for querying*
>
> Now if we want to query that structure, we need to rely in the codes
> instead of in the structure, because the structure is set at runtime not at
> design time. So If we need the COMPOs that have cholesterol > 10 mmol/L we
> need a query like this:
>
> SELECT ...
> FROM ..., CLUSTER[CLUSTER.analyte] c
> WHERE c/path_to_code = 14647-2 AND c/path_to_magnitude > 10 AND
> c/path_to_units = mmol/L
>
>
> *What's the problem with that query?*
>
> If we have instances like this:
>
> - COMPO
>   - OBSERVATION
>  - CLUSTER = name=cholesterol, code=LOINC::14647-2, value=6.3 mmol/L
>  - CLUSTER = name=triglyceride, code=LOINC::14927-8, value=12.3 mmol/L
>  - CLUSTER = name=HDL, code=LOINC::2085-9, value=2.0 mmol/L
>  - CLUSTER = name=LDL, code=LOINC::39469-2, value=1.5 mmol/L
>
>
> c can be any of the 4 CLUSTERs set at runtime since all of them are
> occurrences of the same node defined in the archetype and the correspondent
> OPT. So when comparing the code, value and units that can match values from
> the other CLUSTERs, so we need a way to ensure those paths have the same
> instance parent, and that can't be done with archetype paths.
>
> So the query above might find the code 14647-2 in the first CLUSTER, but
> check the magnitude against the second CLUSTER that is > 10.
>
> The issue goes away if each CLUSTER can have a specific nodeId that
> complies with the specification on the archetype but is really an instance
> nodeId.
>
> Another solution might be to add some kind of extra expression to the AQL
>

Generic modeling and issues for querying

[Pablo Pazos]

Hi all,

Lately I've been working a lot with lab test reports. Current CKM modeling
for this relies on a generic model that applies to any kind and structure
of result in this way:

- COMPO.report-result // any result document
  - OBSERVATION.laboratory_test_result// results container, can be used
as a panel
- CLUSTER.laboratory_test_analyte  // single result


This kind of generic model relies on specific structures to be set at
runtime, and also to use specific codes to know which type of result is
contained in the analytes (which remembers me of the way CDAs are modeled).

*An example*

For a lipids panel result, which contains analytes for cholesterol,
triglyceride, HDL and LDL, we need systems to create that structure and use
specific codes like:

- COMPO
  - OBSERVATION
 - CLUSTER = cholesterol, LOINC::14647-2
 - CLUSTER = triglyceride, LOINC::14927-8
 - CLUSTER = HDL, LOINC::2085-9
 - CLUSTER = LDL, LOINC::39469-2

That is 4 occurrences of the same CLUSTER, and inside each CLUSTER, the
same ELEMENTS (name, result, comment, etc).


*Issues for querying*

Now if we want to query that structure, we need to rely in the codes
instead of in the structure, because the structure is set at runtime not at
design time. So If we need the COMPOs that have cholesterol > 10 mmol/L we
need a query like this:

SELECT ...
FROM ..., CLUSTER[CLUSTER.analyte] c
WHERE c/path_to_code = 14647-2 AND c/path_to_magnitude > 10 AND
c/path_to_units = mmol/L


*What's the problem with that query?*

If we have instances like this:

- COMPO
  - OBSERVATION
 - CLUSTER = name=cholesterol, code=LOINC::14647-2, value=6.3 mmol/L
 - CLUSTER = name=triglyceride, code=LOINC::14927-8, value=12.3 mmol/L
 - CLUSTER = name=HDL, code=LOINC::2085-9, value=2.0 mmol/L
 - CLUSTER = name=LDL, code=LOINC::39469-2, value=1.5 mmol/L


c can be any of the 4 CLUSTERs set at runtime since all of them are
occurrences of the same node defined in the archetype and the correspondent
OPT. So when comparing the code, value and units that can match values from
the other CLUSTERs, so we need a way to ensure those paths have the same
instance parent, and that can't be done with archetype paths.

So the query above might find the code 14647-2 in the first CLUSTER, but
check the magnitude against the second CLUSTER that is > 10.

The issue goes away if each CLUSTER can have a specific nodeId that
complies with the specification on the archetype but is really an instance
nodeId.

Another solution might be to add some kind of extra expression to the AQL
to say "these paths should be under the same parent instance".

But the simplest would be just not to have generic models, so the "lipids
panel" archetype would have 4 CLUSTERs each with it's own nodeId, so when
querying, the paths are pointing to different CLUSTERs and they contained
ELEMENTs.


Not sure how others solve these cases, would like to hear if you use these
generic models, how to query them without these issues, or if you just go
with specific models.

Thanks.


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

Re: What's the correct XML in an OPT for multiple terminology references?

[Pablo Pazos]

Just remembered children of attribute can handle multiple alternatives,
while this is syntactically correct I'm not sure if the alternatives can be
of the same object type:



defining_code
  

  
  
CODE_PHRASE

  



*terminology:LOINC*
  
  
CODE_PHRASE

  


*
terminology:SNOMED-CT*
  


On Sat, Sep 15, 2018 at 2:56 PM Pablo Pazos 
wrote:

> Hi,
>
> I'm having trouble generating OPTs (1.4) from archetypes that reference
> multiple terminologies from a DV_CODED_TEXT.
>
> For instance, I have a coded node that will be coded by LOINC or
> SNOMED-CT, that can be set in the archetype. But when exporting the OPT
> from the Template Designer, only LOINC appears in this way:
>
> 
>  CODE_PHRASE
>  
> true
> true
> false
> false
> 1
> 1
>  
>  
> * terminology:LOINC*
>
>
>
> Now, looking at the OPT schema (I think I got it from the TD), it says the
> C_CODE_PHRASE only can have one *referenceSetUri* element, so it is not
> possible to add more elements with other terminologies.
>
> So, how can we put many terminologies on the OPT?
>
> Should that be multiple values in that element? like this:
>
> *terminology:LOINC
> terminology:SNOMED-CT*
>
> (that looks ugly and I don't think is valid)
>
>
> I'm surprised to find this simple case can't be supported by tools or the
> OPT format itself. Any tips are welcome.
>
>
> Best,
> Pablo.
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
>

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

What's the correct XML in an OPT for multiple terminology references?

[Pablo Pazos]

Hi,

I'm having trouble generating OPTs (1.4) from archetypes that reference
multiple terminologies from a DV_CODED_TEXT.

For instance, I have a coded node that will be coded by LOINC or SNOMED-CT,
that can be set in the archetype. But when exporting the OPT from the
Template Designer, only LOINC appears in this way:


 CODE_PHRASE
 
true
true
false
false
1
1
 
 
* terminology:LOINC*
   


Now, looking at the OPT schema (I think I got it from the TD), it says the
C_CODE_PHRASE only can have one *referenceSetUri* element, so it is not
possible to add more elements with other terminologies.

So, how can we put many terminologies on the OPT?

Should that be multiple values in that element? like this:

*terminology:LOINC terminology:SNOMED-CT*

(that looks ugly and I don't think is valid)


I'm surprised to find this simple case can't be supported by tools or the
OPT format itself. Any tips are welcome.


Best,
Pablo.

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Inconclusive lab results coding

[Pablo Pazos]

Hi all, lately I've been modeling different types of lab results.

Now I'm modeling cervical cytology, and there is a kind of result that is
"inconclusive or not clear", for other results I've found SNOMED CT codes
but not for this one. That is the only one that I can't code right now,
maybe others with more experience on this area can help me find a code.

This is what I have right now, sorry rubrics are in spanish (but is easy to
just put the codes in the SNOMED browser to see the concept in english
http://browser.ihtsdotools.org/?perspective=full=404684003=en-edition=v20180731=http://browser.ihtsdotools.org/api/v1/snomed=9000509007
):

+ Normal (negativo): SNOMED-CT::5559008
+ Poco claro (no concluyente)
+ Anormal (positivo)
  + CEASI o ASCUS (células escamosas atípicas de signigicado
indeterminado): SNOMED-CT::39035006
  + CGA (células grandulares atípicas): SNOMED-CT::4476003
  + LIEBG (lesiones intraepiteliales escamosas de grado bajo):
SNOMED-CT::112662005
  + LIEAG (lesiones intraepiteliales escamosas de grado alto):
SNOMED-CT::22725004
  + CEA (células escamosas atípicas, no se pueden excluir las LIEAG):
SNOMED-CT::373878001
  + AIS (adenocarcinoma in situ): SNOMED-CT::51642000
  + Células de cáncer cervical (carcinoma de células escamosas o
adenocarcinoma): SNOMED-CT::285432005


Thanks!

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

Re: Recommended versioning strategy for Templates

[Pablo Pazos]

In the EHRServer we use that approach, template ids have a version number
and language:
https://github.com/ppazos/cabolabs-ehrserver/wiki/Template-Management-(from-EHRServer-v1.3)

But that is not related to querying.

On Sat, Sep 1, 2018 at 2:21 PM Ian McNicoll  wrote:

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


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

Re: Recommended versioning strategy for Templates

[Pablo Pazos]

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

Re: AQL on specific list of compositions

[Pablo Pazos]

That is one of the issues with AQL, one thing is to support the syntax,
another thing is to have compatible query engine implementations, even if
the semantics are correctly interpreted for each operator, data results
might differ. But we are also having different interpretations of the
operators, and also different levels of support of the AQL syntax itself.

My interpretation of this situation is we are on a starting point of a
wider use of the query specs, we will have inconsistencies between
implementations and maybe in a couple of years we will have a clear spec
for the full AQL syntax (with extensions), the internal query engine
architecture, and the result sets.

On Tue, Aug 21, 2018 at 2:28 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> Hi Thomas,
>
> from my perspective, this approach (by not being explicit about the RM
> classes (and semantics) that need to be supported by the Contains keyword)
> led to a situation in which two vendors (Marand and DIPS) can claim that
> they have a valid implementation of openEHR but are not compatible. I can't
> even tell if Marand (not support Folders at all) or DIPS (using
> questionable overloading of the semantics) is more right or wrong with
> their approaches on this matter...
>
> Birger
>
>
> Am 21.08.2018 um 17:04 schrieb Thomas Beale:
>
> Hi Birger,
>
> Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec -
> they are just used in examples. AQL doesn't actually know anytthing about
> particular types. Seref's intention is that it stays this way, and his
> proposed function, or some other equivalent resolver mechanism would be a
> generic addition to AQL that would, for openEHR structures be used for
> FOLDERs containing refs to COMPOSITIONs (actually VERSIONED_COMPOSITIONs),
> and also any other similar situation (e.g. in the demographic model).
>
> - thomas
>
>
> On 21/08/2018 15:52, Birger Haarbrandt wrote:
>
> Hi Seref,
>
> while I understand your argument regarding overloading of definitions (and
> I agree with your reasoning), I see a clear need to not treat folders as
> second class citizens in openEHR. Not including Folders in the official AQL
> spec and leaving this to vendor-dependent functions will not be helpful to
> allow portability. Especially, as the use of folders (especially when it
> can contain data in an ITEM_STRUCTURE) is becoming a common pattern to
> represent episodes of care.
>
> Cheers,
>
> --
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> --
>
>
>
> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical
> Informatics (PLRI) Technical University Braunschweig and Hannover Medical
> School Software Architect HiGHmed Project *
> Tel: +49 176 640 94 640, Fax: +49 531/391-9502
> birger.haarbra...@plri.de
> www.plri.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

Re: AQL on specific list of compositions

[Pablo Pazos]

>>>
>>> *From:* openEHR-technical  *On
>>> Behalf Of *Ian McNicoll
>>> *Sent:* mandag 20. august 2018 11:22
>>> *To:* For openEHR technical discussions >> hr.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
>>
>>
>
> ___
> 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

Re: Drug dispense entry class question

[Pablo Pazos]

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

Re: Drug dispense entry class question

[Pablo Pazos]

Thanks Ian,

I know this was modeled. Just wanted to understand the rationale behind
choosing an ACTION vs an ADMIN_ENTRY, this is to help me create an exercise
for my students. And for ACTION, if the dispense should be an active of
final state, and from your message it seems I was on the right path, not
thinking this as a final state since more actions can happen after the
dispense, like the one I mentioned of the patient recording intake.

:)

On Sat, Aug 11, 2018 at 4:41 PM, Ian McNicoll  wrote:

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


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

Re: Drug dispense entry class question

[Pablo Pazos]

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

Drug dispense entry class question

[Pablo Pazos]

Hi all,

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.

What do you think?

Thanks!

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

Re: post-coordination in openEHR

[Pablo Pazos]

IMO it means post coordinated stuff can't be used at design time in
archetypes. It can be used at runtime. For instance we use snomed
expressions embedded in openEHR queries to filter coded texts. In the
archetype or template that defines that coded text, there is only a binding
with snomed, nothing else.

On Thu, Aug 9, 2018, 09:21 Georg Fette  wrote:

> Hello,
> Using terminology bindings it is posssible to bind terminology IDs of
> specific terminologies to archetypes as well as to their members. In the
> openEHR documentation it is written that there is no concept of
> post-coordination outside the terminology environment. What does that
> exactly mean ? When I have a post-coordinated expression, how do I use
> it within openEHR ? The linkage of an openEHR system to a potential
> terminology server is something that I do not yet unterstand very well.
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR Education Program

[Pablo Pazos]

とても良い

On Wed, Jul 25, 2018 at 6:08 AM, Shinji KOBAYASHI  wrote:

> Very good time to announce.
> We will be broadcasting openEHR tutorial(in Japanese) via our youtube
> channel from 10:00(JST) on 27th, July 2018.
> https://www.youtube.com/channel/UCTIV2k0OhooiuvRgPSqY-iw
> If you are interested in Japanese openEHR tutorial, please watch it.
>
> Best regards,
> Shinji Kobayashi
>
> 2018-07-25 17:59 GMT+09:00 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
>>
>>
>
> ___
> 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

Re: openEHR Education Program

[Pablo Pazos]

Hi David, yes I was involved :)

Evelyn presented a document called Book of Knowledge, which tried to
analyze/define different contexts and aspects of different roles people can
play using openEHR, the skills needed for an openEHR related job, and some
topics that should be part of training/education programs ("program" in
terms of courses and their internal organization of topics). On that
opportunity I acted as a reviewer/editor of the BoK.

I think the BoK was an excellent start for a full fledged program
("program" in terms of people organizing, validating, endorsing and
certificating courses, trainers and students), but in practical terms it
might be to ambitious and had a huge scope that can't be handled by the low
budget we have at the Foundation.

Some months ago people from the board started to propose a the need of a
practical approach and way smaller scope, but someone has to define that.
After talking a lot with Hildi, Koray, and Heather, Hildi proposed a new
plan of action and presented that to the board. This time I also acted as a
reviewer/editor, as well as others. Hildi is actually leading this new
effort.

I think after the board approve the document presented by Hildi, that
should be opened to the community for transparency and feedback. The nice
thing is, maybe my biggest contribution to the doc, is that includes a plan
of action for the first 12 months of the new education program (was never
formally established), that includes, among other things, to have some
guidelines for trainers to coordinate/standardize parts of the training
they (we) give, and how the endorsement of trainers should be handled by
the foundation and the related responsibilities of the education program in
assessing and endorse training proposals. It would be great if in a couple
of years we can have people offering training that is formally endorsed by
the openEHR foundation. This of course will be also a filter for people
offering openEHR training that doesn't have any experience with it and
never participated in the community, sadly there are cases.

Hope this gives a little background of the education program, what's going
on, and what are the next steps.

Best,
Pablo.

PS: I think after the program is formally established, we'll open
postulations to add more members, as we do with the SEC.


On Tue, Jul 24, 2018 at 8:37 AM, 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
>
>


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

Re: UCUM/SNOMED/custom units

[Pablo Pazos]

REF https://openehr.atlassian.net/browse/SPECPR-96

On Mon, Jul 23, 2018 at 9:15 AM, Bert Verhees  wrote:

> On 23-07-18 13:45, Diego Boscá wrote:
>
>> Units need to be (and will be) revamped, we also need other things
>> already discussed in other posts like rubric, long descriptions (which
>> could be language dependent), etc. This could be very useful for better
>> describing custom UCUM units too.
>> Several alternatives are being explored in order to not break current
>> units definitions. Maybe adding an optional codephrase or terminology
>> mapping could do the trick, as then you can tell where the unit comes from
>> and allows you to provide a "code" which could either contain a Snomed code
>> or a UCUM expression. Inputs are appreciated as always :)
>>
>
> I think your suggested solution is just right ;-)
> But possible I do not oversee all consequences
>
> Bert
>
>
> ___
> 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

Does anyone know if the Template Designer is being maintained?

[Pablo Pazos]

Bug reports been there for 3 years and no new versions seem to be released:
https://openehr.atlassian.net/projects/TDPR/issues/TDPR-16?filter=allopenissues

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

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

[Pablo Pazos]

Hi Dileep,

In the EHRServer we use the template path as an absolute path for each node
in the template, that allows to identify each node in the OPT even if
different nodes hang from the same archetype root (have the same archetype
path). This allows querying for the right node.

Also there is another case when nodes with the same path but different data
type are in a composition instance. We use the path + type to identify
those node alternatives.


Best,
Pablo.

On Fri, Jul 6, 2018 at 6:07 AM, 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
>
>


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

Empty COMPOSITION.content is valid?

[Pablo Pazos]

Hi all,

Recently a client committed COMPOSITIONS with empty content to the
EHRServer, because in the OPT all the structure was associated to
context.other_context.

After reviewing the specs, I found this invariant on the COMPOSITION spec:

Content_valid: content /= Void implies not content.is_empty

That means that content can actually be null/void, since on that case, the
"implies" is true.

Also checked the COMPOSITION XSD, and the minOccurs for content is 0.

Does it make sense to have an empty COMPOSITION.content?
Does other implementers support that?
On which cases?

Thanks!

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

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

[Pablo Pazos]

Exactly, "fraction" and "integer fraction" are the same thing semantically,
but in the specs, the "integer fraction" the only one that defines a
specific format, "fraction" does not specifies a format, just the fraction
semantics for the DV_PROPORTION. That is the only difference.

On Tue, Jul 3, 2018 at 7:04 AM, Diego Boscá  wrote:

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

Is the proportion kind "integer fraction" correct?

[Pablo Pazos]

Hi, I'm checking the datatypes specs doing some modeling tests on the
archetype editor.

In the specs, the "integer fraction" proportion kind means the
representation of the fraction 3/2 should be 1 1/2.

http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_types/data_types.html#_proportion_kind_class

Semantically I think this is not on the same level as the other "proportion
kinds", since it doesn't represent a kind, but a format, where the same
values can be recorded as numerator (3) and denominator (2) with proportion
kind "fraction" and will mean the same thing. IMO "integer fraction"
doesn't even change the meaning or interpretation of the fraction, while
other "proportion kinds" do.

My question is if the "integer fraction" really belongs to a "proportion
kind" or should be somewhere else on the specs? I guess this tried to solve
a use case and it was a shorthand to represent this format as a proportion
kind.


Thanks,
Pablo.

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Interval events - "change" math function semantics

[Pablo Pazos]

Hi Thomas,

I think I'm missing something:

"...previous measurement is not necessarily in the data set."

>From that ^ I understand the reference value from which the "change" is
measure & recorded is not on the HISTORY time series.

"...one would expect the first value in a HISTORY of EVENTs..."

And that ^ seems to point on the other way. **confused**


I'm inclined to have an initial absolute / reference value, then the
"changes" (deltas, increase, decrease, ...) to be recorded in the same
HISTORY.data time series. IMO this needs clinical validation, but my
assumption os if "reference" and "changes" are not recorded together, there
is missing context for the "change" records that should be resolved in
software (if the specs don't provide a recommendation), and might be an
issue for patient safety (also this needs clinical validation).

If we can validate that, and agree on a criteria, we might need to add a
clarification/recommendation on that area to the specs.


On Wed, Jun 27, 2018 at 7:55 AM, Thomas Beale 
wrote:

>
>
> On 23/06/2018 21:13, Pablo Pazos wrote:
>
> Hi, another question about interval events.
>
> I'm having issues understanding how to use the "change" math functions.
> From the spec http://www.openehr.org/releases/RM/Release-1.0.2/
> docs/data_structures/data_structures.html#_change_data
>
>-
>
>"change": this means that the value recorded is the difference between
>the value now and the value some time previously. It can be positive or
>negative;
>-
>
>"increase": the value recorded for the change is positive. The name
>(i.e. ELEMENT.name) chosen for the item in an archetype carries the
>semantic of positivity e.g. "increase of …​.; rise of…​.; …​.gain" etc;
>-
>
>"decrease": the value recorded for the change is positive. But the
>name chosen for the item carries the semantic of negativity e.g. "decrease
>of …​.; fall of …​.; …​. loss".
>
>
> Since "change", "increase" or "decrease" are based on a previous value,
> shouldn't the record of the change have a link to the previous value that
> served as reference to record the change?
>
>
> it is based on a previous value of the measured datum, but that previous
> measurement is not necessarily in the data set. The use of these codes
> indicates that the difference is being recorded, not the absolute value.
>
>
> I'm not sure in which context a change or increase on some value would be
> useful without the value that change or increase is compared with.
>
>
> Agree; to make it sensible, one would expect the first value in a HISTORY
> of EVENTs to be an absolute instantaneous value, with some or all of the
> other values being differences.
>
>
>
>
> --
> 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

Re: AE constraints offset for POINT_EVENTs

[Pablo Pazos]

On Wed, Jun 27, 2018, 04:56 Thomas Beale  wrote:

>
> On 26/06/2018 18:12, Pablo Pazos wrote:
>
> Thanks David, didn't noticed that discussion!
>
> @Thomas, isn't constraining HISTORY.period a way to define
> POINT_EVENT.offset() for all the events in HISTORY.events?
>
>
> only in a general way and only for Event series that happen to be
> periodic. For example, the Apgar uses only the specific offsets 1 min, 2
> mins, 5 mins and 10 mins.
>

>From the AE it seems not possible to constraint the offset in that way.
Only fixed suggestions can be set. All is defining only periodic point
events. Not sure how defining not constant offsets would be expressed.


> - t
>
> --
> 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: Question about periodic interval events

[Pablo Pazos]

That is the answer I'm looking for :)

Task for the SEC: clarify that on the specs (I'll check current baseline)


On that case, is it possible to have overlapping INTERVAL_EVENTs on the
same series? Thinking of one event taking too long and overlapping the
start of the next one because the constraint for period is 5 minutes and
the INTERVAL_EVENT.width took 6 minutes.

Or it is stated somewhere that we consider INTERVAL_EVENT.width <
HISTORY.period? This can be controlled at design time and/or in software.


Best,
Pablo.

On Tue, Jun 26, 2018 at 5:44 AM, Thomas Beale 
wrote:

>
> always from start to start, assuming there is periodicity.
>
>
> On 23/06/2018 20:35, Pablo Pazos wrote:
>
>> Hi all,
>>
>> As usual I'm reading the specs and have a question about periodic
>> interval events.
>>
>> I'm not sure how the period is calculated in a series. Let's say we have
>> interval events on a time line:
>>
>> ---E1.start___E1.end--E2.startE2.end---...
>>
>>
>
> ___
> 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

Re: AE constraints offset for POINT_EVENTs

[Pablo Pazos]

Thanks David, didn't noticed that discussion!

@Thomas, isn't constraining HISTORY.period a way to define
POINT_EVENT.offset() for all the events in HISTORY.events?

Since period defines regular occurrences of POINT_EVENT, that will
determine the offset of each event from the HISTORY.origin.

For non periodic POINT_EVENTs it doesn't make much sense to constraint the
offset to a fixed value, and the period is obviously not used, so the only
case we might want to constraint "offset" is when we want to constraint
"period" (?)

Also defining a constraint for POINT_EVENT.offset is currently creating a
constraint for the return value of the function, that is DV_DURATION, so
for all the events in HISTORY.events, offset is for instance PT5M, which is
not correct if we have more than one POINT_EVENT in HISTORY.events.

HISTORY[at0001] matches {-- Event Series
events cardinality matches {1..*; unordered} matches {
POINT_EVENT[at0002] occurrences matches {0..*} matches
{-- Cualquier evento
offset matches {
DV_DURATION matches {
value matches {|PT5M|}
}
}

Considering all this, IMO:

1. the AE should not allow constraining that specific function (offset),
need to analyze if we have other cases to state a more general rule like
"no functions can be constrained".
2. the IM is OK, no need to change offset to an attribute, should be a
function of the history origin and the event time as it is right now.
3. LinkEHR behavior is correct in not allow defining constraints for offset.


There is another issue though, for period constraint interpretation for
INTERVAL_EVENTs. I sent a question about that a couple of days ago to the
tech list. The problem is what the period defines for INTERVAL_EVENTs, the
distance between the start of two consecutive events, the distance between
the end of one event and the start of the next one, etc.


Best,
Pablo.



On Tue, Jun 26, 2018 at 5:50 AM, Thomas Beale 
wrote:

> the ontological problem here is that when dealing with time, you always
> want to constrain at design time in terms of relative amounts, usually
> offsets, durations etc. But at runtime, the time data are absolute times,
> that you cannot know at the outset.
>
> This would not be a problem if we had made offset a data element, but then
> the time-point of an EVENT would need to be calculated by adding the offset
> to the origin, and even worse, setting it in the first place would have to
> be done by a subtraction.
>
> Prbabaly the right way to get around this is to allow constraints of the
> form:
>
> (/path/to/EVENT/time - /path/to/HISTORY/origin) matches {PT5M}
>
> and so on. We are just rewriting the expressions language, so we can
> finally solve this any many other more complex constraints, with a single
> language, which will be common to GDL, Task Planning and so on.
>
> - thomas
>
>
>
> On 26/06/2018 09:21, David Moner wrote:
>
> Hi Pablo,
>
> An old discussion about the offset and constraints over methods:
> https://www.mail-archive.com/openehr-technical@lists.
> openehr.org/msg09386.html
>
> And an even older one (from 2012!):
> https://www.mail-archive.com/openehr-technical@lists.
> openehr.org/msg06557.html
>
> It seems that we have never found a full agreement between those who agree
> with constraining the value returned by methods, and those who think that
> it is not a recommendable approach.
>
> BTW, I just checked that in LinkEHR we cannot constraint offset or any
> other method, since our main source for the RM is the XML Schema and it
> doesn't define them.
>
>
> --
> 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

Re: Question about periodic interval events

[Pablo Pazos]

Hi Gerard,

On Sun, Jun 24, 2018 at 4:04 AM, GF  wrote:

> See below
>
> GF
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 24 Jun 2018, at 01:49, Pablo Pazos  wrote:
>
> Hi Gerard,
>
> On Sat, Jun 23, 2018 at 6:58 PM, GF  wrote:
>
>> When one assumes that the all events are the same kind of events but
>> occurring at various points in time,
>>
>
> That is what is supported by the openEHR spec, no need to assume. All
> EVENTs in HISTORY.data are of the same type ~ have the same definition in
> the archetype.
>
>
>>
>> Then the period can be expressed as Frequency (n/T) or equally as Period
>> n/F).
>>
>> Where n=number of events and T= total time from begin of the first event
>> till the last (E.1 - E.n)
>> Clinical example:
>> Heart rate = 120 beats per minute.
>>
>> Or as Period (T=n/F) expressed as time units that is the time between two
>> events.
>> Clinical example:
>> Period between heart beats =  60/120 = 0,5 seconde. I.E the time between
>> E(n+1) - E(n)
>>
>> In your example
>> Period =  1 divided by Time (E2.start - Time E1.start),
>> or, Period = 1 divided by Time(E3.start) - Time(E2.start)
>> or, Period = 2  divided by Time (E3.start - Time E1.start)
>>
>
> This works with POINT_EVENT, my question is about INTERVAL_EVENT from the
> openEHR specs, where each event start and end are different.
>
>
> Any Event (process) has an end date and start date an can be small but
> never zero.
> End dates are always different from start dates.
> So what do you mean?
>

I'm talking about openEHR events by the definition of the specs, not trying
to come up with another definition. In openEHR POINT_EVENT is the record of
an event that to the record is just a point in time, doesn't really matters
if in reality the event took 10 seconds to execute, like a BP reading. That
is not clinically relevant in most contexts.


>
>
> By openEHR, the heart rate EVENT is one single measure of the hear rate,
> there is no record of individual beats.
>
>
> Its meaning can be several things.
> It can be the rate (frequency) at a real *point* in time. Time=T e.g.
> now, yesterday.
> Or it can be the average over a *period* of time.e.g. the last minute,the
> last 10 minutes, the last month.
> Actually it is a little bit more complex.
>
>
> Again, I'm following the spec definitions, not trying to create my own
interpretation. In that context, current models of heart rate, and current
information model structure for OBSERVATION don't try to model individual
beats, an EVENT is not that, is the consideration of the beat rate as one
data point.

Then the period that I'm talking about is the HISTORY.period by the openEHR
specs, that affect EVENTs in the same OBSERVATION time series. That is not
clearly defined in the specs (going back to my original question).


>
> What would make an INTERVAL_EVENT from heart rate, is to record the
> average heart rate in an hour.
>
> Frequency at *point* in a Unit Time.
>
> Not sure that I'm following. INTERVAL_EVENT by the openEHR specs is not
that. It allows to record a summarized value from an interval of time, e.g.
average (or max, or min, or mean, ...) heart rate in the last 10 minutes.


> And a periodic list of INTERVAL_EVENTs, would be records of the average of
> the heart rate that happen periodically. The issue I'm having is the specs
> don't have a concrete definition of "period" for INTERVAL_EVENT series.
>
>
> INTERVAL–EVENTs as interval between events measured over a *period* of
> time.
>
> What is NOT defined?
>

This is not correct, check the spec:
http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_history_package


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

Re: Question about periodic interval events

[Pablo Pazos]

"Ex" is just an interval event, "interval" in terms of the openEHR specs.

Here clinical context is not relevant, the point is how time calculations
are done to use the period (HISTORY.period
http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_history_class
).

But if you think this has to do with the medical interpretation, please
elaborate. Maybe I'm missing something.

Thanks.

On Sat, Jun 23, 2018 at 4:42 PM, Karsten Hilbert 
wrote:

> On Sat, Jun 23, 2018 at 04:35:36PM -0300, Pablo Pazos wrote:
>
> > As usual I'm reading the specs and have a question about periodic
> interval
> > events.
> >
> > I'm not sure how the period is calculated in a series. Let's say we have
> > interval events on a time line:
> >
> > ---E1.start___E1.end--E2.startE2.end---...
> >
> > Note: interval events can have different durations.
> >
> > Is the period calculated from E1.start to E2.start or from E1.end to
> > E2.start?
> >
> > This is of course to know when E3 should start.
>
> As a doctor I would say it depends on what E is, medically.
>
> 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

Interval events - "change" math function semantics

[Pablo Pazos]

Hi, another question about interval events.

I'm having issues understanding how to use the "change" math functions.
>From the spec
http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_change_data

   -

   "change": this means that the value recorded is the difference between
   the value now and the value some time previously. It can be positive or
   negative;
   -

   "increase": the value recorded for the change is positive. The name
   (i.e. ELEMENT.name) chosen for the item in an archetype carries the
   semantic of positivity e.g. "increase of …​.; rise of…​.; …​.gain" etc;
   -

   "decrease": the value recorded for the change is positive. But the name
   chosen for the item carries the semantic of negativity e.g. "decrease of
   …​.; fall of …​.; …​. loss".


Since "change", "increase" or "decrease" are based on a previous value,
shouldn't the record of the change have a link to the previous value that
served as reference to record the change?

I'm not sure in which context a change or increase on some value would be
useful without the value that change or increase is compared with.

Checking the terminology for math functions, we have absolute (can be
calculated just from given values), and relative (needs a given value and a
previous value) math functions.
https://github.com/openEHR/terminology/blob/master/openEHR_RM/en/openehr_terminology.xml

These are the ones that I don't understand, in terms of how to use them in
software:








Does anybody have some example that uses any of those math functions?


Thanks!

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

Question about periodic interval events

[Pablo Pazos]

Hi all,

As usual I'm reading the specs and have a question about periodic interval
events.

I'm not sure how the period is calculated in a series. Let's say we have
interval events on a time line:

---E1.start___E1.end--E2.startE2.end---...

Note: interval events can have different durations.

Is the period calculated from E1.start to E2.start or from E1.end to
E2.start?

This is of course to know when E3 should start.

Thanks!

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

Re: SMART on FHIR integration

[Pablo Pazos]

SSO is a front end feature, that is not on the current scope of the openEHR
specs.

I think any openEHR implementer can do SSO at the front-end app level to
access SMART apps.

On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz <br...@nantz.org> wrote:

> I see you have had discussions on FHIR and SMART on FHIR.  Is it on the
> roadmap for openEHR to support SMART on FHIR launch sequence (
> http://docs.smarthealthit.org/authorization/) for single sign on?  I know
> many customers who would like this seemless integration.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Check the initial messages on the thread.

Basically how to use SNOMED in openEHR, and in a specific area: data
querying. AQL support for SNOMED codes and expressions was an initial part
of the topic.

We are trying to solve a basic problem: how to get data out the systems in
a smart way. This is because archetypes are good but don't have context
that terminologies have, and AQL is good but only queries what is defined
by models. So we need something to query over terminologies in combination
with querying over models. Reasoning, interpretation and modeling
approaches are other orthogonal problems.

This is a very specific problem for the openEHR specs and ITS, is not a
general problem to solve.

On Tue, Apr 3, 2018 at 4:31 AM, A Verhees <bert.verh...@rosa.nl> wrote:

> Can we specific define in about ten words which problem is talked about in
> this discussion?
>
> Maybe we can then use that definition as a guideline to keep the
> discussion focussed.
>
> Best regards
> Bert Verhees
>
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:
>
>> Please see below,
>>
>> On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl> wrote:
>>
>>> Is that so?
>>>
>>> There will be systems that allow pre-coordinated codes. There will be
>>> systems that use as many pre-coordinated codes. And several in between
>>> solutions.
>>>
>>
>> I agree, there will be systems that allow and use pre and post
>> coordinated codes, that is a fairly normal requirement in clinical
>> information systems and openEHR specs supports that.
>>
>>
>>> This means that reasoners will be used to create transformations.
>>>
>>
>> It doesn't mean that, I don't see where that is implied.
>>
>> Some systems might use reasoners using ontologies, rules, codes and other
>> content, to infer some "facts", and the results should be interpreted in
>> the same context as the ontologies, rules, clinical records and codes are
>> created, managed and used. Inferred facts are context dependent.
>>
>> Some other systems might not use any reasoners or ontologies at all, and
>> define programmatic rules that use SNOMED codes and expressions (pre and
>> post coordinated), and other contextual clinical / demographic /
>> administrative information to evaluate those rules and get some result (an
>> alert, a recommendation, a reminder, etc.)
>>
>> And other systems might not have rules at all and just use codes,
>> expressions and contextual data to create some visual representation of the
>> patient's status, to be presented to a clinician and make him/her evaluate
>> the data and make a decision. This is the most basic area we should cover,
>> and what originally generated this discussion: how to use SNOMED in openEHR
>> queries.
>>
>> Use cases are many, we can't focus on just one area and generalize from
>> there.
>>
>>
>>> It is likely that ontological servoces will be used, And then we will
>>> have a potential problem.
>>>
>>
>> That will really depend on specific implementations. I don't think
>> proposing a combination of standards with a lot of potential will cause any
>> issues per se.
>>
>>
>>
>>> But perhaps solvable with the correct precautions.
>>> One being that ontological servoces are NOT used and that ad hoc rules
>>> do the transform.
>>>
>>
>> That is exactly my point from above, automatic conclusions from a
>> reasoner or any AI can be interpreted as a general truth on any context.
>> Those conclusions should be interpreted in the same context as data and
>> knowledge was created. And semantics should be given by humans on a
>> per-context basis.
>>
>>
>>
>>> What possible solution is the canonical one? which is the ‘golden truth’.
>>>
>>
>> Since all that ^ is context-dependent, I don't think there is any
>> canonical form or golden truth.
>>
>>
>>>
>>> When we add to all this that only part of the epistemology can be
>>> pre-coordinated it means that part of the temporal aspects for instance can
>>> NOT be dealt with in SNOMED, then we have the situation that part of the
>>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>>
>>
>> I agree and that is a good example of what I call "context" (how and
>> where knowledge and information is defined, managed and used, very related
>> to epistemology :)
>>
>>
>>>
>>>
>>> Gerard   Freriks
>&g

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Please see below,

On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl> wrote:

> Is that so?
>
> There will be systems that allow pre-coordinated codes. There will be
> systems that use as many pre-coordinated codes. And several in between
> solutions.
>

I agree, there will be systems that allow and use pre and post coordinated
codes, that is a fairly normal requirement in clinical information systems
and openEHR specs supports that.


> This means that reasoners will be used to create transformations.
>

It doesn't mean that, I don't see where that is implied.

Some systems might use reasoners using ontologies, rules, codes and other
content, to infer some "facts", and the results should be interpreted in
the same context as the ontologies, rules, clinical records and codes are
created, managed and used. Inferred facts are context dependent.

Some other systems might not use any reasoners or ontologies at all, and
define programmatic rules that use SNOMED codes and expressions (pre and
post coordinated), and other contextual clinical / demographic /
administrative information to evaluate those rules and get some result (an
alert, a recommendation, a reminder, etc.)

And other systems might not have rules at all and just use codes,
expressions and contextual data to create some visual representation of the
patient's status, to be presented to a clinician and make him/her evaluate
the data and make a decision. This is the most basic area we should cover,
and what originally generated this discussion: how to use SNOMED in openEHR
queries.

Use cases are many, we can't focus on just one area and generalize from
there.


> It is likely that ontological servoces will be used, And then we will have
> a potential problem.
>

That will really depend on specific implementations. I don't think
proposing a combination of standards with a lot of potential will cause any
issues per se.



> But perhaps solvable with the correct precautions.
> One being that ontological servoces are NOT used and that ad hoc rules do
> the transform.
>

That is exactly my point from above, automatic conclusions from a reasoner
or any AI can be interpreted as a general truth on any context. Those
conclusions should be interpreted in the same context as data and knowledge
was created. And semantics should be given by humans on a per-context basis.



> What possible solution is the canonical one? which is the ‘golden truth’.
>

Since all that ^ is context-dependent, I don't think there is any canonical
form or golden truth.


>
> When we add to all this that only part of the epistemology can be
> pre-coordinated it means that part of the temporal aspects for instance can
> NOT be dealt with in SNOMED, then we have the situation that part of the
> epistemology is in SNOMED and part defined in the Archetype/Template.
>

I agree and that is a good example of what I call "context" (how and where
knowledge and information is defined, managed and used, very related to
epistemology :)


>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>
> Yes, but the main topic here is the use of SNOMED inside openEHR, so there
> is no terminology world separated from the content modeling and data
> recording world. We will use SNOMED inside the openEHR context, so the
> SNOMED meaning will be constrained by the openEHR meaning when recording
> clinical information. We should be constraint to that context.
>
> On Mon, Apr 2, 2018 at 6:01 AM, GF <gf...@luna.nl> wrote:
>
>> Pablo,
>>
>> It is as Thomas and I wrote.
>>
>> *Open world Assumption:* Ontologies declare absolute truths irrespective
>> of geographical location and point in time.
>>
>> *Closed World Assumption*: Archetypes help express what an author wants
>> to document. These are very subjective truths at a point in time.
>>
>> This subtle but important distinction is only one of the reasons to
>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>> matter when we start to reason about the documented patient data.
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 01:11, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>>
>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>> make sense. No system can record what can or can't happen in the future,
>> and that concept is not part of any terminology AFAIK.
>>
>> On Sun, A

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

I'm sorry but "...no cancer was, is, or will be present." doesn't even make
sense. No system can record what can or can't happen in the future, and
that concept is not part of any terminology AFAIK.

On Sun, Apr 1, 2018 at 7:35 PM, GF <gf...@luna.nl> wrote:

> Thomas,
>
> OpenEHR and 13606 deal with Closed World Assumption systems.
> And therefor both mean in the case of 'No Cancer' that Cancer was not
> found in the database or that No Cancer was the documented result of an
> evaluation.
> Both statements are documented things in a Template that according to the
> author cancer is not found.
> But any time in the future it might.
>
> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
> cancer was, is, or will be present.
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 1 Apr 2018, at 14:41, Thomas Beale <thomas.be...@openehr.org> wrote:
>
>
> On 01/04/2018 13:16, GF wrote:
>
> Pre-coordinated SNOMED codes are like classifications, in that they are
> used at the user level, the User Interface,
> The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed
> in its constituents.
> These decomposed primitive codes can be used in structures like archetypes
> at the proper places.
> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>
> But we keep the semantic differences codes expressed  using the SNOMED
> ontology and the Archetype and its codes.
> Ontologies have the Open World Assumption. A pre-corodinated code like:
> No-Cancer means never there was, is or will be cancer. Ontologies describe
> reality.
> In archetypes that use the Closed World Assumption Diagnosis=cancer,
> PresenceModifier=No means No Cancer found but perhaps they are. It just was
> not found. Presence of absence in a database are described.
>
>
> I'm unclear why you call this a use of the closed world assumption: the
> entire openEHR framework is for building HISs that enable reporting of
> reality as it is known to those working in it. So if they put 'No cancer'
> that just means that the current clinical thinking for some patient, *with
> respect to some investigation*, is that the original presenting problem
> is not cancer.
>
> That never means that the patient doesn't have cancer in their body
> somewhere, it just means that the currently investigated signs and symptoms
> don't relate to cancer, according to the the investigation carried out.
> Even that can be overturned later. But everyone assumes this - the EHR is
> always understood as an 'open world' system, where absence of X doesn't
> mean negation of X, it just means that no-one has investigated X.
>
> - 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
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: openEHR Toolkit

[Pablo Pazos]

this is a simple app, Java only.

On Thu, Mar 29, 2018, 04:04 A Verhees <bert.verh...@rosa.nl> wrote:

>
>
> Op do 29 mrt. 2018 02:39 schreef Pablo Pazos <pablo@gmail.com>:
>
>> For now this is just a place that integrates some of the tools I
>> developed, and will add more soon.
>> If you have open tools developed in Java, I can try to integrate them
>> into the CoT.
>>
>
> It is Java only? I was hoping for an open architecture.  Is it an idea to
> refactor it in that way?
>
>
>> On Mar 28, 2018 3:58 AM, "A Verhees" <bert.verh...@rosa.nl> wrote:
>>
>> Very interesting  initiative. Is it an idea to make it some kind an open
>> framework/platform infrastructure so that other developers can collaborate
>> or hang their software in?
>>
>> Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:
>>
>>> 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
>>> 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
>>
>>
>> ___
>> 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 Toolkit

[Pablo Pazos]

For now this is just a place that integrates some of the tools I developed,
and will add more soon.
If you have open tools developed in Java, I can try to integrate them into
the CoT.

On Mar 28, 2018 3:58 AM, "A Verhees" <bert.verh...@rosa.nl> wrote:

Very interesting  initiative. Is it an idea to make it some kind an open
framework/platform infrastructure so that other developers can collaborate
or hang their software in?

Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:

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

openEHR Toolkit

[Pablo Pazos]

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

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

[Pablo Pazos]

Yep, I know https://docs.oracle.com/javase/tutorial/datetime/iso/period.html

But this is not about anything Java specific, just giving an example why
Duration might not be good for an assumed type on the openEHR specs :)

On the other hand... (re)thinking: assumed types should not be considered
as "supported by a programming language", but "supported by a programming
language or application" ***. For instance, it is not so difficult to
create a Duration class ourselves on any programming language, or even use
one of the many available libraries that deal with Duration types and are
compatible with ISO8601 durations.

Considering that, we might need to clarify:

1. What "assumed type" really is (it seems most tend to think that should
be supported by a programming language, need to double check the specs to
see how this is defined, maybe is clearly defined but not highlighted
enough).

2. Clarify the use of the Duration class from CDuration where Duration is
not on the specs (we can say it is assumed considering assumed as the
definition ***)

3. Complementing 2. we can propose support for Duration on many programming
languages by recommending certain libraries or core types. This can be an
ITS or just an addendum/errata to v1.0.2 specs.


I think those points will solve all the issues mentioned on this thread.


On Tue, Mar 20, 2018 at 5:10 PM, Pieter Bos <pieter@nedap.com> wrote:

> Java 8 has a Duration for hours, minutes and seconds, and Period for
> years, months and days. Both implement a few interfaces with which you can
> abstract them.
> No idea why they chose this, it’s quite annoying to work with. You can
> relatively easily implement your own variant of ChronoPeriof that supports
> all of the options.
>
> Regards,
>
> Pieter Bos
>
> Op 20 mrt. 2018 om 21:06 heeft Pablo Pazos <pablo.pa...@cabolabs.com<
> mailto:pablo.pa...@cabolabs.com>> het volgende geschreven:
>
> Thanks Thomas, will create the PR!
>
> Also will double check if the same happens with other types, but I think
> the only "odd" one that might not be correct to assume, is the Duration.
> For instance, Java 8 added the Duration as a base type, but it only handles
> day to seconds duration expressions, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org<
> mailto:thomas.be...@openehr.org>> wrote:
>
>
> On 19/03/2018 22:25, Pablo Pazos wrote:
> Hi Thomas, the definition of DV_DURATION is clear to me :)
>
> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
> C_DURATION because the referenced Duration class in C_DURATION was not
> included on the specs. This is the issue I'm pointing to, the missing class.
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a new
> course. There might be issues like this on other areas of 1.0.2, I mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline spec and use AOM2, but I
> can't afford the cost right now. I'm sure others are on my same position.
>
> hopefully that will change soon, because ADL2 is more regular and simpler
> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
> interested to know what the real costs are and to see what we can do to
> make the transition simpler, because staying with ADL1.4 is limiting system
> functionality for the future.
>
>
> BTW tried to check if the issue is also on 1.0.3 but the link to support
> is broken http://openehr.org/RM/Release-1.0.3/support.html
>
> the page where you got that link<https://www.openehr.org/
> releases/RM/Release-1.0.3/docs/index> is now fixed.
>
> - th

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

[Pablo Pazos]

Thanks Thomas, will create the PR!

Also will double check if the same happens with other types, but I think
the only "odd" one that might not be correct to assume, is the Duration.
For instance, Java 8 added the Duration as a base type, but it only handles
day to seconds duration expressions, year, month, week are not supported.
Each technology has it's own quirks :)

On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org>
wrote:

>
>
> On 19/03/2018 22:25, Pablo Pazos wrote:
>
> Hi Thomas, the definition of DV_DURATION is clear to me :)
>
> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
> C_DURATION because the referenced Duration class in C_DURATION was not
> included on the specs. *This is the issue I'm pointing to, the missing
> class.*
>
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that
> spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a new
> course. There might be issues like this on other areas of 1.0.2, I mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline spec and use AOM2, but I
> can't afford the cost right now. I'm sure others are on my same position.
>
>
> hopefully that will change soon, because ADL2 is more regular and simpler
> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
> interested to know what the real costs are and to see what we can do to
> make the transition simpler, because staying with ADL1.4 is limiting system
> functionality for the future.
>
>
> BTW tried to check if the issue is also on 1.0.3 but the link to support
> is broken http://openehr.org/RM/Release-1.0.3/support.html
>
>
> the page where you got that link
> <https://www.openehr.org/releases/RM/Release-1.0.3/docs/index> is now
> fixed.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

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

[Pablo Pazos]

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

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

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


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

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

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

On Mon, Mar 19, 2018 at 4:03 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:

>
>
> On 19/03/2018 18:33, Pablo Pazos wrote:
>
> Thanks Thomas, I see the Duration class on the baseline BASE model
>
> http://openehr.org/releases/BASE/latest/docs/foundation_
> types/foundation_types.html#_overview_5
>
> But I'm a 1.0.2 implementer and I guess there are others. As far as I can
> see, there is no Duration class for 1.0.2. I would be good to add a
> disclaimer or errata comment for 1.0.2 maybe guiding to use ISO8601_DURATION
> or DV_DURATION in CDuration.
>
>
> DV_DURATION has never been the target type of C_DURATION - DV_DURATION is
> a complex type in the DV_ORDERED hierarchy (i.e. a sibling more or less of
> DV_QUANTITY).
>
>
> IMO that can generate a mismatch between implementations. For instance,
> the Java Ref uses DV_DURATION in CDuration https://github.com/
> wware/openehr-java/blob/master/openehr-aom/src/main/
> java/org/openehr/am/archetype/constraintmodel/primitive/
> CDuration.java#L186
>
>
> I don't know why they do that - that is not what the spec says.
>
> - thomas
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

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

[Pablo Pazos]

Thanks Thomas, I see the Duration class on the baseline BASE model

http://openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_overview_5

But I'm a 1.0.2 implementer and I guess there are others. As far as I can
see, there is no Duration class for 1.0.2. I would be good to add a
disclaimer or errata comment for 1.0.2 maybe guiding to use ISO8601_DURATION
or DV_DURATION in CDuration.

IMO that can generate a mismatch between implementations. For instance, the
Java Ref uses DV_DURATION in CDuration
https://github.com/wware/openehr-java/blob/master/openehr-aom/src/main/java/org/openehr/am/archetype/constraintmodel/primitive/CDuration.java#L186



On Mon, Mar 19, 2018 at 12:13 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> Hi Pablo,
>
> you should use the specs on the main spec home page
> <http://www.openehr.org/programs/specification/workingbaseline>; in this
> case I guess it is the AOM 1.4 spec
> <http://www.openehr.org/releases/AM/latest/docs/AOM1.4/AOM1.4.html#_primitive_package>
> you want to refer to.
>
> We now have the basic time types in the Foundation types spec
> <http://www.openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_time_types>.
> Both Duration and Iso8601_Duration are defined. For the archetype spec, the
> former is assumed, because ISO8601 syntax representation is used in
> archetypes.
>
> The specification is much better (but different) in AOM2
> <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_c_duration_class>
> .
>
> - thomas
>
> On 19/03/2018 05:24, Pablo Pazos wrote:
>
> Hi,
>
> Looking at CDuration http://www.openehr.org/releases/1.0.2/architecture/
> am/aom.pdf page 46, the range constraint is defined with a Duration class.
>
> On the support specs http://www.openehr.org/releases/1.0.2/architecture/
> rm/support_im.pdf page 30 we have the ISO8601_DURATION class.
>
> Should AOM reference that class or we have another Duration class
> somewhere?
>
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
> ISO8601_DURATION). http://www.openehr.org/releases/1.0.2/architecture/
> rm/data_types_im.pdf page 54
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

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

[Pablo Pazos]

Hi Gerard, this is about the current specs, not about what is supported by
programming languages.

On Mon, Mar 19, 2018, 05:57 GF <gf...@luna.nl> wrote:

> Again my thoughts
>
> Duration is not a Data Type in many computer languages.
> So we need to model it in an Archetype (Chairos)
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Mar 2018, at 06:24, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>
> Hi,
>
> Looking at CDuration
> http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf page 46,
> the range constraint is defined with a Duration class.
>
> On the support specs
> http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf page
> 30 we have the ISO8601_DURATION class.
>
> Should AOM reference that class or we have another Duration class
> somewhere?
>
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
> ISO8601_DURATION).
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf page
> 54
>
>
> ___
> 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

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

[Pablo Pazos]

Hi,

Looking at CDuration
http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf page 46, the
range constraint is defined with a Duration class.

On the support specs
http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf page
30 we have the ISO8601_DURATION class.

Should AOM reference that class or we have another Duration class somewhere?

Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
ISO8601_DURATION).
http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf
page 54


Thanks!

-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

+1 but for the focus of this conversation I think we are trying to solve
(find a relatively good enough solution) the clinical side and use detailed
terminologies for that.

On Wed, Mar 14, 2018 at 8:56 PM, Mikael Nyström <mikael.nyst...@liu.se>
wrote:

> Hi Pablo,
>
>
>
> Yes, of cause it is! My main point was that a statistical classification
> is a simpler product than a clinical ontology and it is therefore also
> easier to implement a statistical classification than a clinical ontology.
> But if your use case require a clinical ontology instead of a statistical
> classification, you need to accept that it is more difficult to implement a
> clinical ontology than a statistical classification.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* den 14 mars 2018 23:58
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* RE: [Troll] Terminology bindings ... again
>
>
>
> But ICD is a statistical not a clinical tool.
>
>
>
> On Mar 14, 2018 7:10 PM, "Mikael Nyström" <mikael.nyst...@liu.se> wrote:
>
> Hi,
>
>
>
> Of cause it is possible to create something that is easier to use. ICD-10
> is a good example of something that have similarities with SNOMED CT and is
> both (for some use cases) easier to implement and more widespread. But I if
> you want something that is based on logic, because you want to use logic
> functions when you use the system, it comes with the complexity of logic.
> And it is not that complex to implement SNOMED CT. The problem is probably
> that we have fewer trained people in health informatics (including in for
> example SNOMED CT and openEHR) that in other informatics areas.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Philippe Ameline
> *Sent:* den 13 mars 2018 13:32
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: [Troll] Terminology bindings ... again
>
>
>
> Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :
>
>
>
> I am get the impression that SNOMED CT is hard to implement, and therefore
> wondered if we are at some kind of tipping point, like where HL7v3 was a
> few years ago, and some bright spark came along, and now we have FHIR that
> is gaining great traction in the health community due to the ease at which
> it can be implemented.
>
>
> Hi John,
>
> The tipping point will only get reached when a sufficient amount of Snomed
> users will state that it is uselessly hard to implement... and when someone
> will invent a smart way to simplify it... not there yet ;-)
>
> But I really insist on the two orthogonal issues at stake:
> 1) a component should ease your job and not kill your project (detect
> "dead horses" early),
> 2) a component should not keep you stuck in the wrong (ancient) reference
> frame.
>
> No need to say that FHIR is easier to put at work than the plain RIM, but
> it still keeps its community in a system where "boxes that saw the patient
> passing by can exchange information" when we should (due to both the
> chronic turn and the information society era) be dedicated to organize
> multidisciplinary teamwork around patients.
>
> Best,
>
> Philippe
>
>
> ___
> 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
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

RE: [Troll] Terminology bindings ... again

[Pablo Pazos]

But ICD is a statistical not a clinical tool.

On Mar 14, 2018 7:10 PM, "Mikael Nyström"  wrote:

> Hi,
>
>
>
> Of cause it is possible to create something that is easier to use. ICD-10
> is a good example of something that have similarities with SNOMED CT and is
> both (for some use cases) easier to implement and more widespread. But I if
> you want something that is based on logic, because you want to use logic
> functions when you use the system, it comes with the complexity of logic.
> And it is not that complex to implement SNOMED CT. The problem is probably
> that we have fewer trained people in health informatics (including in for
> example SNOMED CT and openEHR) that in other informatics areas.
>
>
>
>Regards
>
>Mikael
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Philippe Ameline
> *Sent:* den 13 mars 2018 13:32
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: [Troll] Terminology bindings ... again
>
>
>
> Le 13/03/2018 à 12:32, GEORGE, John (NHS DIGITAL) a écrit :
>
>
>
> I am get the impression that SNOMED CT is hard to implement, and therefore
> wondered if we are at some kind of tipping point, like where HL7v3 was a
> few years ago, and some bright spark came along, and now we have FHIR that
> is gaining great traction in the health community due to the ease at which
> it can be implemented.
>
>
> Hi John,
>
> The tipping point will only get reached when a sufficient amount of Snomed
> users will state that it is uselessly hard to implement... and when someone
> will invent a smart way to simplify it... not there yet ;-)
>
> But I really insist on the two orthogonal issues at stake:
> 1) a component should ease your job and not kill your project (detect
> "dead horses" early),
> 2) a component should not keep you stuck in the wrong (ancient) reference
> frame.
>
> No need to say that FHIR is easier to put at work than the plain RIM, but
> it still keeps its community in a system where "boxes that saw the patient
> passing by can exchange information" when we should (due to both the
> chronic turn and the information society era) be dedicated to organize
> multidisciplinary teamwork around patients.
>
> Best,
>
> Philippe
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Pablo Pazos]

I got it, when I said standardizing diagnosis you might thought of your
specific implementation / experience. But I was talking about the strategy,
not the implementation.

The strategy can be good and implementations fail miserably, is not a
problem of the strategy :)

As I said, primary coding is the worst way of implementing this, should not
be recommended by any literature, and software vendors / organizations /
govt imposing that should be held responsible for bad implementations.

On Tue, Mar 13, 2018 at 6:45 PM, Karsten Hilbert <karsten.hilb...@gmx.net>
wrote:

>  There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>  But I'm not sure if Karsten was talking about this, let's wait :)
>
>
>
>
> I was mainly talking about the first, which is standard in German
> ambulatory care.
>
> Karsten
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

There are many implementation solutions for primary, assisted and secondary
coding.

In assisted coding what you mention is one way.

The best solution IMO that I saw implemented is free text search, matching
to an interface terminology that internally maps to SNOMED. The interface
terminology is controlled, and based on real terms gathered from users, so
this methodology adapts to the location and usage. And what the wizard
provides are alternative and suggested terms from the interface
terminology. Everything is a tree here but no tree is shown to the end
user, they just see free text suggestions for his/her input. A team of
experts maintains the interface terminology and mappings to SNOMED.
Mappings to other terminologies can be done, for instance with LOINC, or
even ICD for statistics.

This is the approach of a health provider in Argentina and is the way the
national EHR strategy is being implemented in Uruguay. I think Chile will
also follow those steps.

On Tue, Mar 13, 2018 at 3:55 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> I would put it the other way around: it can only be done with structured,
> controlled subsets, that retain hierarchy from the original terminology,
> remove unneeded codes, and do a few other tricks (adding non-coding 'group'
> concepts to help guide the user). This has to be done using smart tree
> controls, or anything that logically works as a tree-based choosing tool.
>
> No flat lists ;)
>
> - thomas
>
> On 13/03/2018 18:33, Pablo Pazos wrote:
>
> It is a very very very bad practice to ask clinicians to code!
>
> Standardizing diagnosis is a very different thing than asking clinicians
> to code, the first is the strategy, the second is one possible, and bad,
> implementation.
>
> There are 3 ways of "coding" that I know of: 1. primary coding (ask
> clinicians and other clinical users to code directly), 2. secondary coding
> (users record information, a team of specialists do the coding later), 3.
> assisted coding (software helps users to code, and there are many ways of
> doing this, from NLP to GUI wizards).
>
> But I'm not sure if Karsten was talking about this, let's wait :)
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

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

[Pablo Pazos]

It is a very very very bad practice to ask clinicians to code!

Standardizing diagnosis is a very different thing than asking clinicians to
code, the first is the strategy, the second is one possible, and bad,
implementation.

There are 3 ways of "coding" that I know of: 1. primary coding (ask
clinicians and other clinical users to code directly), 2. secondary coding
(users record information, a team of specialists do the coding later), 3.
assisted coding (software helps users to code, and there are many ways of
doing this, from NLP to GUI wizards).

But I'm not sure if Karsten was talking about this, let's wait :)


On Tue, Mar 13, 2018 at 3:25 PM, Diego Boscá <yamp...@gmail.com> wrote:

> I assume the reason is that asking clinicians to do coding without any
> help provides great variability and leads to coding errors. What Thomas
> said about presenting clinicians with addecuated subsets is key to avoid
> that. There are also mechanisms to check coding quality/errors, but usually
> need high domain & terminology knowledge (but creating systems that 'learn'
> from documentalists' knowledge is feasible)
>
> El mar., 13 mar. 2018 19:03, Pablo Pazos <pablo.pa...@cabolabs.com>
> escribió:
>
>>
>>
>> On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert <karsten.hilb...@gmx.net
>> > wrote:
>>
>>> > just imagine standardizing every diagnosis
>>>
>>> That typically leads to either bad statistics or disimproved care.
>>>
>>
>> Can I ask why?
>>
>>
>>>
>>> Karsten
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> technical_lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pa...@cabolabs.com
>> +598 99 043 145 <099%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
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

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

[Pablo Pazos]

On Tue, Mar 13, 2018 at 2:15 PM, Karsten Hilbert <karsten.hilb...@gmx.net>
wrote:

> > just imagine standardizing every diagnosis
>
> That typically leads to either bad statistics or disimproved care.
>

Can I ask why?


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



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

gt;appropriate representation and tools
>- embark on an exercise to graft in appropriate upper level
>ontology/ies, i.e. BFO2, RO, and related ontologies (this is where the <10
>comes from by the way)
>- specify standards for URIs, querying, ref-sets that *work across all
>terminologies*, not just SNOMED CT
>
> A further program would look at integrating units (but not by the current
> method of importing to SNOMED, which is a complete error because of the
> different meta-models), drugs and substances (same story), lab result
> normal and other range data, and so on. None of this can be done without
> properly studying and developing the underlying ontologies, which are
> generally small, but subtle.
> I'll stop there for now. I suspect I have kicked the hornet's nest, but
> since Grahame kicked it first, and I can run faster than him, I feel oddly
> safe. Probably an illusion.
>
> - thomas
>
>
> On 13/03/2018 12:12, Grahame Grieve wrote:
>
>
>>
>> I am get the impression that SNOMED CT is hard to implement, and
>> therefore wondered if we are at some kind of tipping point, like where
>> HL7v3 was a few years ago, and some bright spark came along, and now we
>> have FHIR that is gaining great traction in the health community due to the
>> ease at which it can be implemented.
>>
>
> this is very true, and I wish that someone would stick their neck out and
> do this at scale with
> a community behind them. Many of the parameters for how it could be done
> are obvious around
> free and crowd-support etc. But the big problem is that there is no
> capacity for it to happen as a
> palace revolution; it must be a full civil war first.
>
> Grahame
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

Hi,

IMO having s national terminology server like we have in Uruguay, is a
first step of delivering. jus imagine standardizing every diagnosis, every
procedure and every drug around the country? I can only see benefits for
clinical environments and public health, they will have data to actually
see what's happening in a complex system. also this is part of a state
strategy for health accessibility.

BTW, we don't have tons of money, so even if some tactical areas fail, is
the investment of learning. But we are learning from institutions that
already did this and using their experience, this  not an isolated journey
reinventing the wheel.

There are 3 questions to make when your are starting: 1. Is there any use
of SNOMED in my ehealth strategy? 2. Is there an alternative? 3. What's the
cost of SNOMED vs. the alternative?

I'm an engineer and just recently I was understood the real value of SNOMED
sheet using it for data querying. Without getting your hand dirty a little
bit is difficult to know for sure what are the pros and cons. Obviously
this is not a panacea and needs a lot of work to implement and maintain.
ROI is long term as in everything in ehealth (like implementing openEHR!)

best,
Pablo

On Mar 13, 2018 6:20 AM, "Philippe Ameline" <philippe.amel...@free.fr>
wrote:

> Pablo, I wish you sincerely all the best.
>
> IMHO, the question is not really to enroll but to deliver... and
> considering the tremendous amount of money that was invested in HL7 and
> Snomed (both to elaborate and try to implement) and the actual societal
> return, there is such a discrepancy that the hypothesis that, due to
> missing the "information society" turn, health systems are entering
> terrible crisis times is to be considered seriously.
>
> In current "information society", you have two options when considering
> "health information systems":
> 1) You dedicate yourself to "medical information systems" instead, and can
> freely build for (inter-connected) silos,
> 2) You consider "health" in its genuine meaning and you have to realize
> that it is a complex domain fully opened to all other societal issues...
> hence should ban components that are endemic to medicine.
>
> Maybe (and I really mean it for Latin America), it should be high time to
> leapfrog, not to join the "dollars wasting club" ;-)
>
> Philippe
>
> Le 12/03/2018 à 18:17, Pablo Pazos a écrit :
>
> In Latin America is all the contrary, more countries are becoming SNOMED
> members and adopting SNOMED at the govt level.
>
> On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline <
> philippe.amel...@free.fr> wrote:
>
>> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>>
>> > IMO we should focus on SNOMED.
>>
>> Hi,
>>
>> There is currently some kind of interesting momentum against Snomed.
>>
>> It can come from governments that refuse to pay for it (current mood in
>> France), of from practitioners who, after having been asked by their gov
>> to "sort out their Snomed subset" came to the conclusion that it doesn't
>> exist.
>>
>> Some also predict that the most certain result of keeping up
>> trying to build systems using such shitty fully endemic components is to
>> have medical doctors disappear from missing the "information society"
>> turn.
>>
>> Have some of you been aware of the Meriterm (European) project?
>>
>> Best,
>>
>> Philippe
>>
>>
>> ___
>> 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 <099%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 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

Thanks Thomas, I added a paragraph about the UI generation modes at the
end, I forgot to mention that yesterday.

On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> Pablo,
>
> Good work - I've included a reference to this doc in the original wiki
> page
> <https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets>,
> and added a few ideas about how to use it. It is very close to what I was
> thinking of.
>
> - thomas
>
> On 12/03/2018 07:31, Pablo Pazos wrote:
>
> Hi all,
>
> I manage to translate / update part of the work we did some years ago in
> terms of UI definition and generation for the openEHR stack.
>
> Here is the doc, feedback is very welcome!
>
> https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_
> T9H6UMsGNkiZoU7Iw/edit?usp=sharing
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

In Latin America is all the contrary, more countries are becoming SNOMED
members and adopting SNOMED at the govt level.

On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline <philippe.amel...@free.fr
> wrote:

> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current mood in
> France), of from practitioners who, after having been asked by their gov
> to "sort out their Snomed subset" came to the conclusion that it doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: Templates for application form development

[Pablo Pazos]

Hi all,

I manage to translate / update part of the work we did some years ago in
terms of UI definition and generation for the openEHR stack.

Here is the doc, feedback is very welcome!

https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing




On Wed, Feb 21, 2018 at 12:13 PM, A Verhees <bert.verh...@rosa.nl> wrote:

> Well, this sounds very good, so I can forget my babble about dependency
> circles, concerning this part of the specs
>
> I hope this will be in stable release very soon, because I need to have a
> stable definition for a project
>
> Thanks
> Bert
>
> Op 21 feb. 2018 3:21 p.m. schreef "Thomas Beale" <thomas.be...@openehr.org
> >:
>
>
>>
>> On 21/02/2018 13:00, Bert Verhees wrote:
>>
>>> On 20-02-18 20:09, Thomas Beale wrote:
>>>
>>>>
>>>>> The terminology service also has dependencies to rm data types, only
>>>>> because of codephrase. Wouldn't it be possible to avoid that?
>>>>>
>>>>
>>>> Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead
>>>> of CODE_PHRASE; eventually, the RM should just use that. If you found any
>>>> use of CODE_PHRASE in BASE, please let us know.
>>>>
>>>
>>> This is of course a good thing.
>>>
>>>
>>> But now the question, how do I know which definition to use.
>>>
>>> I always looked at this URL: http://www.openehr.org/program
>>> s/specification/workingbaseline
>>>
>>> There I found "Support", which brings me to:
>>>
>>> http://www.openehr.org/releases/RM/latest/docs/support/support.html
>>>
>>> In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
>>>
>>
>> yes - we are still working on this - to find the cleanest way to separate
>> it out without breaking current code.
>>
>>
>>>
>>> Now I read that there is a new class in BASE, I found the link:
>>> http://www.openehr.org/releases/BASE/latest/docs/index
>>>
>>> And I found Terminology_Code: http://www.openehr.org/release
>>> s/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
>>>
>>> Which is a real improvement, exactly what I was hoping for, it did not
>>> only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class
>>> from SUPPORT
>>>
>>> It has a property/field which is named terminology_id and is of type
>>> string
>>>
>>>
>>> Is this what is going to be the new standard?
>>>
>>> And when will this be like that?
>>>
>>
>> Well it will be the new standard for BASE classes very soon. Over time,
>> we will start either replacing CODE_PHRASE in the upper models with
>> TERMINOLOGY_CODE, or possibly adding some sort of mapping / conversion
>> logic. But we'll only do that based on input from implementers - we need to
>> find a way to update the models without breaking existing systems.
>>
>>
>>>
>>> When looking further, I also see that there is still a TERMINOLOGY_ID
>>> class in that document which is the old support terminology which is
>>> derived from OBJECT_ID
>>>
>>> http://www.openehr.org/releases/BASE/latest/docs/base_types/
>>> base_types.html#_terminology_id_class
>>>
>>>
>>> Is this confusing, or am I missing something stupid? Am I the only
>>> person asking this kind of questions? If yes, where do others get their
>>> information from?
>>>
>>> Please help me, because, I think, this is very important.
>>>
>>
>> you should consider the classes you see in BASE today as being what will
>> be issued, unless anyone finds a problem with them. In the near future, we
>> will continue the cleanup around terminology. One reason we have not
>> cleaned it up yet is because noone in industry agrees on what standard or
>> tools to use. Noone faithfully implements CTS2 for example, except a
>> non-maintained server from Mayo (LexGrid from memory). IHTSDO did something
>> different, and FHIR did something else.  All have good and bad points, but
>> there has been no clear specification.
>>
>> I am inclined to think that the specification of the future is a kind of
>> stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple
>> serialisation formats, and cleaner models, but semantically, more or less
>> the same. But we have to be practical too. Maybe the FHIR terminology
>> servi

Re: Terminology bindings ... again

[Pablo Pazos]

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms
of clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström <mikael.nyst...@liu.se>
wrote:

> Hi,
>
>
>
> Yes, it is correct that expressions include single code binding. Those
> kinds of bindings are just the simplest variants of expressions. :-)
>
>
>
> I think that in a few years’ time nearly all implementations of SNOMED CT
> not only implement the international version, but also one are a few
> international, national or local extensions, so this use case is probably
> the normal use case and not the exceptional use case.
>
>
>
>  Regards
>
>  Mikael
>
>  (Among other things SNOMED CT Implementation
> Advisor)
>
>
>
> *Från:* openEHR-clinical [mailto:openehr-clinical-
> boun...@lists.openehr.org] *För *Pablo Pazos
> *Skickat:* den 12 mars 2018 01:39
> *Till:* For openEHR clinical discussions <openehr-clinical@lists.
> openehr.org>
> *Kopia:* Openehr-Technical <openehr-technical@lists.openehr.org>
> *Ämne:* Re: Terminology bindings ... again
>
>
>
> Now that I have more experience with SNOMED expressions, I like the idea
> of doing the binding with an expression, also I think an expression
> includes the single code binding, if that is correct there is no need of
> defining a different notation for single code binding, just use a simple
> expression formed by one specific concept code. Also the expression being
> something processable and very versatile, we can express complex concepts
> with a few codes, which will help on adding knowledge to the archetype and
> serve to a better and simpler CDS.
>
> About the metadata, there should be expressed against which SNOMED release
> this expression was created. We can't be sure only with min version. I
> should be responsibility of the user to check if the expression works on a
> different version/release of SNOMED. Another metadata is if the version is
> a local extension, some countries have their own extensions.
>
> I don't know if we need to support other terminologies (technically) and
> if doing that is useful (strategically). Terminology services can do SNOMED
> to ICD, and ICD is not clinical relevant. LOINC is useful, but there is a
> SNOMED-LOINC collaboration, so we might expect an official mapping in the
> future (https://loinc.org/collaboration/snomed-international/). IMO we
> should focus on SNOMED.
>
>
>
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
> Recently we discussed terminology bindings. We probably still have not got
> them right, but we don't have a model of what we think they should be. I
> posted a quick idea of a possible more structured version:
>
>
> *term_bindings* = <
>
> ["snomed_ct"] = <
>
> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
> (SIMPLE_BINDING) <
>
>  target = <http://snomedct.info/id/169895004> *-- Apgar score at 
> 1 minute*
>
>  notes = <"some notes">
>
>  min_version = <"2017-02-01">
>
>  etc = <"etc">
>
>   >
>
> ["id26"] = (CONSTRAINT_BINDING) <
>
>target = <"71388002 |Procedure| : 405815000 |Procedure device| 
>  =  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
> action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian 
> structure|">
>
>   min_version = <"2017-04-01">
>
>notes = <"some notes">
>
>etc = <"etc">
>
>>
>
> >
>
> >
>
>
> I noted that the right hand side of a binding can be a few different
> things, each of which would be accompanied by various meta-data, including:
>
>- a single concept code
>- a single code or other id referring to an external value set in an
>external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there
>is no standard that I know of)
>- a composition expression that refers to a more refined concept
>- possible a constraint expression that locally determines a value set
>intensionally, to be resolved by application to the Terminology service.
>
> I'd rather avoid the last, because of the brittleness of intensional
> ref-set query syntax expressions. In any case, we need a better idea of
> what meta-data are needed. E.g.:
>
>- somethi

Re: Terminology bindings ... again

[Pablo Pazos]

Now that I have more experience with SNOMED expressions, I like the idea of
doing the binding with an expression, also I think an expression includes
the single code binding, if that is correct there is no need of defining a
different notation for single code binding, just use a simple expression
formed by one specific concept code. Also the expression being something
processable and very versatile, we can express complex concepts with a few
codes, which will help on adding knowledge to the archetype and serve to a
better and simpler CDS.

About the metadata, there should be expressed against which SNOMED release
this expression was created. We can't be sure only with min version. I
should be responsibility of the user to check if the expression works on a
different version/release of SNOMED. Another metadata is if the version is
a local extension, some countries have their own extensions.

I don't know if we need to support other terminologies (technically) and if
doing that is useful (strategically). Terminology services can do SNOMED to
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a
SNOMED-LOINC collaboration, so we might expect an official mapping in the
future (https://loinc.org/collaboration/snomed-international/). IMO we
should focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> Recently we discussed terminology bindings. We probably still have not got
> them right, but we don't have a model of what we think they should be. I
> posted a quick idea of a possible more structured version:
>
> term_bindings = <
> ["snomed_ct"] = <
> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
> (SIMPLE_BINDING) < target = <http://snomedct.info/id/169895004> 
> -- Apgar score at 1 minute notes = <"some notes">
>   min_version = <"2017-02-01">
>   etc = <"etc">
>   >
> ["id26"] = (CONSTRAINT_BINDING) < target = <"71388002 
> |Procedure| : 405815000 |Procedure device|  =  122456005 |Laser device| , 
> 260686004 |Method|  =  129304002 |Excision - action| ,405813007 |Procedure 
> site - direct|  =  1549700l6 |Ovarian structure|">min_version 
> = <"2017-04-01">
>   notes = <"some notes">
>   etc = <"etc">
>   >
> >
> >
>
>
> I noted that the right hand side of a binding can be a few different
> things, each of which would be accompanied by various meta-data, including:
>
>- a single concept code
>- a single code or other id referring to an external value set in an
>external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there
>is no standard that I know of)
>- a composition expression that refers to a more refined concept
>- possible a constraint expression that locally determines a value set
>intensionally, to be resolved by application to the Terminology service.
>
> I'd rather avoid the last, because of the brittleness of intensional
> ref-set query syntax expressions. In any case, we need a better idea of
> what meta-data are needed. E.g.:
>
>- something to do with (min) version of terminology required for the
>reference to be valid
>- something to do with purpose?
>- other notes - a tagged list of basic types?
>
> I would like to get a better idea of the requirements.
>
> - 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-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Improving the specification for DV_PARSABLE, specially for ACTIVITY.timing

[Pablo Pazos]

Hi all,

The specs have a very loose definition of DV_PARSABLE that makes it hard
for developers to know how to use it correctly.

The first issue is on the DV_PARSABLE.formalism attribute.


*1) In the data_types spec there is no clear terminology associated with
the formalism.*

Current: "Name of the formalism, e.g. GLIF 1.0 , Proforma etc." [1]

Expected: An internal terminology, or references to acceptable external
terminologies, like IANA Media Types [2], or subsets of such external
terminologies (not all IANA Media Types should be considered as
DV_PARSABLE, for instance the binary ones like images, audio, etc.)


[1]
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class
[2] https://www.iana.org/assignments/media-types/media-types.xhtml


*2) In the ehr spec, ACTIVITY.timing is DV_PARSABLE, again the formalism
has a loose definition.*

Current: "Timing of the activity, in the form of a parsable string, such as
an HL7 GTS or ISO8601 string." [3]

Expected: specify a terminology of acceptable codes for the formalism of
timing expressions. Should we consider "HL7 GTS" and "ISO8601" as valid
codes for the formalism attribute?


[3]
http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_activity_class


*3. DV_PARSABLE.formalism is String [4], not DV_CODED_TEXT.*

This generates an interoperability problem, since each implementation is
free of putting virtually anything on the formalism making it almost
impossible for an external system, receiving this data, to correctly parse
the DV_PARSABLE value.

IMO we need to analyze the change on the SEC, and release an ITS for the
correct usage of the formalism if it is String (applies to current and
previous versions of the spec) and if that changes to DV_CODED_TEXT, also
create a guide for that.

This comes from real customers trying to implement this and sending
anything on the formalism.


[4]
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class


*4. Trying to avoid accepting "anything" on the formalism*

What I did on the EHRServer is to validate the formalism values from the
XSD, basically defining my own terminology of accepted values for the
formalism, some IANA for known parsable object representations, and some
specific for the ACTIVITY.timing.

For the ACTIVITY.timing I'm inclined to include FHIR_GTS_ABBREVIATION [5]
and FHIR_TIMING_EVENT [6]


[5] https://www.hl7.org/fhir/valueset-timing-abbreviation.html
[6] https://www.hl7.org/fhir/valueset-event-timing.html


This is my solution:


  
   

 
 

 
 

  

  
  
  
  
  
  
  
  
  

  


   
  
 



*5. The format for DV_PARSABLE.value when using serialization formats,
should be defined based on the formalism.*

When an instance of a COMPOSITION is serialized to XML or JSON, the
contents from DV_PARSABLE.value should be processed in such way that don't
break the serialization format. For instance, if the DV_PARSABLE.formalism
is XML or HTML and the serialization format is XML, just putting the value
as XML or HTML will break the whole COMPOSITION XML.

Currently we don't have an ITS guide that says how to do that correctly.
The poor man solution is to always encode the value in base64, but that
generates an interoperability problem, since there is no place on the
DV_PARSABLE to specify that the value is base64 encoded.

In HL7 there is the ED (encapsulated data) datatype that is similar to the
openEHR DV_ENCAPSULATED, but HL7 ED [7] has the encoding attribute that can
be used to say "this is base64 encoded" [8]. I think we don't have
something similar, and maybe we should.


[7]
http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1=ED
[8]
http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1=0299


There are a couple of related CRs on JIRA

https://openehr.atlassian.net/browse/SPECPR-242
https://openehr.atlassian.net/browse/SPECPR-126



Anyone else has problems with this area of the specs? How did you solve
that?

-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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-techn

Re: Setting thresholds

[Pablo Pazos]

Hi Jan-Marc,

We implemented a similar tool a couple of years ago, the limits and goals
were store in the system, not as openEHR artifacts.

Best,
Pablo.

On Wed, Feb 28, 2018 at 8:48 AM, Jan-Marc Verlinden <jan-m...@medrecord.io>
wrote:

> We are developing a completely openEHR based Personal Health Environment
> (PHR). For this we would like to show measured data in a graph containing
> "good" or "bad". Mostly one would see some traffic light system, our
> approach is different but comes to the same principle.
>
> So for this we need to set thresholds that also could be changed
> afterwards. In the most common BP archetype (and Template) no thresholds
> are defined, so at what level would we do that?
> --
>
> Regards, Jan-Marc
> Mobile: +31 6 53785650 <+31%206%2053785650>
> www.medrecord.io
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: Templates for application form development

[Pablo Pazos]

Jussara,

Here is a copy of the paper we presented on INFOLAC 2014

https://www.slideshare.net/pablitox/generacin-automtica-de-interfaces-de-usuario-para-sistemas-de-informacin-clnicos-basados-en-una-metodologa-multinivel

The presentation

http://www.sueiidiss.org/images/archivos2015/temasinfolac/22.pdf

That paper is referenced from my MEDINFO 2015 paper

https://books.google.com.uy/books?id=OmZrCgAAQBAJ=PA49=PA49=Generaci%C3%B3n+autom%C3%A1tica+de+interfaces+de+usuario+para+sistemas+de+informaci%C3%B3n+cl%C3%ADnicos+basados+en+la+metodolog%C3%ADa+multinivel=bl=GAd8sfgJuz=UK5rAgO1xrSUEnrUPpWPxDdSJ-E=en=X=0ahUKEwjh_vPPoLbZAhWimeAKHaexDkoQ6AEIMDAB#v=onepage=Generaci%C3%B3n%20autom%C3%A1tica%20de%20interfaces%20de%20usuario%20para%20sistemas%20de%20informaci%C3%B3n%20cl%C3%ADnicos%20basados%20en%20la%20metodolog%C3%ADa%20multinivel=false


All are also here
http://independent.academia.edu/pablopazos



Since then, I have updated the UITemplate model to use OPTs instead of
archetypes directly, added improvements and features that are not in the
initial model from the paper. The new model still needs work, but we proven
we can use it as an abstract, generic, declarative openEHR UI definition
focused on data entry and form-oriented visualization. And that technology
specific UI generators can use it to output other declarative form UI
specifications, that dev tools / IDEs can take in order to render UIs. E.g.
from an UITemplate instance in XML,  different generators can generate XAML
(.NET UI definitions), SwiXML (Java Swing UI definitions), XHTML/HTML5 (for
web), and there are XML UI definitions also for Android and iOS that can be
generated. Basically generators are XML mappers, and knowing the
destination schema is really easy to create the maping rules between input
UITemplates and X technology UI definition.

A second level, of definition is also missing, about the rules for data
input, like "if field X has a value, show field Y". I don't think we need
to specify mandatory or cardinality constraints on the UITemplate since the
OPT already has those and the UITemplate should just define UI stuff that
is not on the referenced OPT.

I hope to have an updated & translated spec for next week.

Best,
Pablo.

On Tue, Feb 20, 2018 at 1:52 PM, Pablo Pazos <pablo.pa...@cabolabs.com>
wrote:

> Let me look for it, haveit on a backup disk somewhere :)
>
> On Tue, Feb 20, 2018 at 9:59 AM, Jussara Macedo Rötzsch <jussara.macedo@
> coreconsulting.com.br> wrote:
>
>> Could we have access to that Pablo?
>> Regards
>> Jussara Rotzsch
>>
>> Em dom, 18 de fev de 2018 às 15:58, Pablo Pazos <pablo.pa...@cabolabs.com>
>> escreveu:
>>
>>> I have a pdf spec in Spanish, this was a university project to have
>>> platform independent GUI definitions based on opts, while creating
>>> technology specific GUI generators for data entry and display. I mentioned
>>> this a while ago on the lists but catched not much attention.
>>>
>>> Need to do a little translation work :)
>>>
>>>
>>> On Feb 18, 2018 7:51 AM, "Thomas Beale" <thomas.be...@openehr.org>
>>> wrote:
>>>
>>>
>>>
>>> On 17/02/2018 20:11, Pablo Pazos wrote:
>>>
>>>> I think SET has a lot of applications, including result
>>>> sets. Of course that should interior from LOCATABLE to be archetypable.
>>>>
>>>> I'm not sure on the types associated with the UI. I have a
>>>> specification for UITenplates that includes some of that, I can share it :)
>>>>
>>>>
>>> I think any existing UI/template specification / app modelling would be
>>> useful to share - possibly on the wiki - let me know if you need a page
>>> there.
>>>
>>> My aim would be to get closer to an IDE application building tool for
>>> clinical people to at least build a POC application that works, something
>>> like Balsamiq but with real data connections built in. Marand's EhrExplorer
>>> does some of this, and it would also be useful to extract some of the
>>> semantics of that tool into a standard specification to support this kind
>>> of thing.
>>>
>>> - thomas
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/ope

Re: Templates for application form development

[Pablo Pazos]

Templates have no information about user interfaces, are mainly full
document data structures + semantic definitions + constraints + terminology
(local and bindings).

User interface information includes layout, form composition, position,
size, style, etc. Clearly this is not included in current openEHR templates.

BTW all those elements are part of the UITemplate model that I mentioned
before. Will try to have an english translation to share next week.

On Tue, Feb 20, 2018 at 10:58 AM, GF <gf...@luna.nl> wrote:

> Hi,
>
> There is NO need for an other RM.
>
> Templates (imo) describe an interface.
> Templates for an interface used for display only need annotations in the
> appropriate nodes of the Display Archetype
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Feb 2018, at 10:29, Bert Verhees <bert.verh...@rosa.nl> wrote:
>
> On 19-02-18 10:21, Diego Boscá wrote:
>
> Personally I would prefer if no visualization attributes ended up in the
> EHR RM, but I'm fine if we want to create an additional RM to handle
> visualization (and we create templates of that model that point to the EHR
> model)
>
>
> I agree on this!
>
> (again sloppy English in my previous message, this time changing the
> meaning, I changed the quote below, I am awake now, will not happen again,
> excuse me)
>
>
> 2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl>:
>
>> On 18-02-18 23:09, GF wrote:
>>
>>> Is it an idea to annotate nodes with instructions for display.
>>>
>>
>> Personally I think having special templates/archetypes for display is
>> better. Templates are create*d* per purpose, and mixing purposes in a
>> single template does *no**t* seem good idea to me
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: Templates for application form development

[Pablo Pazos]

Let me look for it, haveit on a backup disk somewhere :)

On Tue, Feb 20, 2018 at 9:59 AM, Jussara Macedo Rötzsch <
jussara.mac...@coreconsulting.com.br> wrote:

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



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: Templates for application form development

[Pablo Pazos]

IMO annotating templates with UI info is not a good idea. A layered
approach is much cleaner and scalable, i.e. to define a new artifact on top
of current templates / archetypes / RM (these are also examples of layered
design).

Under this approach, if we have UITemplates on top of openEHR Templates,
when we generate Operational UITemplates, that will contain UI + structure
(template and archetype constraints) + RM references. This would be the
final element to be used to feed software. but the underlying models are
all separated and have a specific responsibility.

If we go ahead, we can add another level for workflow, defining an order
and conditions under which each "screen" should be displayed, like a
WFTemplate, having an Operational WFTemplate that will include all WF + GUI
+ structure + RM references.

We can continue adding layers :)

On Mon, Feb 19, 2018 at 10:23 AM, GF <gf...@luna.nl> wrote:

> Is there a terminology with concepts we can use to annotate?
> Probably there is and there are more.
> Which one, will be the question.
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Feb 2018, at 07:00, Erik Sundvall <erik.sundv...@liu.se> wrote:
>
>
> sön 18 feb. 2018 kl. 23:10 skrev GF <gf...@luna.nl>:
>
>> Is it an idea to annotate nodes with instructions for display.
>>
>
> Yes, using (mostly shared/standardised) annotations for GUI-rendering
> hints in templates (or layers of templates) has been a major idea in
> previous GUI-related discussions in openEHR mailing lists.
>
> //Erik
>
> (We should link to some old list posts on the topic in that wiki page Tom
> created)
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: Templates for application form development

[Pablo Pazos]

Yes, this is about two different problems

1. having extra RM structures tree be used to group RM data in different
ways than the one defined for a composition, in order to use y as a data
retrieval for APIs and GUI.

2. another level of definition, above OPTs, to specify GUI structures and
attributes, and maybe bindings with specific GUI technologies. This doesn't
affect current RM or change anything on the OPT model.

On Feb 19, 2018 8:08 AM, "Thomas Beale"  wrote:

>
> note that a key problem I want to address is that templates based on
> COMPOSITIONs don't really make sense as models of data retrieval/display
> forms - they are really only useful for data capture forms (or messages, or
> documents), because COMPOSITION is a container for committing data to the
> EHR.
>
> Displaying data is a different question - it may be EHR data, it may be
> demographic data, and it may be something else entirely. So the data items
> we want to mention in templates are mostly of ENTRY level, and will be the
> results of queries; the relevant queries could be included in such
> templates.
>
> So the starting point for many forms won't be a COMPOSITION - it is
> instead a different logical container that groups data that result from one
> or more queries, into a 'use group', i.e the group of data items intended
> to be visualised or used as a report etc.
>
> One problem today is that people trying to define screens for visual
> applications are forced (more or less) to create templates starting with
> COMPOSITIONs, which is incorrect; my impression is that such templates are
> only used for data capture and that other display forms are modelled in
> various non-standard ways, or not at all.
>
> I think annotations (based on paths) will be useful, but I not completely
> adequate to achieved what is needed.
>
> - thomas
>
> On 19/02/2018 07:49, Erik Sundvall wrote:
>
> Hi!
>
> I agree that in many use-cases it is better to have a separate template
> intended for GUI/application hints overlayed on a "normal" data content
> definition template. (Quick experimentation may be an exception.)
>
> That is why I added "layers of templates" in my previous comment - sorry
> for not explaining in detail. So a GUI-hint-annotated template based on
> another "normal" content aggregation/constraint-focused template would be
> a way to do it. I guess the effect in a resulting operational template
> (OPT) is essentially the same no matter how many layers of templates you
> choose to work with, right? So a form/GUI-renderer based on OPTs does not
> care how you layer the design, but your maintenance headaches might be
> affected if not separating things at design time.
>
> I agree with Diego and Bert and suggest starting experimenting in the AM
> end (for example using annotations with GUI-hints in templates) and see how
> far that takes us, before possibly considering extending the RM (or
> whatever *M).
>
> Annotations do not require any changes to AM or RM, the mechanism is
> already defined in the specifications. Conventions regarding patterns or
> prefixes in annotation keys and/or annotation values will likely give
> enough to start with.
>
> A (not so very thought through yet) possible example of annotation use for
> application building is available in picture 40 (and supported by picture
> 36 in
> https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-
> PQDLFy/view?usp=sharing
>
> //Erik
>
> mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees :
>
>> On 18-02-18 23:09, GF wrote:
>> > Is it an idea to annotate nodes with instructions for display.
>>
>> Personally I think having special templates/archetypes for display is
>> better. Templates are create per purpose, and mixing purposes in a
>> single template does  seem good idea to me
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list

Re: Templates for application form development

[Pablo Pazos]

I have a pdf spec in Spanish, this was a university project to have
platform independent GUI definitions based on opts, while creating
technology specific GUI generators for data entry and display. I mentioned
this a while ago on the lists but catched not much attention.

Need to do a little translation work :)

On Feb 18, 2018 7:51 AM, "Thomas Beale" <thomas.be...@openehr.org> wrote:



On 17/02/2018 20:11, Pablo Pazos wrote:

> I think SET has a lot of applications, including result sets.
> Of course that should interior from LOCATABLE to be archetypable.
>
> I'm not sure on the types associated with the UI. I have a specification
> for UITenplates that includes some of that, I can share it :)
>
>
I think any existing UI/template specification / app modelling would be
useful to share - possibly on the wiki - let me know if you need a page
there.

My aim would be to get closer to an IDE application building tool for
clinical people to at least build a POC application that works, something
like Balsamiq but with real data connections built in. Marand's EhrExplorer
does some of this, and it would also be useful to extract some of the
semantics of that tool into a standard specification to support this kind
of thing.

- thomas



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

Re: Templates for application form development

[Pablo Pazos]

I think SET has a lot of applications, including result sets. Of
course that should interior from LOCATABLE to be archetypable.

I'm not sure on the types associated with the UI. I have a specification
for UITenplates that includes some of that, I can share it :)

I'm interested in moving this idea forward.

Please let me know how I can help.

On Feb 17, 2018 4:07 PM, "Thomas Beale"  wrote:

I've been recently messing around with ADL-designer, and thinking more
about how to do application building with templates. A few things are
becoming clearer to me. Firstly, templates based on COMPOSITION (or PARTY,
PERSON etc, for demographics) are potentially good for data capture, but
don't in general make sense for data retrieval.

For a retrieval data set, e.g. a screen containing a combination of
demographics, EHR clinical, other info, we need another kind of container.
Let's call this DATA_SET for the moment, and assume it is defined as
follows:

class DATA_SET inherit LOCATABLE
content: LOCATABLE [*]
end

Then an archetype of this could be built for a screen, and it could insert
SECTIONS purely for display purposes. Maybe it could include style
information. So let's imagine that instead of just SECTIONs we could use
something a bit smarter, like DATA_GROUP. We could then create a template
like the following (each included archetype is actually an overlay based on
an underlying archetype):

DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
   name matches {[at20]} -- "Patient details"
   style matches {1} -- area; from an enumeration of
tabs|menu|area|etc
   items matches {
use_archetype PERSON[id3, openEHR-EHR-PERSON.ovl_
patient_details_1.v1]
   }
}
DATA_GROUP[id4] matches {
   name matches {[at21]} -- "Clinical"
   style matches {1} -- area; from an enumeration of
tabs|menu|area|etc
   items matches {
DATA_GROUP[id6] matches {
   name matches {[at22]} -- "First trimester"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id7,
openEHR-EHR-OBERVATION.ovl_first_trimester_summary_1.v1]
   }
}
DATA_GROUP[id8] matches {
   name matches {[at23]} -- "Second trimester"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id9,
openEHR-EHR-OBERVATION.ovl_second_trimester_summary_1.v1]
   }
}
DATA_GROUP[id10] matches {
   name matches {[at24]} -- "Third trimester, first part"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id11,
openEHR-EHR-OBERVATION.ovl_third_trimester_summary_1.v1] -- overlay 1
   }
}
DATA_GROUP[id12] matches {
   name matches {[at25]} -- "Third trimester, last month"
   style matches {0} -- tabs
   items matches {
use_archetype OBSERVATION [id13,
openEHR-EHR-OBERVATION.ovl_first_trimester_summary_2.v1] -- overlay 2
   }
}
}
}
}
}

Notice that now we have demographic data (magenta) and EHR data (blue)
easily mixed in; we have a rough screen layout defined, something like two
HBOX areas, with the second one having tabs inside for the various
pregnancy trimesters.

In this construction, the only real data are the included archetypes; the
outer DATA_SET and DATA_GROUPs are just defined structures that are created
on the fly by a screen renderer. Different types of DATA_GROUP could be
used to provide the UI hints we often talk about - use tabs, use a box with
a name, and so on - people familiar with the typical UI elements like HBOX,
VBOX, TREE, MENU, MENU_ITEM, DATE_FIELD, TEXT_FIELD (the names differ
across UI toolkits) will see that this approach could be used to more or
less fully define whole screens. A similar thing could be done to define
messages or documents.

Paths through such a structure would effectively be paths to parts of a
form (or a message), and could be referenced in other sections of the
template to control visualisation.

We could embed the generating queries as well for example:

DATA_SET[id1] matches {
content matches {
DATA_GROUP[id2] matches {
   name matches {[at20]} -- first trimester
   query matches {
*   "SELECT obs*
*FROM *
*EHR[$ehr_id] CONTAINS *
*summary**
COMPOSITION[openEHR-EHR-COMPOSITION.pregnancy_summary.v1]*
*WHERE*
*summary/context/start_dat**e **> **$current_date - P1Y*
*"*
   }
   style 

Re: Optmizing AQL

[Pablo Pazos]

Here you can find info about the firs proof of concept of openEHR+SNOMED
for querying, it worked better than expected and the integration was easier
than expected :)

https://cabolabs.com/blog/article/openehr__snomed_ct_a_perfect_combination_for_data_querying-5a440acd0f763.html

On Sat, Feb 17, 2018 at 12:57 PM, Bert Verhees <bert.verh...@rosa.nl> wrote:

> On 17-02-18 16:22, Pablo Pazos wrote:
>
>> Just thinking out loud! But I'm working towards this with Diego :)
>>
>
> Ah, I didn't know that. I must read the mailing-lists more often.
>
> Good luck with that. I am very interested to hear about proceedings and
> plans
>
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

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

[Pablo Pazos]

IMO what gives context is the OPT that constrains the underlying reference
model, queries are based on archetypes and paths defined in OPTs and SNOMED
expressions are just a way of creating semantically complex criteria for
querying, nothing more.

That is why SNOMED alone can't be used for querying.

On Sat, Feb 17, 2018 at 7:21 AM, GF <gf...@luna.nl> wrote:

> Hi,
>
> In order to reach full interoperability and interpretability we need a
> clearcut separation between constituting models that are part of the
> Interoperability standards stack.
> It is the function of a Terminology to create a system of concepts that
> coherently defines concepts in a domain.
> And that is and must be the only function of SNOMED.
>
> When it comes to queries we need to take into account data values in a
> context, the epistemology.
> SNOMED will NEVER be able to model, contain the full temporal and spacial
> epistemology.
> That context/epistemology is defined by meta-data in COMPOSITION that as
> committed to databases and documents.
> In addition the world of databases is the domain of what is called the
> Closed World Assumption and Terminologies like SNOMED are part of the Open
> Worlds Assumption domain.
> Mixing these two creates severe problems.
>
> So I oppose the thought to crate search engines in the SNOMED Terminology
> domain.
> CIMI has adopted this fines, sharp divide between the worlds of Archetypes
> and Terminology.
>
>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 17 Feb 2018, at 08:57, A Verhees <bert.verh...@rosa.nl> wrote:
>
> Hi, sorry to interfere, if II understand well,
>
> I think a possible problem could be that respiratory infection caused by a
> virus can return some derived codes to be returned although in this case it
> are not so many.
>
> However to use this mechanism generally, it can happen that really many
> derived codes will be returned from the SNOMED engine, and in that case the
> AQL query would need to be executed many times. Once for each possible
> derived code.
>
> One could also consider to hand over the result set from AQL to the SNOMED
> engine to see if it is derived, which could cause less executions.
>
> But in both cases it is datamining which is always difficult to estimate
> what the best strategy in a specific case is.
>
> A good idea maybe to design an intelligent query-strategy-decision engine
> which offers advice to see what works best. This engine could execute
> limited queries, for example, with a count operator so that it does not
> need to go all the way when a limit is reached.
>
> It is true what you write that datamining queries seldom are expected to
> return in real time, but I have seen situations in marketing were they ran
> for hours and queried almost one million dossiers, we even created in
> between databases.
>
> That decision engine could also be an external service.
>
> It is good to hear that you think about separated services anyway. That
> works in the advantage of a microservices architecture.
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://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

Re: Optmizing AQL

[Pablo Pazos]

That is exactly the idea of "features" that I mentioned on the other post.

But besides defining syntax (AQL and how to express features in AQL-like
form), I mean the declarative format, what is more valuable is to define
each feature functionality. So features can be implemented in AQL and
non-AQL environments (some of us have path-based queries, not AQL syntax
processing).

A generic feature can be expressed as a definition (semantics) and a result
schema (I think most will be lists of some kind of codes or ids). The
evaluation of the definition to get a result instance that matches with the
result schema is a service client, and the service is where features are
really interpreted.

If services are well defined (API to resolve SNOMED expressions, API to
resolve archetype hierarchies, etc.) it would be easier to create clients
for many technologies and standardize querying features between different
implementations, and each system can publish it's conformance statement
with the supported features.

This generates a kind of plug-n-play architecture for queries.

And on a sci-fi future, making query services discoverable based on the
supported features and kinds of information contained in the repos that can
be queried (publishing supported OPTs).

Just thinking out loud! But I'm working towards this with Diego :)


Best,
Pablo.


On Sat, Feb 17, 2018 at 9:11 AM, Diego Boscá <yamp...@gmail.com> wrote:

> Maybe it is possible to generalize it in a way that it could be external
> calls that return a value or list of values. Maybe this is enough for
> SNOMED, CDSS, but also for queries to linked data such as drug-drug
> interaction and other services availabe in bioportal, etc.
>
> 2018-02-17 9:23 GMT+01:00 A Verhees <bert.verh...@rosa.nl>:
>
>> The discussion Pablo has makes me think it could be good to have in an
>> AQL-engine an entry to have external query languages executed like SNOMED
>> expressions which can treat result data as hierarchies of data and so add
>> an extra functionality layer
>>
>> Bert
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

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

[Pablo Pazos]

Hi Pieter,

On Fri, Feb 16, 2018 at 12:27 PM, Pieter Bos <pieter@nedap.com> wrote:

> Sounds like a good proposal Pablo.
>
>
The idea came from a PoC I did last year integrating SNOMED expressions
into openEHR queries.

IMO complex queries will need external very specialized micro services to
be evaluated, and ADL syntax is not enough to represent some complex
queries.

For instance, "give me all patients that had a diagnosis of respiratory
infection caused by virus, from any composition whose archetype is
specialized from X".


1. "diagnosis" = archID (Problem/Diagnosis) + path_to_coded_diagnosis
2. "respiratory infection caused by virus" = SNOMED Expression (<<
275498002 |infección del tracto respiratorio (trastorno)| : 246075003
|agente causal| = 49872002 |virus|)
3. "composition defined by a specialization of archetype X" = list of arch
IDs in a specialization hierarchy


1. Is part of openEHR and the internal data repo model
2. Should be evaluated against a service that will return codes in a plain
list
3. Should be evaluated against a service that will return archetype ids in
a plain list

With 2 and 3 resolved, it is easy to transform everything into SQL or
whatever, execute the query, get results and transform results in some
representation (JSON, XML, CSV, etc).

We could still add complexity to the query, and will need more external
microservices to resolve instead of implementing everything internally
generating unmaintainable/unescalable/less interoperable systems.

Another idea is to think of query "features", so we can define profiles,
for instance my queries support SNOMED expressions, your queries support
querying by archetype hierarchies, etc. If we standardize the features it
will be easy to have compliance statements for each system, marking which
features are implemented on an openEHR CDR. And the idea of having external
micro services that can help implementing those features would help to have
full featured query interfaces on many different systems, and even reach
query interoperability (we are far from that right now).



> For ADL 2 a single archetype api can be used for both archetypes and
> templates. However, it makes sense to allow the get api of archetypes to
> specify the form you want the result in: differential, flattened, or
> operational template (opt2).
>

IMO most endpoints on the API should be agnostic of the ADL version and
work with template ids, archetype ids and paths. But of course, if we have
template management endpoints, that will be ADL/OPT version dependant,
since formats and models differ.


>
> Our EHR still will integrate the archetype part and query part, as well as
> the option to choose a used archetype for a slot at runtime. Could all be
> built with separate services and apis, but once you have everything
> integrated it makes for a very easy to use API for both EHR and
> datawarehouse usage. without needing sophisticated client libraries.
> However, you need much more complex server side tools in the EHR of course.
>

Of course, that is a design/implementation decision. I agree having all the
"features" implemented in one place adds a lot of complexity to the system,
while might improve performance.

A little thought about performance, I think most queries don't need to be
executed in real time, and a lot of background work and caching can be done
to make things work fast, so I don't see an issue on having complex queries
and use multiple external micro services to be able to evaluate the whole
query.


Best,
Pablo.


>
> Regards,
>
> Pieter
>
> Op 16 feb. 2018 om 15:48 heeft Pablo Pazos <pablo.,@cabolabs.com> het
> volgende geschreven:Ivo
>
> Hi Pieter,s
>
> Besides the API, I think for ADL2 archetypes and templates/OPTs have the
> same model, and archetype IDs / template IDs will follow the same
> structure.So for ADL2 using archetypes or templates would be the same in
> the API.
>
> Which endpoints do you find problematic in terms of using ADL2?
>
>
> About querying, analyzing your use case, I think there are two ways of
> knowing the full specialization hierarchy, one is to query an archetype
> repo/CKM while evaluating a query and do not have that info in the data
> repo. Like "give me all archetype IDs that specialize arch ID X", this will
> be [A, B, C], then use that list on the query in your data repo like
> "archetype_id IN [A, B, C]".
>
> The other option is to have the archetype repo/CKM integrated with the
> clinical data repo (which I don't like architecturally speaking), so the
> "give me all the archetype IDs that specialize arch ID X" is resolved
> internally.
>
> Considering there is a component that has knowledge about the
> specialization, and that can be used internally (behin

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

[Pablo Pazos]

Hi Pieter,

Besides the API, I think for ADL2 archetypes and templates/OPTs have the
same model, and archetype IDs / template IDs will follow the same
structure.So for ADL2 using archetypes or templates would be the same in
the API.

Which endpoints do you find problematic in terms of using ADL2?


About querying, analyzing your use case, I think there are two ways of
knowing the full specialization hierarchy, one is to query an archetype
repo/CKM while evaluating a query and do not have that info in the data
repo. Like "give me all archetype IDs that specialize arch ID X", this will
be [A, B, C], then use that list on the query in your data repo like
"archetype_id IN [A, B, C]".

The other option is to have the archetype repo/CKM integrated with the
clinical data repo (which I don't like architecturally speaking), so the
"give me all the archetype IDs that specialize arch ID X" is resolved
internally.

Considering there is a component that has knowledge about the
specialization, and that can be used internally (behind the API) I don't
see the need of adding explicit support in the API for archetypes.

What I think is better is to define an archetype repo/CKM API to manage
archetypes and to resolve specialization queries among other queries like
"this path exists for this archetype ID?", etc. If this is possible, we can
have interoperability between archetype repos and your queries can use my
repo to get specialization info, and vice-versa.


Best,
Pablo.



On Thu, Feb 15, 2018 at 1:09 PM, Pieter Bos <pieter@nedap.com> wrote:

> I noticed the recent version of the REST api  only works with templates,
> and not archetypes.
>
> As our EHR is ADL 2 only, this has some interesting consequences.
>
> Of course, you can upload just the operational templates and probably
> create a fully functional EHR, but if you work with ADL 2, you would always
> need an external tool to create the OPT2 from the ADL repository that you
> want to use, instead of an EHR that generates the OPT2s from the source
> archetypes itself. Of course, you could just use the ADL workbench or the
> Archie adlchecker command-line utility to do it for you, but I’m not sure
> if it’s a nice thing to do.
>
> Also if you only use OPT2, you might want to do queries such as ‘retrieve
> all information that is stored in an EHR that has been derived from
> archetype with id X, including archetypes specializing from X’ (not just
> operational template X). An example: retrieve all reports, or all care
> plans, regardless of the used template. To do that, you probably need a
> specialization section in the OPT2, which according to the specs should
> have been removed, and you also need to create operational templates for
> archetypes that you never use to directly create compositions from. Or the
> tool querying the EHR must be fully aware of the full archetype
> specialization tree and use that to create a query with all specializing
> archetypes included in the query.
>
> So, is it intended that the REST API only works with operational
> templates, and never archetypes?
>
> Regards,
>
> Pieter Bos
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Thomas Beale <thomas.be...@openehr.org>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Friday, 26 January 2018 at 14:23
> To: Openehr-Technical <openehr-technical@lists.openehr.org>
> Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments
>
>
> The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath
> Frankel, Pablo Pazos, and others on the SEC<https://www.openehr.org/
> programs/specification/editorialcommittee> and elsewhere) have made a
> 0.9.0 Release of the ITS (Implementation Technology Specifications)
> component, in order to make a pre-1.0.0 release of the REST APIs available
> for wider comment.
>
> The key point about this current release is that it is meant to be a 'core
> basics' foundation of APIs to build on, and some services like CDS, and
> more sophisticated querying (e.g. that Erik Sundvall has published in the
> past) will be added over time.
>
> NOTE THAT IN THE 0.9.0 RELEASE, BREAKING CHANGES ARE POSSIBLE.
>
> You can see the ITS Release 0.9.0 link here<https://www.openehr.org/
> programs/specification/latestreleases>, while the links you see on the
> specs 'working baseline' page<https://www.openehr.org/
> programs/specification/workingbaseline> are the result of 0.9.0 plus any
> modifications made due to feedback. The .apib files are here in Github<
> https://github.com/openEHR/specifications-ITS/tree/master/REST_API> (see
> mainly the includes directory).
>
> We are aiming to releas

Re: Announcing Archie version 0.4

[Pablo Pazos]

Thanks Pieter, I'm sure we will use it when adl 2 time arrive for us, we
are still on 1.4.

On Feb 3, 2018 9:04 AM, "Pieter Bos"  wrote:

Or a Java app with rest api and a JavaScript frontend. Let the java
application take care of parsing, validating, flattening, operational
template creation etc and send json to your front end. Archie has built-in
json serialization and deserialization support.

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan > het
volgende geschreven:

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer > wrote:
On 1 Feb 2018, at 05:13, Thomas Beale  wrote:

... But the main interest is that we will be able to build new tools such
as a Java/JS replacement for the ADL Workbench, and of course things like a
high-quality, BMM-driven runtime archetype validating kernel for EHR
systems, workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
Archie (written in Java, disappointingly) would enable JavaScript
implementations. JavaScript has nothing in common with Java (apart from the
name).

Peter


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

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

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

But you can't specify terms in DV_COUNT while DV_ORDINAL.symbol can be used
to specify the arbitrary units but not as physical property units of
measure, but as a terminology concept / term.

On Tue, Jan 30, 2018 at 1:30 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:

>
> On 30/01/2018 16:24, Pablo Pazos wrote:
>
>> Hi Silje,
>>
>> My thinking is for your use case, DV_QUANTITY doesn't apply for
>> arbitrary, since those seem not related with physical properties (mass,
>> length, area, concentration, etc.)
>>
>> As I said, "level of X" makes me think of DV_ORDINAL.
>>
>
> or even DV_COUNT.
>
> I have asked some questions of knowledgeable ontology sources; will post
> any replies I get here.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
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

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

Hi Silje,

My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary,
since those seem not related with physical properties (mass, length, area,
concentration, etc.)

As I said, "level of X" makes me think of DV_ORDINAL.

DV_PROPORTION would be used for numerator / denominator modeling, but
currently doesn't support units so it's real / real. My suggestion was to
analyze the change from that to an arbitrary type for each numerator and
denominator, so you can model DV_QUANTITY / DV_QUANTITY proportions.

Also DV_ORDINAL doesn't have a unit but has a DV_CODED_TEXT, maybe your
arbitrary units are really terms from a given terminology, so this might be
good to model that.

But as I said, for this specific use case you might need to use many data
points (ELEMENTS) of different types, inside a CLUSTER to be able to comply
with all your requirements (please check my previous message where I
outlined your requirements as I understood them).


Hope that helps.



On Tue, Jan 30, 2018 at 11:55 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi Pablo,
>
>
>
> This is our current modelling, for reference (the administration unit
> denominator isn’t modelled):
>
>
>
> I don’t see how either ordinals or proportions, the way they currently
> work, can be of any help here.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Monday, January 29, 2018 4:34 PM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* Re: Quantities of arbitrary units in openEHR
>
>
>
> Hi Silje,
>
>
>
> On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no> wrote:
>
> Hi,
>
>
>
> «Any units» isn’t the same as “arbitrary units”. As I wrote below,
> “arbitrary units” in the context of biomedicine are units which are defined
> by biological activity, such as level of allergic reaction or enzymatic
> activity.
>
>
>
> From the modeling point of view, I don't think using DV_QUANTITY for this
> is the right direction, since DV_QUANTITY.units are defined to contain a
> unit related to a physical property (mass, length volume, concentration,
> etc.). When talking about "level of X", my first idea is to go for
> DV_ORDINAL. If the ordinal part is not really needed, then downgrade to
> DV_CODED_TEXT (that is part of DV_ORDINAL).
>
>
>
> This is done to be able to compare the concentration of different
> substances which have the same effects in different mass or volume amounts
> – birch pollen extract vs grass pollen extract (measured in SQ-U;
> standardized quality units), retinol vs betacarotene (measured in RE,
> retinol equivalents), human insulin vs insulin analogues (measured in IU,
> international units).
>
>
>
> In this context, I think comparing levels will work with DV_ORDINAL.
>
>
>
>
>
> To be able to specify medication strength in a meaningful way, I need a
> numerator (amount active substance) and a denominator (amount helper
> substance). The numerator can be a mass (such as mg), a volume (such as ml)
> or an arbitrary unit (such as IU). The denominator can be a volume, a mass
> or an administration unit (such as tablet or puff).
>
>
>
> This would be normally modeled with DV_PROPORTION, but the issue is that
> we don't have units there, just real numerator and deonominator.
>
>
>
> This might lead to a requirement of having DV_PROPORTION<num_type,
> den_type>, so something like DV_PROPORTION<DV_QUANTITY, DV_QUANTITY> will
> work.
>
>
>
> Also, with DV_QUANTITY alone it is not possible to express an explicit
> numerator and denominator, just the final real value of num/den, but the
> units are flexible enough to satisfy this. But this leads to the issue you
> have again :)
>
>
>
> So if the requirement is:
>
>
>
> 1. to have explicit numerator and denominator,
>
> 2. have units for numerator and denominator,
>
> 3. have units that are not related with physical properties or that are
> not standardized,
>
> 4. be able to compare two values of this form
>
>
>
> With the current RM, I think it is not possible to model it directly as
> one datatype, so it might be a combination of datatypes and using a CLUSTER
> to put all together. Then some querying power will allow you to compare
> those structures.
>
>
>
> I can't think of a better solution with the current RM.
>
>
>
> Architecturally I think having DV_PROPORTION<DV_ORDERED, DV_ORDERED> might
> be a better solution but needs changes

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

Hi Silje,

On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi,
>
>
>
> «Any units» isn’t the same as “arbitrary units”. As I wrote below,
> “arbitrary units” in the context of biomedicine are units which are defined
> by biological activity, such as level of allergic reaction or enzymatic
> activity.
>

>From the modeling point of view, I don't think using DV_QUANTITY for this
is the right direction, since DV_QUANTITY.units are defined to contain a
unit related to a physical property (mass, length volume, concentration,
etc.). When talking about "level of X", my first idea is to go for
DV_ORDINAL. If the ordinal part is not really needed, then downgrade to
DV_CODED_TEXT (that is part of DV_ORDINAL).


> This is done to be able to compare the concentration of different
> substances which have the same effects in different mass or volume amounts
> – birch pollen extract vs grass pollen extract (measured in SQ-U;
> standardized quality units), retinol vs betacarotene (measured in RE,
> retinol equivalents), human insulin vs insulin analogues (measured in IU,
> international units).
>

In this context, I think comparing levels will work with DV_ORDINAL.


>
>
> To be able to specify medication strength in a meaningful way, I need a
> numerator (amount active substance) and a denominator (amount helper
> substance). The numerator can be a mass (such as mg), a volume (such as ml)
> or an arbitrary unit (such as IU). The denominator can be a volume, a mass
> or an administration unit (such as tablet or puff).
>

This would be normally modeled with DV_PROPORTION, but the issue is that we
don't have units there, just real numerator and deonominator.

This might lead to a requirement of having DV_PROPORTION<num_type,
den_type>, so something like DV_PROPORTION<DV_QUANTITY, DV_QUANTITY> will
work.

Also, with DV_QUANTITY alone it is not possible to express an explicit
numerator and denominator, just the final real value of num/den, but the
units are flexible enough to satisfy this. But this leads to the issue you
have again :)

So if the requirement is:

1. to have explicit numerator and denominator,
2. have units for numerator and denominator,
3. have units that are not related with physical properties or that are not
standardized,
4. be able to compare two values of this form

With the current RM, I think it is not possible to model it directly as one
datatype, so it might be a combination of datatypes and using a CLUSTER to
put all together. Then some querying power will allow you to compare those
structures.

I can't think of a better solution with the current RM.

Architecturally I think having DV_PROPORTION<DV_ORDERED, DV_ORDERED> might
be a better solution but needs changes to the RM. We already have this for
DV_INTERVAL but a proportion is not the same as an interval.

REF:
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_overview_4



> Since there can be approximately a million different variations on mass,
> volume and arbitrary units, I don’t want to specify them all in the
> archetype, but leave it up to the application, while still specifying the
> property (mass, volume or arbitrary). At the moment, I can’t do this for
> the arbitrary units element, since there’s no property in the openEHR units
> properties terminology set for arbitrary units.
>
>
>
> However, I’m starting to wonder if “ openEHR="385" />” really is a misnamed “arbitrary units” property. Anyone
> know the origin of this? IU isn’t a mass unit, so it’s misnamed in any case
> (see https://en.wikipedia.org/wiki/International_unit).
>
>
>
> Also, what would be really really neat, is a Quantity data type which
> could be any of a couple of a set of preselected properties (such as for
> instance mass, volume and arbitrary), and not just one fixed property. :o)
>

For the aforementioned, DV_QUANTITY might not be the right solution for
this problem IMHO.


>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Monday, January 29, 2018 12:37 AM
> *To:* For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> *Subject:* RE: Quantities of arbitrary units in openEHR
>
>
>
> Hi Silje,
>
>
>
> When specifying the property but not the units, any units are allowed.
> This is saying "any units" which is similar to "arbitrary units". We can
> relax the spec to allow non-ucum as units (my interpretation of "any units"
> is any in ucum and compliant with the specified property, while "arbitrary"
> might be in or not in ucum, and compliant with the property).
>

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

Maybe we can analyze the need/implications of changing the string tour of
units for a coded text in the SEC?

On Jan 26, 2018 9:11 AM, "Thomas Beale"  wrote:

> that's not a bad idea, but that requires a change to the reference model,
> since DV_QUANTITY.units is currently a String.
>
> I sometimes wonder if we need to allow for some sort of automatic
> conversions in cases like this, i.e. where the 'code' is self-defining - as
> we already accept via the notion of openEHR code-sets, e.g. country codes
> and so on - units are like this, rather than being like SNOMED or LOINC
> codes.
>
> Perhaps we define it to be legal to enable a String field can be mapped to
> a code-set, more or less in the way that Diego does here?
>
> - thomas
>
> On 26/01/2018 11:08, Diego Boscá wrote:
>
> maybe something like this
>
> ELEMENT[at0004] occurrences matches {0..1} matches {  -- One element
> value existence matches {0..1}
> matches {
> DV_QUANTITY occurrences
> matches {0..1} matches {  -- DV_QUANTITY
> units existence matches
> {1..1} matches {
> [ac0001]
> }
> }
> }
> }
>
> ...
>
>
>  constraint_binding = <
> ["UCUM"] = <
> items = <
> ["ac0001"] = <[UCUM::mass]>
> >
> >
> >
>
>
> 'mass' or whatever way of identifying the valid unit set
>
>
>
> 2018-01-26 10:40 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
>> This sounds good in theory, but I don’t think it’ll help me with my
>> modelling in the next couple of weeks? J
>>
>>
>>
>> Regards,
>>
>> *Silje*
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org] *On Behalf Of *Diego Boscá
>> *Sent:* Friday, January 26, 2018 10:18 AM
>> *To:* For openEHR technical discussions > hr.org>
>> *Subject:* Re: Quantities of arbitrary units in openEHR
>>
>>
>>
>> In my mind, this should be done not by fixing a property but by defining
>> a constraint reference pointing to the service/set of codes that can
>> provide you with all mass units
>>
>>
>>
>> 2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland <
>> silje.ljosland.ba...@nasjonalikt.no>:
>>
>> Deriving the properties from the codes makes sense when you actually
>> specify the codes, but what do you do when you want to specify “this is a
>> concentration, but I don’t care about the exact units”?
>>
>>
>>
>> “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all
>> for “new units for which we haven’t got the property defined in the
>> terminology yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
>>
>> I see that IUPAC and IFCC has decided to use the term “procedure defined
>> unit” instead of “arbitrary unit”.
>>
>>
>>
>> Also, does leaving the “property” field out mean that we can have one
>> Quantity element with the units Cel, m, kg, ml and [arb'U]?
>>
>>
>>
>> Regards,
>>
>> *Silje*
>>
>>
>>
>> *Fra:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org] *På vegne av* Diego Boscá
>> *Sendt:* fredag 26. januar 2018 09:42
>> *Til:* For openEHR technical discussions > hr.org>
>> *Emne:* Re: Quantities of arbitrary units in openEHR
>>
>>
>>
>> I think there are several potential problems with this, and IMHO we are
>> stepping too much on what should be done in a terminology service (We are
>> literally talking about a 'public available UCUM service'). You can also
>> ask the terminology service what kind of unit code you have. Your
>> implementation could answer "arbitrary" for these new units.
>>
>>
>>
>> In my opinion, saying "here comes a mass unit code" is not much different
>> from "here comes a diagnosis code", and we say these in a completely
>> different way (a better way, if you ask me).
>>
>>
>>
>> Also, I'm not a big fan of "arbitrary" property, as feels like a "other"
>> kind of terminology code that is potentially dangerous as knowledge or
>> terminology advances, thus coexisting 'arbitrary' and 'new shiny type of
>> measurements' all mixed up. That's why I also expect these properties to be
>> as derived from the codes and not the other way around.
>>
>>
>>
>> 2018-01-26 9:21 GMT+01:00 Sebastian Garde > ics.com>:
>>
>> While I agree with the SPEC-95 rationale (once you have a unit, you
>> should be able to know what its property is), it is still convenient to
>> have the property for constraining.
>> Otherwise you don't have a way to say in an archetype: I don't care about
>> the exact unit here, but please let it be a "Mass".
>>
>> -Ursprüngliche Nachricht-
>> Von: 

RE: Quantities of arbitrary units in openEHR

[Pablo Pazos]

Hi Silje,

When specifying the property but not the units, any units are allowed. This
is saying "any units" which is similar to "arbitrary units". We can relax
the spec to allow non-ucum as units (my interpretation of "any units" is
any in ucum and compliant with the specified property, while "arbitrary"
might be in or not in ucum, and compliant with the property).

What do you think?

On Jan 26, 2018 6:01 AM, "Bakke, Silje Ljosland" <
silje.ljosland.ba...@nasjonalikt.no> wrote:

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

Re: Process to follow for coding using Terminology server

[Pablo Pazos]

DV_CODED_TEXT inherits from DV_TEXT, so in the object oriented model any
text can be coded.

On Dec 20, 2017 2:42 AM, "Dileep V S"  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: information about allowable data in a openEHR format

[Pablo Pazos]

Hi David,

The openEHR model can store codes data from any terminology and use any
kind of structure, that is defined in archetypes and templates.

Why do you need json to understand openEHR data storage? Are you using a
json database?

Json is not part of the specifications, but there is a standard XML schema
available. They XML can be transformed to json with two lines of code.

I have tools that generate test documents with dummy data on openEHR XML.
All open source.

Regards,
Pablo.


On Nov 22, 2017 11:45 AM, "Monaghan, David S" 
wrote:

Hey all,

Apologies for asking what is probably a simple question but I’m just
starting out in this space now.

My question is:

If I have a patient record with ICD-9 and ICD-10 codes, Pharmacy codes,
procedure codes, patient data such as age, sex, height, weight etc. and
also free form clinical notes. Can I store all this kinda of data in a
openEHR format? And if so could you provide me with a sample json of what
that kind of patient record would look like?



Or point me in the right direction?



Thanks so much



Kind regards

Dave



*Dr David Monaghan  **| Optum*

Lead Machine Learning Researcher – Product Engineering and Data Solutions

BLOCK C, SPENCER DOCK, Dublin, Ireland

T +353 749 200 436

E david_monag...@optum.com

*www.optum.com *



*Our United Culture  *The way forward

Integrity  |  Compassion  |  Relationships  |  Innovation  |  Performance



Optum Services (Ireland) Limited, a private company limited by shares,
registered in Ireland with company number 579794 and with its registered
office at 70 Sir John Rogerson's Quay, Dublin 2.










This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

___
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