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

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: 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: [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: 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]

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

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

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

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]

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

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

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

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

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]

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

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

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

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

{Disarmed} OpenEHR evaluation

[Pablo Pazos Gutierrez]

It would be great to have access to these archetypes, and I can make the 
translations to spanish ;)

thank you,
Pablo Pazos Gutierrez
  - Original Message - 
  From: Thomas Beale 
  To: For openEHR technical discussions 
  Sent: Monday, December 22, 2008 12:38 PM
  Subject: Re: {Disarmed} OpenEHR evaluation



  The most useful demographic archetypes available will be Sergio Freire's from 
Brazil - they are based on ISO 0, and he has about 20 of them. He is just 
reworking some of the details, and said to me while I was there recently that 
he will translate them into English (using teh ISO 0 names) and then make 
them available. I would expect this set to become the base set for openEHR. 
They are easy to build plug-in specialised archetypes for that contain e.g. 
braziliann address, japanese address, etc - the bits that vary.

  - thomas beale

  Pab wrote: 
Hi,

I've started working on an EHR project at national level in my country. The 
people here knows only about HL7 and IHE, but OpenEHR is not so popular. I've 
been follow OpenEHR since 2006, when with Rodrigo Filgueira we made a prototype 
of an ICU system with the OpenEHR Information Model.

This is the first email of a list of emails I have to send to you to make a 
correct evaluation of OpenEHR and to have solid information to propose it to my 
coleagues on the project (I don't make the decisions so I need to convince my 
coleagues). I think OpenEHR has very good ideas and concepts and it's 
reasonably stable and mature, but some issues are not so clear or not so mature 
(IMHO), now I can think of two things: the template specification and template 
tools and archetype/template versioning. Later I'll ask you about these 
subjects, know I need some words about another subject.

At this time, we are making a prototype of a Master Patient Index system, 
at this time the only specifications and standards that are over the table are 
IHE (the PIX profile) and HL7 for messaging. I need to know what is the 
experience on this subject using OpenEHR (I know that Ocean Informatics has its 
own MPI system, is it based on OpenEHR IM and AOM?), if someone has build an 
MPI please leave some lines on the subject: what problems do you have? what 
archetypes do you use? etc etc.

I want to propose something like the IHE transactions but implemented with 
OpenEHR messages based on demographic archetypes (something like the Patient 
Administration domain of HL7, that defines messages with demographic data). I 
see that here MailScanner has detected a possible fraud attempt from 
www.openehr.org claiming to be 
http://wwwopenehr.org/clinicalmodels/archetypes.html are some demographic 
archetypes but the links are broken. Are this archetypes stable? are them 
complete? (they have all the demographic data that is needed: ids, names, 
contact mediums, address or some kind of geo-referenced location, etc, etc).


Please drop me a line on these subjects,
thanks a lot!

Cheers,
Pablo.

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  


  -- 
   Thomas Beale
Chief Technology Officer, Ocean Informatics

Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London 





--


  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081222/a204d800/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanC_small.png
Type: image/png
Size: 4972 bytes
Desc: not available
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081222/a204d800/attachment.png

Java Ref Impl SVN password request

[Pablo Pazos Gutierrez]

Hi Rong,

- Original Message - 
From: Rong Chen rong.ac...@gmail.com
To: For openEHR technical discussions openehr-technical at openehr.org
Sent: Tuesday, April 28, 2009 1:55 PM
Subject: Re: Java Ref Impl SVN password request


 Hi Pablo,

 The Svn server is not working properly now. Normally you shouldn't
 need password to access the repository in read mode.


I'll wait for the server to work correctly.

 By the way, can you please post your Java implementation specific
 questions on the openEHR Java mailing list instead of this one?


Yeah, I'll send it right away.

Thank you!

 Cheers,
 Rong

 2009/4/28 Pablo Pazos Gutierrez pazospablo at hotmail.com:
 Hi,

 Yesterday I have downloaded the java reference implementation from the 
 svn
 site, but today I'm getting a password request:


 Authorization Required

 This server could not verify that you are authorized to access the 
 document
 requested. Either you supplied the wrong credentials (e.g., bad 
 password),
 or your browser doesn't understand how to supply the credentials 
 required.


 The SVN has no more free access?

 Thanks.

 --
 Atte.
 A/C Pablo Pazos Gutierrez
 www.SimpleWebPortal.net
 http://YuppFramework.blogspot.com
 http://groups.google.com/group/yuppframeworkphp
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 

Loading archetypes referenced by ArchetypeSlots

[Pablo Pazos Gutierrez]

Hi,

I'm doing some archetype modeling and loading tests with Java Ref Impl.
I have two ACTION archetypes and a COMPOSITION archetype that
references the two ACTION archetypes:

content cardinality matches {0..*; unordered} matches {
   allow_archetype ACTION occurrences matches {0..1} matches {
  include
 archetype_id/value matches {/via_venosa_central\.v1/}
 archetype_id/value matches {/via_venosa_periferica\.v1/}
   }
 }

 If a load the COMPOSITION archetype with the ADL parser, how can I load all
 the archetypes that matches the allow_archetype assertion?
 I need to have a full archetype structure loaded but I don't know if the 
ADL
 parser can do this automatically.

 Thanks a lot!

 Cheers,
Pablo Pazos Gutierez.
 

{Disarmed} OpenEHR evaluation

[Pablo Pazos Gutierrez]

Hi Sam, 

Yes, Sergio send me the draft archetypes, but now I'm going on vacation, I'll 
play with them when I'm back.

Thank you!

cheers,
Pablo.
  - Original Message - 
  From: Sam Heard 
  To: 'For openEHR technical discussions' 
  Sent: Monday, January 05, 2009 10:36 PM
  Subject: RE: {Disarmed} OpenEHR evaluation


  Hi Pablo

   

  Did you get them? If you send an email to Heather Leslie, I know she has the 
set.

   

  Cheers, Sam

   

  From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Pablo Pazos 
Gutierrez
  Sent: Tuesday, 23 December 2008 12:21 AM
  To: For openEHR technical discussions
  Subject: Re: {Disarmed} OpenEHR evaluation

   

  It would be great to have access to these archetypes, and I can make the 
translations to spanish ;)

   

  thank you,

  Pablo Pazos Gutierrez

- Original Message - 

From: Thomas Beale 

To: For openEHR technical discussions 

Sent: Monday, December 22, 2008 12:38 PM

Subject: Re: {Disarmed} OpenEHR evaluation

 


The most useful demographic archetypes available will be Sergio Freire's 
from Brazil - they are based on ISO 0, and he has about 20 of them. He is 
just reworking some of the details, and said to me while I was there recently 
that he will translate them into English (using teh ISO 0 names) and then 
make them available. I would expect this set to become the base set for 
openEHR. They are easy to build plug-in specialised archetypes for that contain 
e.g. braziliann address, japanese address, etc - the bits that vary.

- thomas beale

Pab wrote: 

Hi,

 

I've started working on an EHR project at national level in my country. The 
people here knows only about HL7 and IHE, but OpenEHR is not so popular. I've 
been follow OpenEHR since 2006, when with Rodrigo Filgueira we made a prototype 
of an ICU system with the OpenEHR Information Model.

 

This is the first email of a list of emails I have to send to you to make a 
correct evaluation of OpenEHR and to have solid information to propose it to my 
coleagues on the project (I don't make the decisions so I need to convince my 
coleagues). I think OpenEHR has very good ideas and concepts and it's 
reasonably stable and mature, but some issues are not so clear or not so mature 
(IMHO), now I can think of two things: the template specification and template 
tools and archetype/template versioning. Later I'll ask you about these 
subjects, know I need some words about another subject.

 

At this time, we are making a prototype of a Master Patient Index system, 
at this time the only specifications and standards that are over the table are 
IHE (the PIX profile) and HL7 for messaging. I need to know what is the 
experience on this subject using OpenEHR (I know that Ocean Informatics has its 
own MPI system, is it based on OpenEHR IM and AOM?), if someone has build an 
MPI please leave some lines on the subject: what problems do you have? what 
archetypes do you use? etc etc.

 

I want to propose something like the IHE transactions but implemented with 
OpenEHR messages based on demographic archetypes (something like the Patient 
Administration domain of HL7, that defines messages with demographic data). I 
see that here MailScanner has detected a possible fraud attempt from 
www.openehr.org claiming to be 
http://wwwopenehr.org/clinicalmodels/archetypes.html are some demographic 
archetypes but the links are broken. Are this archetypes stable? are them 
complete? (they have all the demographic data that is needed: ids, names, 
contact mediums, address or some kind of geo-referenced location, etc, etc).

 

 

Please drop me a line on these subjects,

thanks a lot!

 

Cheers,
Pablo.




 ___openEHR-technical mailing 
listopenEHR-technical at 
openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical   

-- 


 Thomas Beale
  Chief Technology Officer, Ocean Informatics

  Chair Architectural Review Board, openEHR Foundation
  Honorary Research Fellow, University College London
 

 




___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



--


  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private

Why is the editor not opening ADL files?

[Pablo Pazos Gutierrez]

Hi,

I agree, specially if we think of OpenEHR as a PATIENT CENTRIC specification of 
an EHR.

Cheers,
Pablo.
  - Original Message - 
  From: Williamtfgoossen at cs.com 
  To: openehr-technical at openehr.org 
  Sent: Monday, March 16, 2009 12:26 PM
  Subject: Re: Why is the editor not opening ADL files?


  Sam,

  this below - demographics not relevant in the EHR is like the most confusing 
comment ever I heard from you. 

  About whom are we going to create a EHR then? If it is not possible to have 
the individuals name, id, birthdate and sex in the EHR (generally named patient 
demographics), it becomes useless in my vue. 

  Or do I miss a point here? 

  William

  In a message dated 16-3-2009 8:39:20 W. Europe Standard Time, sam.heard at 
oceaninformatics.com writes: 

In the meantime, I just want to be clear that the demographic model 
archetypes cannot be used in the EHR ? they are not relevant there.

  

Cheers, Sam

  




  Sincerely yours,

  dr. William TF Goossen
  director 
  Results 4 Care b.v.
  De Stinse 15
  3823 VM Amersfoort
  the Netherlands
  emails: 
  Results4Care at cs.com
  williamtfgoossen at cs.com 
  info at results4care.nl 

  phone + 31654614458
  fax +3133 2570169
  www.results4care.nl
  Dutch Chamber of Commerce number: 32133713 


--


  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090316/fa3f7c57/attachment.html

Problems with java archetype parser

[Pablo Pazos Gutierrez]

Hi, thanks, it seems this page is out of date and doesn't have the jar you 
mention :( 

 http://www.openehr.org/svn/ref_impl_java/TRUNK/docs/download.htm

Cheers,
Pablo.
  - Original Message - 
  From: Tony Fran?a 
  To: For openEHR technical discussions 
  Sent: Wednesday, April 29, 2009 9:39 AM
  Subject: Re: Problems with java archetype parser


  Seems you have one jar missing in your classpath: 
measure-serv-0.1-SNAPSHOT.jar


  If you cannot find it you can build it from the sources (as soon as it stops 
asking for a password in read mode):
  http://www.openehr.org/svn/ref_impl_java/TRUNK



  And then do a mvn install on the measure-serv module.


  Cheers
  Tony L?mpada


  On Mon, Apr 27, 2009 at 11:59 PM, Pablo Pazos Gutierrez pazospablo at 
hotmail.com wrote:

Hi everyone,

I've downloaded the java parser jar from openehr site 
(http://www.openehr.org/svn/ref_impl_java/TRUNK/docs/download.htm) and made a 
simple application to try it, but when I want to parse an archetype I get: 
Exception in thread main java.lang.NoClassDefFoundError: 
org/openehr/rm/support/measurement/SimpleMeasurementService

at se.acode.openehr.parser.ADLParser.init(

ADLParser.java:49) 
at se.acode.openehr.parser.ADLParser.init(

ADLParser.java:56) 
at Main.main(

Main.java:55)

Attached is my code, I use all the jars I've downloaded from the openehr 
site, and the XStream lib to see the content of the parsed instance of the 
archetype (this code is never executed because the error).


Any ideas?


Thanks a lot!
Cheers,
Pablo.

--
Atte.
A/C Pablo Pazos Gutierrez
www.SimpleWebPortal.net
http://YuppFramework.blogspot.com
http://groups.google.com/group/yuppframeworkphp

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical






--


  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090501/52d32dee/attachment.html

How to start

[Ing. Pablo Pazos]

Create tables, saves and retrieves the.same way you do with any other system. 
This is not black magic, is just data :)

But you need to create the bindings.

In 2012 I created bindings and give them to developers of a mobile app for a 
company in Netherlands (Bert works in that project). The developers only had to 
understand the bindings, not the whole openEHR paradigm.

Sent from my LG Mobile

Lexis Nexis lexisnexis5490 at gmail.com wrote:

Should I create a new database table to store these fields:

Last Name:
First Name:
Date of Birth Date:
Gender:
Phone:
Email:
Emergency Contact Person:

I get confused about how to save and retrieve data and where data are saved?

Thanks,

David


On Tue, Aug 6, 2013 at 8:59 PM, pablo pazos pazospablo at hotmail.com wrote:

 Hi Lexis, you can grab the demographic Person archetype here:
 http://www.openehr.org/ckm/

 Then use the ADL Workbench to extract paths, and map those paths with your
 fields. We call that mapping a binding between archetype nodes and
 software elements/artifacts.

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/homehttp://twitter.com/ppazos

 --
 Date: Tue, 6 Aug 2013 20:50:29 -0400
 Subject: How to start
 From: lexisnexis5490 at gmail.com
 To: openehr-technical at lists.openehr.org


 I am a Java developer. I am assigned to develop EHR based on OpenEHR. I
 read some specifications and they seem very complex to me. For instance, I
 want to create a web page like:

 Last Name:
 First Name:
 Date of Birth Date:
 Gender:
 Phone:
 Email:
 Emergency Contact Person:

 How do I map this object to Archetype?


 David

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

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

How to start

[Ing. Pablo Pazos]

Look for oenEHR xml schemas.

Sent from my LG Mobile

Lexis Nexis lexisnexis5490 at gmail.com wrote:

Is RM-objects only used for data interchanges between different EHR system?

Does a way to serialize your RM-objects to that database means that I
have to create my own tables to store medical data?

Where can I get a whole picture about how to retrieve data and save data?
As I understand OpenEHR is used to model medical data. Am I right?

Thanks,

David


On Wed, Aug 7, 2013 at 3:33 AM, Bert Verhees bert.verhees at rosa.nl wrote:

  On 08/07/2013 03:21 AM, Lexis Nexis wrote:

   Is there a tutorial book I can purchase or some examples? Step-by-step
 tutorial is best.

  I found ArchetypeSaveLoadExample.java, but I missed a lot of imported
 libraries. How do I find the source code for this example?


 David, you have to build your own kernel. There is no fully functional
 kernel in Java available.
 There are some wheels you have to reinvent.

 Be careful with advices in the past, they are always/often based on
 limited experiences, or have some company-politically background.

 Think for your own, that is the most important advice I can give you.

 You must think about:
 - Database-layer, you have to consider the type of database, and then a
 way to serialize your RM-objects to that database.
 - You also must consider your infrastructure, how to handle archetypes,
 how to validate data against the archetypes, how to communicate with GUI's,
 etc.
 - How to have a query-engine which is able to query ADL-paths. (AQL)

 All this is not available in open source, even good ideas how to do so are
 not available.

 There is quite a lot you have to do before you have a working
 OpenEHR-kernel.

 So, thinking in terms of displaying data on a website, is something you do
 not need to do coming months.
 In fact, that is more or less, the last step.

 A first step:
 A good study point to start with is read the Reference Model, and look at
 the archetypes at:
 http://www.openehr.org/ckm/
 Try to match them, and when you have understood that, than it will become
 time to think about how to design your kernel.
 There are many good ways to do so.

 This list is a good place for advice, especially when you have more
 specific questions

 good luck
 Bert Verhees




  Thanks,

  David


 On Tue, Aug 6, 2013 at 8:59 PM, pablo pazos pazospablo at hotmail.comwrote:

  Hi Lexis, you can grab the demographic Person archetype here:
 http://www.openehr.org/ckm/

 Then use the ADL Workbench to extract paths, and map those paths with
 your fields. We call that mapping a binding between archetype nodes and
 software elements/artifacts.

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home

  --
 Date: Tue, 6 Aug 2013 20:50:29 -0400
 Subject: How to start
 From: lexisnexis5490 at gmail.com
 To: openehr-technical at lists.openehr.org


  I am a Java developer. I am assigned to develop EHR based on
 OpenEHR. I read some specifications and they seem very complex to me. For
 instance, I want to create a web page like:

  Last Name:
  First Name:
  Date of Birth Date:
  Gender:
  Phone:
  Email:
  Emergency Contact Person:

  How do I map this object to Archetype?


  David

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

 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




 ___
 openEHR-technical mailing listopenEHR-technical at 
 lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

How to start

[Ing. Pablo Pazos]

Please specify what kind of examples do you need. For the software part I 
believe you can do it. The binding is just a mapping of the elements I 
mentioned on my previous messages, in a simple text file.

Sent from my LG Mobile

Lexis Nexis lexisnexis5490 at gmail.com wrote:

May I have some examples? I am starting to understand OpenEHR a little bit.

Thanks,

David


On Wed, Aug 7, 2013 at 10:41 PM, Ing. Pablo Pazos pazospablo at 
hotmail.comwrote:

 Create tables, saves and retrieves the.same way you do with any other
 system. This is not black magic, is just data :)

 But you need to create the bindings.

 In 2012 I created bindings and give them to developers of a mobile app for
 a company in Netherlands (Bert works in that project). The developers only
 had to understand the bindings, not the whole openEHR paradigm.

 Sent from my LG Mobile

 Lexis Nexis lexisnexis5490 at gmail.com wrote:

 Should I create a new database table to store these fields:
 
 Last Name:
 First Name:
 Date of Birth Date:
 Gender:
 Phone:
 Email:
 Emergency Contact Person:
 
 I get confused about how to save and retrieve data and where data are
 saved?
 
 Thanks,
 
 David
 
 
 On Tue, Aug 6, 2013 at 8:59 PM, pablo pazos pazospablo at hotmail.com
 wrote:
 
  Hi Lexis, you can grab the demographic Person archetype here:
  http://www.openehr.org/ckm/
 
  Then use the ADL Workbench to extract paths, and map those paths with
 your
  fields. We call that mapping a binding between archetype nodes and
  software elements/artifacts.
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos
 
  --
  Date: Tue, 6 Aug 2013 20:50:29 -0400
  Subject: How to start
  From: lexisnexis5490 at gmail.com
  To: openehr-technical at lists.openehr.org
 
 
  I am a Java developer. I am assigned to develop EHR based on OpenEHR. I
  read some specifications and they seem very complex to me. For
 instance, I
  want to create a web page like:
 
  Last Name:
  First Name:
  Date of Birth Date:
  Gender:
  Phone:
  Email:
  Emergency Contact Person:
 
  How do I map this object to Archetype?
 
 
  David
 
  ___ openEHR-technical
 mailing
  list openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
 
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

Cyclic datatypes: OpenEHR virus

[Ing. Pablo Pazos]

If the value is not constrained, the validator should return true without 
continuing checking in cascade-recursive mode. For this to work as expected, 
the data structure should be validated before than the data validation. The 
easiest way of validating the structure is serializing the instance to XML and 
using XSD.

Sent from my LG Mobile

Bert Verhees bert.verhees at rosa.nl wrote:

Thomas Beale schreef op 12-5-2014 17:25:
 I don't see the problem here; the DV_CODED_TEXT of the 
 TERM_MAPPING.purpose is always a different instance from the root 
 DV_TEXT or DV_CODED_TEXT instance. So how can a loop occur?
What I was doing was writing validation-rules for: DV_TEXT matches{*}
I am working on the finishing part of software to write validation-rules 
automated, archetypes are translated to validation-rules, and I am doing 
the last bits, so I came to this which I had saved in a TODO list.
I had a stack-overflow, and first I thought it was a bug, but after 
investigating, I found, it was as designed.

For this situation, I had to write a rule for attribute: mappings, which 
can be used, because there is no constraint.
And I wanted to validate the expression completely, so every possible 
attribute had to be handled, with occurrence as defined in the 
XML-Schema. Attribute: mappings is optional, so it is allowed.
Every attribute that is not a simple type, but a complex OpenEHR-type 
needs to be treated the same way (recursive), so in the 
mappings-attribute, there is the purpose-attribute which again can have 
a mappings-attribute, which again can have purpose-attribute, and so on.

A data-set which would look like that recursive situation would still 
match inside the archetype-definition.
Even if this would repeat ten times inside that data-set, it would still 
be matching against the archetype.

I admit that the problem is a theoretical one, and I suggested an 
automated feeding system, which could create that to make it less 
theoretical.
I have seen systems which go to every detail and every bit, thinkable, 
automated systems sometimes go very deep.

The problem is, how can validation software distinguish erroneous 
nesting from legitimate nesting.
I don't think that is possible, so the validating software has to stop 
at a certain arbitrary level of depth.
At a certain point, the validating software will mark a part of a 
data-set as erroneous: too deeply nested, even if it still fits inside 
the archetype

Then I remembered a teacher from years ago, he said: Don't write perfect 
software, write feasible software

But OK, thank you all for your reply's, I am now convinced that it is 
not a 100% solvable problem.


best regards
Bert

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