Re: export opt in other languages

[Thomas Beale]

Hi,

this list has now moved to Discourse. You should create an account there 
<https://discourse.openehr.org>. The description of the new groups is 
here 
<https://discourse.openehr.org/t/new-openehr-discourse-site-replacing-mailing-lists/97>.


Then you could repost this as a new topic in the specifications category 
<https://discourse.openehr.org/c/specifications/6>. Make sure you watch 
or track the News and Specifications categories.


- thomas beale

On 16/01/2020 14:51, Joyce Liu wrote:

Hello,
How can I export opts to have them containing another language (or 
just in that other language) using Template Designer? The archetypes 
used in those templates are already translated. I have tried adding 
additional language when exporting but nothing has changed, is there 
some other setting I am missing?


Thank you.
Joyce

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

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, US Veterans Affairs
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: access on items in a cluster

[Thomas Beale]

Hi Georg,

ITEM is an abstract type. The hierarchy pattern of ITEM / CLUSTER / 
ELEMENT 
<https://specifications.openehr.org/releases/UML/latest/#Diagrams___18_1_83e026d_1433773264427_531476_6966> 
is one of the most common in class modelling.


- thomas

On 30/10/2019 09:26, Georg Fette wrote:

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

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR ADL2 published as ISO 13606-2:2019

[Thomas Beale]

In 2008, ADL 1.4 was adopted as the basis of ISO 13606-2.

A few years ago, the renewal process started for this standard, and as 
part of that, openEHR Foundation was asked to allow the ADL2 version of 
the Archetype Formalism (specifically, the AOM2 specification 
<https://specifications.openehr.org/releases/AM/latest/AOM2.html>) to be 
used as the basis for the new version of 13606-2. The latter has now 
been published as ISO 13606-2:2019 (ISO home page 
<https://www.iso.org/standard/62305.html>).


For users of openEHR specifications at government level, it may help to 
be able to point to this ISO standard.


- thomas

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
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

Re: difference in expressability for archetype and template definitions

[Thomas Beale]

You can see an example of an ADL2 template here 
<https://specifications.openehr.org/releases/AM/latest/ADL2.html#_templates>.


The ADL Workbench and I think Archie as well (and maybe even Better 
/Marand ADL-designer?) will read and write these templates.


- thomas

On 12/10/2019 12:03, Georg Fette wrote:

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

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Fwd: Re: openehr template specification questions

[Thomas Beale]

Georg,

if you go to the ITS page 
<https://specifications.openehr.org/releases/ITS/latest/index>, you can 
see links to most concrete formats you need. The XML format for AOM2 and 
OPT2 is there as well, which is the format for ADL2 templates, since the 
latter are just a kind of archetype in ADL2. THese latter XML formats 
have not yet been used much, but the ADL workbench generates them (but 
doesn't read them). The ADL-designer and/or LinkEHR will read the XML 
formats for ADL 1.4 and .oet, but probably not (yet) ADL2-XML.


- thomas

On 16/09/2019 11:58, Georg Fette wrote:

Hello,
I am currently trying to learn the openEHR template format specification.
The first thing I did was looking at the specification page 
(https://specifications.openehr.org/), to see what template formats 
exist. On this page OPT1.4, OPT2 and AOM2 are listed as description 
laguages that somehow are related to templates. .oet is not listed on 
this page and I did not find a a formal definition of the 
xml-specification for .oet.

Is there somewhere a formal .oet specification ?
I read the pages linked to OPT1.4, OPT2 and AOM2 linked on the 
specification page.
The next thing I did was that I downloaded all templates from 
https://www.openehr.org/ckm/, https://arketyper.no/ckm/ and 
https://ckm.highmed.org/ckm/ using the bulk exports and tried to infer 
the specification from what I got from those three CKMs. Are the names 
of the tags simply the names of the archetype fields from the 
archetypes, enriched with  and  ?
The next thing I looked at were the .opt files. The CKMs can export 
those individually using the Ocean OPT components. Which format do 
those files correpont to, OPT1.4 or OPT2 ?
On the specification page 
https://specifications.openehr.org/releases/AM/latest/OPT2.html I did 
not find a specification for the XML-Format of .opts.

Is the .optx specification somewhere available ?
Is it possible with one of the available workbenches (perhaps even 
using a CKM) to transform the .opt-XML file into an .adl file ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
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

Re: Help list openEHR procurements, related documents and things to think of!

[Thomas Beale]

pretty much everything on this page 
 was a 
(successful) procurement



- thomas


On 22/08/2019 13:34, Erik Sundvall wrote:

Hi!

I have started a wikipage about "Procurement of openEHR-related systems":
https://openehr.atlassian.net/wiki/spaces/resources/pages/416514052/Procurement+of+openEHR-related+systems
(As a preparation for an upcoming, not yet started procurement)

Please help me list things there, it may help many others in similar 
situations now and in the future.


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

Improving FHIR - the admin resources

[Thomas Beale]

For people trying to work with FHIR, this post on how some of its 
Resources could be improved 
<https://wolandscat.net/2019/09/11/fixes-for-fhir-the-admin-resources/> 
may be of interest.


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Christmas cleaning of the openEHR wiki...

[Thomas Beale]

My personal view is that it is better to have slightly more spaces each 
with clear scope, even if some have not much content, rather than trying 
to push all content into a few spaces with larger amounts of content. To 
me it seems obvious what kinds of things I might find in 'ontology' and 
'education', whereas if I know there are some articles on these areas, 
but they are buried in e..g the 'specifications' space, it's going to be 
a matter of trying to search for them with various keys.


I fixed the Resources space a little bit, but it seems to me there is a 
fair bit of content like FAQs that people may well access.


these are just my views, and others may have better ideas...!

- thomas

On 07/08/2019 08:26, Bakke, Silje Ljosland via openEHR-technical wrote:


I think we may need a more thorough discussion about how to best use 
the wiki. How do we maximise information findability, how do we enable 
new people (and not-so-new people!) to find their way around? Do we 
make new empty spaces when we start something new, or do we branch 
them out when the existing spaces become crowded? How do we decide 
what goes in which space?


For now:

  * I’ve reactivated the Education space, since I saw it was used for
the Spanish openEHR Day. (Is this really education though, and not
community?)
  * The Ontologies space has a single page with a few attachments, of
which nothing has been changed since 2012. Does this really
warrant a separate space? Could this page be moved to a different
space?
  * Could the Community space be merged with Resources? If I
understand correctly, their uses are at least partly overlapping.

Kind regards, Silje



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

Re: Christmas cleaning of the openEHR wiki...

[Thomas Beale]

On 06/08/2019 13:43, Bakke, Silje Ljosland via openEHR-technical wrote:


Picking this up again half a year later…

I’ve archived the following spaces, since there seemed to be a 
consensus that they weren’t used. This is easily reversible:


  * Healthcare
  * Demonstration Space
  * Education
  * Ontologies
  * Website

Thomas, have you had a chance to look at and/or move the stuff in the 
following spaces?


although the CIMI and Terminology spaces are not added to in recent 
times, they are both regularly viewed for content, including by outside 
agencies (including US VA and HL7).


I'd rather keep the Ontologies space alive as well, it is read quite often.

I also suspect Education is going to start being used soon (including by 
me ;)



  * CIMI
  * Terminology

For the rest of you, does anyone care if the following spaces are 
archived?


  * Projects (https://openehr.atlassian.net/wiki/spaces/projects)


this is historical info, and I think can be archived.



 *



  * Zz openEHR Community (https://openehr.atlassian.net/wiki/spaces/oecom)

I guess this can be archived, but what happens the next time people want 
to discuss and record ideas about openEHR Community functioning ;)




 *



Regarding the CQ space: Nobody has asked a question in two years in 
any of the spaces. Do we need to keep the Questions functionality at all?


I don't really know how to interpret the lack of use - I think people 
with questions do not think to go to the openEHR website and find the 
Questions link, which used to be on the home page. Maybe we should put 
it back?


- thomas




Kind regards, Silje

*From:*openEHR-technical  
*On Behalf Of *Thomas Beale

*Sent:* Wednesday, December 19, 2018 7:29 PM
*To:* openehr-technical@lists.openehr.org
*Subject:* Re: Christmas cleaning of the openEHR wiki...

On 19/12/2018 11:19, Ian McNicoll wrote:

Effectively empty:

  * https://openehr.atlassian.net/wiki/spaces/healthcare
(mostly empty pages, last edit in 2011)

there is some content here, but no idea who cares about it.

  * https://openehr.atlassian.net/wiki/spaces/ds (Demo default
Confluence space?)

seems to be Confluence help material - not sure if we should delete or 
not.


  * https://openehr.atlassian.net/wiki/spaces/CQ

I think Confluence creates this when we started using Questions - and 
it says not to delete...


  * https://openehr.atlassian.net/wiki/spaces/WEB

we can probably remove this, since we use Jira to manage web work now, 
but I need to check.


 *

Apparently abandoned:

  * https://openehr.atlassian.net/wiki/spaces/ADL
<https://openehr.atlassian.net/wiki/spaces/ADL/> (last
three edits 338, 965 and 1631 days ago)

this one is not abandoned - contains pages that are linked to from the 
Archetype specs release page 
<https://specifications.openehr.org/releases/AM/latest/index>


  * https://openehr.atlassian.net/wiki/spaces/CIMI (last
activity in 2015)

contains material that should be retained somewhere - I'll have a look

  * https://openehr.atlassian.net/wiki/spaces/edu (two pages,
the most recent edited in 2012)

looks dead

  * https://openehr.atlassian.net/wiki/spaces/ontol (only one
page, edited in 2012)

not used AFAIK

  * https://openehr.atlassian.net/wiki/spaces/projects (last
real contribution 720 days ago)

the community should have a look at this one and decide if it is 
useful I think


  * https://openehr.atlassian.net/wiki/spaces/stds (last real
contribution 950 days ago)

we do actually use this, just not that frequently. I'll move the CIMI 
material here


  * https://openehr.atlassian.net/wiki/spaces/SYS (last
activity 2015)

 we use this for sysadmin; last update: 2018-06-11

  * https://openehr.atlassian.net/wiki/spaces/term (last
activity 2014)

not used for a long time. I would move the SNOMED stuff under the STD 
space.


  * https://openehr.atlassian.net/wiki/spaces/oecom (last real
contribution 805 days ago)

this is a special space that we use for community stuff; don't know 
how much is needed of what is there, though...


- thomas


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

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
__

Re: Retrieving healthcare facility ID details using aql

[Thomas Beale]

Hi Dileep,

Here the UML site is your friend. This is the part of the model 
<https://specifications.openehr.org/releases/UML/latest/#Diagrams___18_1_83e026d_1433773264253_175551_6601>you 
are referring to.


Click through PARTY_IDENTIFIED and you will see that the relevant 
property is 'identifiers', not 'identifier'.


Alternatively, see here in the RM Common IM spec 
<https://specifications.openehr.org/releases/RM/latest/common.html#_party_identified_class>.


- thomas

On 16/05/2019 13:00, Dileep V S wrote:

Hi,
I am committing the heatcare facility id context details n my 
compositions as below


"clinical_notes/context/health_care_facility|id": "123456-123",

"clinical_notes/context/health_care_facility|id_scheme": "UUID",

"clinical_notes/context/health_care_facility|id_namespace": "EHR.NETWORK",

"clinical_notes/context/health_care_facility|name": "HealtheLife",

Trying to retrieve this in aql using

c/context/health_care_facility/id/value as orgID 
andc/context/health_care_facility/identifier/value as orgID


both returns error "Could not interpret 
field:context/health_care_facility/identifier/value"


What is the aql syntax to retrieve healthcare facility ID

regards


Dileep V S
/Founder/
HealtheLife Ventures LLP
m:  +91 9632888113
a:  106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: 	<http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com 
<http://ayushehr.com> <http://ayushehr.com> e: dil...@healthelife.in 
<mailto:dil...@healthelife.in>



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

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL access of fields of potential subclasses or derived archetypes

[Thomas Beale]

Hi Georg,

The generic way to do this is to do what archetype tools do. An 
archetype itself mentioned class and attribute names from a 'reference 
model', but it doesn't know anything about any particular model. SUch 
tools have to be told to load a representation of the model in order to 
validate an archetype against it (i.e. in addition to validating correct 
ADL structures etc). Today, every tool is doing this by loading the BMM 
schemas of the reference models. Probably the Archie project 
<https://github.com/openEHR/archie>contains the easiest to use code that 
does this. (Note: the latest Marand ADL-designer, and LinkEHR, as well 
as the original ADL Workbench all use BMM files these days; but Archie 
is probably going to have the cleanest, most modern source code to work 
with).


The general picture is the same for AQL queries: figure out from some 
environment var, config setting or the RM names in the archetype ids in 
the queries which BMM to use to do the validation. Once you have that it 
is easy.


If you want to know more on Archie, ask here, the authors will no doubt 
respond.


- thomas

On 03/05/2019 12:09, Georg Fette wrote:

Hello,
I have a question the is a bit related to the discussion about the 
constraining of the ELEMENT type in the laboratory_analytes.
The current specification defines the field "ehr_status" of the class 
EHR with the type OBJECT_REF. In the AQL specification there is an 
example (chapter 3.7.2.3. NOT) that accesses this field with the 
assumption that the field is of type EHR_STATUS.
I have written a type checker for AQL queries, so I am now stumbling 
across queries that access fields of potential subclasses or derived 
archetypes.

Does/should the specification generally allow such a thing ?
Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Thomas Beale]

Ian,

If you were referring to the discussion about paths and data types, i.e. 
how do you know if you can refer to some path inside a DvQuantity if the 
archetype only knows about DataValue and LOINC codes, it's true that you 
can use such a path, if the real data (Element.value) happen to be a 
DvQuantity, but you have to be able to reliably figure this out at 
runtime, presumably by inferring it from the LOINC or other code - every 
time? In this situation the AQL processor cannot help you, because it 
doesn't have any information about what lies beyond the Element.value 
point in the structure.


It seems to me that it would be preferable to convert data with 
DataValue specific archetypes, since the general case is that data are 
written once, read many times. In that case, you will have data that 
always has a typed analyte Cluster archetype (e.g. to DvQuantity, 
DvOrdinal etc), and and the AQL service will be able to do proper type / 
path checking. AQL authoring tools will also be able to work in a more 
obvious way (e.g. with auto-complete on paths etc).


So far I am not seeing a downside to this. I realise others have thought 
about it longer than I however ...


- thomas

On 02/05/2019 12:02, Ian McNicoll wrote:
The replies that seref and I gave address the issue. The vast majority 
of lab imports will use the generic analyte cluster.


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


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



___
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

[Thomas Beale]

I'm confused... are you saying the value/value path is not a typo in the 
spec?


On 02/05/2019 12:01, Ian McNicoll wrote:

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

On Thu, 2 May 2019, 11:06 Thomas Beale, <mailto:thomas.be...@openehr.org>> wrote:


Georg,

can you please raise a PR for this problem on the Jira PR tracker
<https://openehr.atlassian.net/projects/SPECPR/issues>?

thanks

On 29/04/2019 22:49, Georg Fette wrote:

Hello,
I have a problem with the interpretation of an AQL query from the
AQL documentation. In section 6.3 the path to the value of the
systolic blood pressure is
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
The first part until
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
denotes a DV_QUANTITY.
Where is the additional field 'value' of the type DV_QUANTITY
defined ?
The class itself defines the fields 'magnitude', 'precision',
'units', 'normal_range' and 'other_reference_ranges'. Its parent
class DV_AMOUNT defines 'accurany_is_percent' and 'accuracy'. The
next parent DV_QUANTIFIED defines 'magnitude_status' and again
'accuracy'. The next parent DV_ORDERED defines 'normal_status',
'normal_range' and again 'other_reference_ranges'. The two
parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
fields.
Has this field access to be 'magnitude' instead of 'value' or am
I missing something ?
Greetings
Georg



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

Re: AQL query for blood pressure from the AQL documentation

[Thomas Beale]

Georg,

can you please raise a PR for this problem on the Jira PR tracker 
<https://openehr.atlassian.net/projects/SPECPR/issues>?


thanks

On 29/04/2019 22:49, Georg Fette wrote:

Hello,
I have a problem with the interpretation of an AQL query from the AQL 
documentation. In section 6.3 the path to the value of the systolic 
blood pressure is

/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
The first part until
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
denotes a DV_QUANTITY.
Where is the additional field 'value' of the type DV_QUANTITY defined ?
The class itself defines the fields 'magnitude', 'precision', 'units', 
'normal_range' and 'other_reference_ranges'. Its parent class 
DV_AMOUNT defines 'accurany_is_percent' and 'accuracy'. The next 
parent DV_QUANTIFIED defines 'magnitude_status' and again 'accuracy'. 
The next parent DV_ORDERED defines 'normal_status', 'normal_range' and 
again 'other_reference_ranges'. The two parents of DV_ORDERED are 
DATA_VALUE and Ordered, both define no fields.
Has this field access to be 'magnitude' instead of 'value' or am I 
missing something ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: automatic demotion of lists in AQL ?

[Thomas Beale]

Unless I am missing something, the fragment items[at0001] cannot appear 
more than once /relative to any given archetype/. Here, it is relative 
to 'a', i.e. openEHR-EHR-CLUSTER.laboratory_test_analyte.v1. Within the 
same archetype, you cannot have other items[xxx] such that the xxx are 
not unique, even if there are multiple 'items' attributes down the 
containment graph. From different archetypes you can, but there is no 
difficulty for the AQL processor to disambiguate these.


On 26/04/2019 12:27, Georg Fette wrote:

Hello,
Is it allowed to use an element that is allowed to appear multiple 
times within a path ?

For example in the query

SELECT a/items[at0001]/value
    FROM EHR e
        CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]


the field items[at0001] may appear 0..* times. Thus the access to the 
value field is not properly defined from a type checking point of view.
Does the AQL specification allow such constructs and how is this 
situation interpreted ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: constraining of laboratory_test_analyte Analyte result

[Thomas Beale]

Well, at the risk of stepping on Ian's toes (he has spent a lot more 
time on these particular archetypes and also AQL in general than me), I 
would say that what we need to do is to create a data-type specific 
version of this archetype for each DATA_VALUE descendant, e.g. 
openEHR-EHR-CLUSTER.laboratory_test_analyte_quantity.v1 etc. For 
example, I did these test archetypes some time ago to illustrate just this:


openEHR-EHR-CLUSTER.laboratory_test_analyte_quantity.v1

The definition of this is:

definition
    CLUSTER[id1.1] matches {    -- -
        /items[id2]/value matches {
            DV_QUANTITY[id0.16] matches {
                normal_range matches {
                    DV_INTERVAL[id0.17]
                }
                other_reference_ranges matches {
REFERENCE_RANGE[id0.18]     -- Quantity reference range
                }
            }
        }
    }

You can see a few others here in the ADL2 test archetype Git repo 
<https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/laboratory2>.


From my analysis, these subtypes are unavoidable in order to make 
querying work, but also to enable manual specialisations e.g. into 
particular analytes, which is something very useful for creating 
standardised analytes and panels.


- thomas

On 02/05/2019 09:57, Georg Fette wrote:


Hi Thomas,
It depends on what you mean with "specialise". I do not wish to create 
a new archetype but I rather would like to query existing instances of 
the openEHR-EHR-CLUSTER.laboratory_test_analyte.v1 archetype. From 
those instances I would like to query only this with specific 
attributes. One constraint I am able to define is to constrain the 
analyte name:


SELECT e
FROM EHR e CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]

WHERE a/items[at0024]/value/value = 'Calcium'

But how can I manage to as well constrain the value ? The path 
openEHR-EHR-CLUSTER.laboratory_test_analyte.v1/items[at0001] is of the 
type ELEMENT, which has a DATA_VALUE for its field "value". The 
concrete instances of the analytes do have decendents of the 
DATA_VALUE type in the place for ELEMENT[at0001]/value, e.g. 
DV_QUANTITY. Is it possible to use paths to those concrete value types 
in the WHERE-paths, such like:


SELECT e
FROM EHR e CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]
WHERE a/items[at0024]/value/value = 'Calcium' AND 
a/items[at0001]/value/magnitude > 100


From a type checking point of view, this is not allowed, because the 
data type at the path a/items[at0001]/value (which is DATA_VALUE) does 
not contain a field "magnitude". To make this work I would have to 
bind the value to the concrete type, with something like:


SELECT e
FROM EHR e CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]

CONTAINS DV_QUANTITY b
WHERE a/items[at0024]/value/value = 'Calcium' AND 
a/items[at0001]/value = b and b/magnitude > 100


but I don't think this is allowed in AQL. I am not yet that fluent in 
AQL, so I could need a little help in this.

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: constraining of laboratory_test_analyte Analyte result

[Thomas Beale]

Hi Georg,

Just to be clear, are you trying to specialise the 
openEHR-EHR-CLUSTER.laboratory_test_analyte.v1 archetype for specific 
analytes, e.g. serum sodium, TSH etc?


- thomas

On 29/04/2019 23:46, Georg Fette wrote:

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

How can this problem be resolved ?
Greetings
Georg


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

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

On 16/04/2019 23:37, Grahame Grieve wrote:

hi Tom


well we need to be precise about what 'extended' means. If you add
first level siblings to the previous version of your value set, it
means your value set was incomplete when published.

yes. and that's the point. The world gets by on incomplete agreements


well specifying and publishing an incomplete value set in a model 
intended as some sort of standard means the authors don't understand 
terminology. Consider: if new top-level codes are later found, they 
really should be children of an 'other' top-level category in the 
original value set.


Nevertheless, I take your point that much of the e-health world doesn't 
really know what it is talking about...




If you want to add children (by far the most common case in
hierarchical terminologies like SNOMED and ICDx) there's no
problem, you are just adding more specific choices of a more
general category you already had.

actually, that *is* the problem. You're taking an agreement and 
varying from it for no good reason. In a world where everyone has a 
terminology server and time to consult it, that may be harmless. But 
only may (there's deep subtleties there). And that's not a world we 
live in.


there are usually very good reasons: non-A-non-B-hepatitis became half 
an alphabet in the last 20y.






To be honest, I am not sure that using required at an archetype
level would be wise, it may be something that can be used at a
template level.


probably true; any 'required' or other setting should probably
only be applied at template level.

I think that's a silly rule. Sometimes, the code is inherent to the 
meaning of the structure. Let people say what they need to where they 
need to.


well I wasn't thinking it should be a rule. What Heath meant (I think) 
was that in reality, the 'required' assertion would be most likely at 
local / template level, not at central level. But we should not prevent 
it being used at any level.





yep. it's a mess. Only human review can establish if there was a code 
that should have been used. I completely understand why you dislike 
this as a systems engineer. But reality doesn't go away.


btw, in all my code, I don't treat preferred and example differently 
in code. the only meaningful difference is in the message you give to 
people making templates up, and it's subtle. It was me who invented 
example, and it's proven a very useful way to get designers to be 
concrete about their meaning when they are making designs that are 
about capabilities rather than actual solutions.


It still seems to me that the right model for this concept is more like:

 * /conformance/: required | extensible | optional
 * /usage/: recommended | example

With only the /conformance /attribute being machine processable.

- t



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

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

'Example' is surely a documentation level concept, not a computational 
one, and I would think often local. So if you are locally saying 'here's 
an example', it's pretty close to saying 'we recommend you use this (in 
this locality)'. So I would think at best it would appear in the 
annotations section of an archetype if in the archetype at all; probably 
more like template documentation?


- thomas



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

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

On 16/04/2019 00:16, Heath Frankel wrote:


Hi Tom,

I agree with Grahame, in over 20 years of implementing real systems, I 
don’t think I recall having seen one value-set that hasn’t been 
extended at some point when locally implemented. Even HL7 defined 
tables in V2 that were supposed to not be extended have been extended.


well we need to be precise about what 'extended' means. If you add first 
level siblings to the previous version of your value set, it means your 
value set was incomplete when published. If you want to add children (by 
far the most common case in hierarchical terminologies like SNOMED and 
ICDx) there's no problem, you are just adding more specific choices of a 
more general category you already had.


There is a big difference between best-practice and reality and we 
don’t want to be putting any more barriers to adoption.


To be honest, I am not sure that using required at an archetype level 
would be wise, it may be something that can be used at a template level.


probably true; any 'required' or other setting should probably only be 
applied at template level.


You could argue that preferred covers extensible and I agree that 
example may not be useful in models, but has proven to be useful as a 
guide for FHIR readers.


Therefore, I think we still have Boolean option, either required or 
preferred/extensible/example.


Having said that, using a Boolean doesn’t allow for us to support a 
valid use case in the future and I see some value in aligning with the 
FHIR options (if HL7 allow us to do that) even if we only support a 
subset.


well I am looking for computability. If we go the FHIR way, people are 
going to be writing code like:


if (x.required) {
    // make sure value is from code set
}
elseif (x.preferred) {
    // hm... anything goes
}
elseif (x.extensible) {
    if (x.value == some code not in the value set) {
        // hm... how to determine if there was a code
    // in the vs that should have been used?
    }
}
elseif (x.example) {
    // ?ignore / don't care ?
}

And probably all doing it differently.

- thomas

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

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

I meant to say, in the previous post:

For large domain value sets (anything beyond ?200), I assume the value 
set sits in a terminology service, and the archetype just has a binding 
straight to that. /So there is no problem with the changing contents of 
this kind of value set/, from the archetype point of view, i.e. it's 
always the same value set, even if specific codes change in its usage. 
/We are only talking about literally inline-included value sets/.


- thomas

On 15/04/2019 22:32, Grahame Grieve wrote:

hi Tom

We did not define extensible bindings because we like it. Using it 
creates many issues and it's problematic. We defined it because it's a 
very real world requirement, in spite of it's apparent 'unreliability'.


The use cases arises naturally when
- the approval cycle of changes to the value set is slower than 
operational requirements
- the value set is large, and a community can only get partial 
agreement in the space. This is actually pretty common - typically, 
clinical code sets may need to contain 5000-5 concepts, but most 
of that is a very lng tail, and 95%+ of the use comes from 200-400 
common codes. There's plenty of clinical communities investing time in 
requiring common agreed codes with fixed granularity for the head of 
the distribution.


Neither of these things are an issue if openEHR is just targeting 
single application functionality. But as soon as the community that 
maintains the value set is wider than the users of a single system, 
then extensible bindings are inevitable.


You can consider it bad... but that doesn't make it go away. Nor does 
it reduce the value of the agreements that do exist.




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

FHIR-like terminology 'binding strengths'?

[Thomas Beale]

Last week, we had a workshop on ADL2 in Germany, to try to sort out a 
few issues on the way to making ADL2 mainstream in openEHR 
implementations. See here for the wiki page 
<https://openehr.atlassian.net/wiki/spaces/ADL/pages/382599192/ADL2%2BTooling%2BWorkshop%2B2019>.


One of the issues discussed was on what basis terminology code 
constraints (value sets, generally) in archetypes (or templates) could 
be considered optional, recommended etc (discussion page here 
<https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007225/Local+Value-set+Replacement>). 
Some here will recognise this question as roughly the one that FHIR's 
'binding strengths' <http://hl7.org/fhir/R4/terminologies.html#strength> 
tries to solve. I can understand two of the settings:


 * /required/: thou shalt use one of these here codes
 * /preferred/: we recommend these codes but you can use what you like

I don't know how useful it is to put 'example' value sets in a content 
model, since there might be many possible examples, differing across the 
world. If there is an obvious example that makes sense for the scope / 
geography of application of the archetype, e.g. some SNOMED or LOINC 
subset, then this seems to me to be a case of 'preferred'.


But my main issue is with 'extensible'. In FHIR, this means: you should 
use one of these codes if it applies to your concept, but otherwise you 
can use something else. In my view, in reality, this is the same as 
'preferred'. It's worth considering what it would mean to mandate codes 
that are supplied in a value-set, but then to say, for other meanings 
not covered, use something else. This means that the value-set is 
considered not to be complete, i.e. to exhaustively cover the concept 
space. Supplying half-built value-sets seems like a very unreliable 
thing to be doing in shared clinical models. Is the value set 90% 
complete? Or only 10%? The whole idea of specifying partial value sets 
in clinical models just seems bad to me.


If we assume that value sets are always well-designed, and exhaustive, 
then the only real 'binding strengths' are: required | optional.


I have proposed that this be modelled as:

 * required: Boolean
 * recommendation: enum ( preferred | example )

If we get rid of the example idea (which I think is just noise) then we 
just need 'required'. If required is false, and there is a value set 
specified, clearly it is 'preferred' or recommended in some sense. If 
there is no value set, it's truly open.


Interested in other thoughts on this, particularly a) users of this FHIR 
scheme and b) SNOMED, LOINC, ICD etc specialists.


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

Re: Identity matching

[Thomas Beale]

part of the answer is to have what we call an EHR Index service - see in 
the Service Model overview 
<https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_openehr_platform_model>. 
That is implemented by some of the platform vendors, but not yet 
officially standardised among them. See section 7 
<https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_ehr_index_package>for 
more technical detail. The ids stored in this kind of service are 
normally ones from an MPI, but could be from anywhere.


- thomas

On 28/03/2019 20:10, Sorcerer Stone wrote:
Among openEHR standard compliant platforms, what is the common 
strategy to handle patient identity management when sharing medical 
records in order to reduce mismatch, duplication, clinical trial 
candidate matching, …
What is the current most logical standard practices for (openEHR) 
administrators/community to handle patient matching issues if it 
involves sharing patient records between openEHR platforms and 
propriety EMR platforms?
Is there a role EMPI can play to assist this process (identity 
matching) within the openEHR standard regime? Or openEHR standard has 
a special build-in mechanism to handle this matching issue?



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

Task Planning Visual Modelling Language TP-VML

[Thomas Beale]

For those interested in clinical workflow, Task Planning, etc, the Task 
Planning Visual Modelling Language (TP-VML) 
<https://specifications.openehr.org/releases/PROC/latest/tp_vml.html> is 
taking shape, initially as a draw.io mode.


TP VML tasks

TP VML events

TP VML task groups

TP VML conditionals decision


- thomas

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: serialization syntax of openEHR instance data

[Thomas Beale]

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

Re: FW: Re: JSON for definitions-notation

[Thomas Beale]

On 16/02/2019 14:00, Bert Verhees wrote:

On 16-02-19 13:20, Thomas Beale wrote:


Have a look at the Archie project 
<https://github.com/openEHR/archie>, you'll find very vanilla Java 
facilities used to do most of this work.


Thank you for pointing this out. But I already knew this. My point is 
not that it is easy to dump an ADL archetype via a parser to a JSON 
representation. My point is that the JSON representation must be the 
result and working modus of archetype/data-handling, in the 
archetype-designer and in the repositories. So the ADL parser and all 
that complex code around it becomes superfluous. There should be no 
temptation to do any processing with ADL.


Even in tools that read ADL archetypes, hardly any of the processing is 
done in ADL, it is done on the in-memory AOM structure - that's true 
both in Archetype modelling tools and runtime validation tools.


The utility of ADL as a syntax, apart from being human-readable (at 
least for those who understand the semantic basis of archetypes) is that 
it never changes, whereas object syntaxes, XML etc are changing all the 
time. This month we are using this flavour of JSON, next month it is 
another flavour. Next year, everyone decides they like YAML instead. IT 
is mostly a fashion show of these kinds of changes.


It's the same with programming languages - their syntax changes only 
with the semantic changes (e.g. Java 1.5 -> 1.8), but not with compiled 
representation.


So I am all for using JSON or whatever in the way that you say, but we 
should just remember that such syntaxes are machine formats optimised 
for something, and they will always be replaced by another format(s) 
optimised for something else. Saving out to ADL can be very useful 
sometimes, in case you want to guarantee to preserve semantics across 
these changes.


The other reason ADL exists is that it is a lot easier for humans to 
learn the archetype formalism via the ADL specification than the AOM 
specification, even though the latter is the one containing most of the 
formal semantics.


- thomas


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

Re: FW: Re: JSON for definitions-notation

[Thomas Beale]

On 16/02/2019 01:38, Bert Verhees wrote:


A few last words on this.

It is easy for JSON based archetype repository to cooperate with an 
ADL based repository. Serializing of an AOM structure to ADL is very 
easy to do, this counts for the DADL and CADL part. The other way 
around, to convert the ADL definition part to JSON is harder, that 
involves the parser-code and grammars which are hard to maintain.


Actually, the AOM -> JSON serialiser is generic code - in my Eiffel code 
base, it is a generic converter from in-memory objects (AOM instances) 
to something like a DOM tree (another in-memory structure consisting of 
just a few types of node and leaf objects) which is then trivially 
serialised to JSON, ODIN and YAML.


More modern libraries as found in Java and all other mainstream 
languages these days do the same, and additionally streaming parser 
tools that can potentially make the conversion quicker (in bulk).


Have a look at the Archie project , 
you'll find very vanilla Java facilities used to do most of this work.


- thomas

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

Re: FW: Re: JSON for definitions-notation

[Thomas Beale]

Bert,

if you serialise a AOM archetype to any object dump format, you need 
typing information for the simple reason that there is polymorphism in 
the model, mainly places where the static type is C_OBJECT, 
C_DEFINED_OBJECT or C_PRIMITIVE_OBJECT but the attached type in a real 
archetype can be a number of descendant types.


W.r.t. the naming convention of RM types, attributes etc, I assume you 
are referring to the fact that openEHR archetypes use the published RM 
type and attribute name format, which is so-called 'snake-case' rather 
than 'camelCase'. To make archetypes that refer to data objects usable 
across software written in different languages using different case 
conventions, it may make sense to add an option to OPT generation which 
indicates the flavour of RM casing. I had not thought of this before but 
it would be easy to implement in an OPT generator.


BMM is getting more powerful by the way. I have recently extended it so 
that it allows types to be annotated with a 'value-set' identifier, 
which can be used to limit the values of e.g. data fields of type 
CodePhrase or TerminologyCode to particular terminologies.


- thomas

On 15/02/2019 22:03, Bert Verhees wrote:


I was thinking about the type information ADL has, if it has function 
in validating datasets.


I don't think so, and I think it can be omitted. For 
validating-purpose it is not needed.
An archetype is a tree of properties to properties ending via 
cardinality to leaf nodes. That is the information that is needed and 
JSON can deliver that without diverging from the object dump idea. All 
that information is already in AOM. This has as result that archetypes 
can be read in AOM without need of parsing.


I was also thinking about the name-convention, but that is a reference 
model (BMM) issue. The naming convention in the reference model will 
be used in datasets.


BMM is very powerful, it extends the purpose of reference models and 
archetypes to virtually every domain, also OpenEhr .


It is in fact a wonderful invention, especially in combination with 
NoSql databases, but it needs a simplicity overhauling for efficiency 
and general connection to programming eco systems or standards can be 
achieved by using its conventions.


Bert




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

Re: JSON for definitions-notation

[Thomas Beale]

JSON, YAML and ODIN are all just object-dump serial formats that result 
from traversing an in-memory object graph, so it is a generic operation 
to generate them from tools (XML is more problematic due to being 
irregular in many ways and being schema-dependent).


In the case of archetypes, the dump is just of objects that are 
instances of the AOM 
<https://specifications.openehr.org/releases/AM/latest/AOM2.html#_the_archetype_package>, 
i.e., ARCHETYPE, C_ATTRIBUTE, various kinds of C_OBJECT and so on.


The ADL Workbench has an export mode (for I think around 5 yeras) that 
generates the first 3 for any archetype, and also a whole archetype 
library. The folks doing CIMI use at least the JSON mode. It also 
generates XML, via custom serialiser.


One of the jobs I never completed is a deserialiser for the 3 regular 
formats, but it is nearly trivial. I am not sure if Archie or Marand's 
ADL-designer tools do the same but I think it should be trivial for them 
to implement as well.


I will look into this again...

- thomas

On 15/02/2019 18:51, Bert Verhees wrote:
I always admired OpenEhr for its ability to notate 
archetype-definitions and now also BMM definitions in any type.


I saw experiments in XML, but the official endorsed notation language 
is ADL.



I wonder, would it also be possible to write archetypes and 
reference-models in JSON?


If so, it would save us tons of code, no grammars needed, no parsers 
needed. Many programming languages support JSON out of the box, with 
only some annotations needed. NoSQL Databases often support JSON, and 
have their own JSON-path based hierarchical query-languages.


Venkat Subramaniam, who is a java-guru, said: "Don't walk away from 
complexity, RUN!!!"


But Einstein said: "Everything Should Be Made as Simple as Possible, 
But Not Simpler"


So the question is: Are there any technical objections to express 
archetypes and reference-models in JSON?


Best regards

Bert Verhees


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




--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 02/02/2019 16:21, Pieter Bos wrote:


*From: *openEHR-technical 
 on behalf of Thomas 
Beale 
*Reply-To: *For openEHR technical discussions 


*Date: *Saturday, 2 February 2019 at 15:01
*To: *"openehr-technical@lists.openehr.org" 


*Subject: *Re: Rules in archetypes - what are the requirements?

Assuming you meant to put 'id7' as the first one, I don't understand 
what this achieves beyond just:


/events[id2]/data/items/element[id7]/value/magnitude >
    /events[id2]/data/items/element[id4]/value/magnitude +
    /events[id2]/data/items/element[id5]/value/magnitude +
    /events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that 
conform to the /events[id2] branch of the structure.


Since the occurrences of events[id2] can be more than one, 
/events[id2]/data/items/element[id7]/value/magnitude in the execution 
environment (actual data) maps to  a List.


well it could be understood that way - that would be to literally 
interpret it as a runtime path. The way I think of it is to mean 'this 
condition xyz must hold true' for each instance to which it applies. 
This greatly simplifies things - otherwise you end up in a complicated 
place like you have described below.


That means you need to define operators such as +, > and = on a list 
of reals. Or to define somehow that a statement containing only path 
bindings within a single multiply-occurring structure will mean that 
it gets evaluated for each occurrence of such a structure. The second 
case is complicated if you need to include data outside /events[id2] 
in your expression. A real world use case would be data in /protocol, 
which can influence the interpretation of event data, but is outside 
of the event.
So we did the first in Archie, with a bit of tricks to make this work 
for assignments. For example, how the plus operator is interpreted in 
Archie:


+(Real r1, Real r2)
  return the sum both numbers
...
Much of this complexity can be avoided by  not defining the operator 
on lists/sets, and requiring the for_all loop on lists or sets of data 
in the specification. This comes at a price, because the author of the 
expressions needs to understand more of the language and data 
structures. So we chose the second, since the previous draft 
specification did not specify at all how to handle these cases.


Undefined value handling is another subject, I have not checked yet if 
the new proposal solves it. We defined some functions to handle this 
explicitly if the automatic handling doesn’t do it ((input , 
alternative) -> return input  unless input is undefined, then 
alternative), as well as some rounding functions.


the Expression Language draft 
<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_defined_predicate> 
has the defined() predicate which I think should do the job.



If we were to allow the expression for_all $event in /data/events[id3] 
then we need to be clear on what it means: it actually refers to an 
object of type List, but do the members consist of EVENT 
objects found in data at the moment the expression is evaluated? Or 
just the statically defined members in the archetype - which can also 
be multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min 
events?


You would need to evaluate on actual data. If you define it on the 
archetype data, you would need some kind of rules to convert it to an 
evaluation on actual data with different multiplicities than the rules 
specify, for example if events[id2] has occurrences > 1. Might be 
possible, I have not tried to define that. Would probably include some 
extra for_all loops plus some kind of validation errors for cases that 
cannot be converted.
So I would say always the data found at the moment which the 
expression is evaluated. You can still refer to separate statically 
defined members using their distinct node ids, and even those could 
have occurrences > 1 (not in the apgar example since those have 
occurrences {0..1} in the archetype).


Normally we want the processing of 'rules' expressions in archetypes 
to apply to the data when the archetype is being used in its normal 
role of creation / semantic validation at data commit time.


Agreed.

So it seems to me that if we want to support expressions like the 
above, we need to be able to do something like (don't worry about the 
concrete syntax too much, could easily be TS or java-flavoured):


*use_model*
    org.openehr.rm

*data_context*

$xxx_events: List
    $item_aaa, $item_bbb, $item_ccc, $item_ddd: Real

*definition*

check for_all event in $xxx_events:
    event/$item_aaa > event/$item_bbb + event/$item_ccc + 
event/$item_ddd


*data_bindings*-- pseudo-code for now

$xxx_events -> /events[id2]
    $item_aaa -> /data/items/element[id7]/value/magnitude
    $item_bbb -> /data/items/element[id4]/value/magnitude
    $item_ccc -> /data/it

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 02/02/2019 13:15, Ian McNicoll wrote:

Hi Pieter,

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


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


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


agree - that is the idea of this construct in the EL

*use_model*
    org.openehr.rm

then you can declare vars to be of RM types like DvQuantity, DvOrdinal etc.

- t


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

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 01/02/2019 14:53, Pieter Bos wrote:


About the calculation:

Ah, I see, the assignment seems like a good solution. But why would I 
need a function to calculate a score that is just a sum of a number of 
values, instead of a few +-operators?


well you might want to re-use that function. More generally, some 
functions are more interesting, e.g. MAP calculation, and it is 
potentially better to a) name them, b) declare them in a more obvious 
place and c) make them re-usable.





Multiplicities/data binding:

The there exists case is clear. However, what if I have four events, 
all having four elements, each with dv_quantity as value. Say I want 
the magnitude of the last of these quantities to be larger than the 
sum of the first three. Before I could write something like:


for_all $event in /data/events[id3]
 $event/data/items/element[id6]/value/magnitude >
$event/data/items/element[id4]/value/magnitude +
$event/data/items/element[id5]/value/magnitude +
$event/data/items/element[id6]/value/magnitude

Assuming you meant to put 'id7' as the first one, I don't understand 
what this achieves beyond just:


/events[id2]/data/items/element[id7]/value/magnitude >
    /events[id2]/data/items/element[id4]/value/magnitude +
    /events[id2]/data/items/element[id5]/value/magnitude +
    /events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that 
conform to the /events[id2] branch of the structure.


If we were to allow the expression for_all $event in /data/events[id3] 
then we need to be clear on what it means: it actually refers to an 
object of type List, but do the members consist of EVENT objects 
found in data at the moment the expression is evaluated? Or just the 
statically defined members in the archetype - which can also be 
multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min events?


Normally we want the processing of 'rules' expressions in archetypes to 
apply to the data when the archetype is being used in its normal role of 
creation / semantic validation at data commit time. So it seems to me 
that if we want to support expressions like the above, we need to be 
able to do something like (don't worry about the concrete syntax too 
much, could easily be TS or java-flavoured):


*use_model*
    org.openehr.rm

*data_context*

    $xxx_events: List
    $item_aaa, $item_bbb, $item_ccc, $item_ddd: Real

*definition*

    check for_all event in $xxx_events:
    event/$item_aaa > event/$item_bbb + event/$item_ccc + 
event/$item_ddd


*data_bindings* -- pseudo-code for now

$xxx_events -> /events[id2]
$item_aaa -> /data/items/element[id7]/value/magnitude
$item_bbb -> /data/items/element[id4]/value/magnitude
$item_ccc -> /data/items/element[id5]/value/magnitude
$item_ddd -> /data/items/element[id6]/value/magnitude

I don't know what this archetype is, so assume that $xxx_events, 
$item_aaa etc are more meaningful names.


The next problem you mentioned is:

PB: Note that a path that points to a single typed dvquantity in an 
archetype can still point to many items in the RM if somewhere up the 
tree there is a list or a set, for example more than one observation


So I think this implies an incorrect interpretation of this kind of code 
within an archetype. It can't be understood as simultaneously applying 
to multiple Observations if it is within an Observation archetype, only 
to one OBSERVATION instance at a time - usually one about to be committed.


You can still have Lists of things internal to the archetype, as shown 
above with the Events list, but to process the multiplicity, you would 
need to do as we have done and use for_all, or some other 
container-aware operator or function.


Anyway, does this get closer to the sense of what you would like to do? 
It's more than I had conceived of, so this is a useful challenge...


- thomas


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

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

Thanks Pieter,

this is very useful.

On 01/02/2019 12:54, Pieter Bos wrote:


For us the main requirement of the rules is to calculate the value of 
other fields based on other fields. Only the checking of assertions 
has relatively little added value for the use cases our customers 
encounter. I would find it very hard to explain to any users or 
modelers that they can write checks that do the actual score 
calculation, but that they cannot actually use the calculated value 
anywhere. So we ignore this limitation altogether.


the obvious solution to that requirement seems to be to a) use functions 
and b) to allow assignment:


*rules
*    -- assert that manually set total is correct
*check *$apgar_total_value == apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



*rules
*    -- assign total value
    $apgar_total_value = apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)




Also the value binding seems to have an case that has not been covered:

it is possible that a single path lookup results in a list of values. 
This means a single path-bound variable will contain multiple values 
(so a list of values). In the old case, you could handle this with a 
for_all statement to express that the assertion should be valid within 
the scope of a single event, for all events. How could value binding 
solve this? The same question applies to output variable binding as 
well as input variable binding.


conceptually, rules statements are typed, so in this case, the type will 
be List or List or whatever. In that case, expressions 
need to treat it in the normal way, i.e. with List or Set operators that 
obtain single values. E.g.


$systolic_bp_samples: List

there_exists v in $systolic_bp_samples : v > Systolic_bp_threshold 
implies 


These kinds of things (and for_all) are documented in the Expression 
Language draft 
.


Related to this, both the current and proposed specification is 
missing execution rules, especially when paths lookup to a list of 
values instead of a single variable and how to handle that. For 
example what does the following mean when 
/data/events/data/items/element[id3]/value/magnitude resolves to more 
than one value?


I don't see how it can, since that path is defined to be of type Real 
(not List or Set etc) by the RM definition of DvQuantity. 
But I'm probably missing something in the sense of your question...


Anyway, the more I can find out about current requirements, working 
solutions, workaround etc, the better - the intention is to evolve the 
expression facility in archetypes to match those needs and to be as 
useful as possible.


- thomas


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

Rules in archetypes - what are the requirements?

[Thomas Beale]

For many years, there has been a little-used capability in ADL which 
enables basic expressions to be stated such as the following in the 
Apgar Observation archetype:


*rules*

/score_sum/: 
/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude = 
/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value + 
/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value + 
/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value + 
/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value + 
/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value


where all those paths point to the various Apgar leaf data values, i.e. 
total, heart rate etc.


This kind of statement is intended to assert that the total value = the 
sum of the 5 elements, as per the Apgar formula. However, it was never 
that clear that it is an assertion, not a value-setting formula, which 
might also be something we want.


It's also not very readable, even if the paths were rendered with a 
tool, they are long and painful to read.


Another kind of assertion was to for conditional mandation of some part 
of the data depending on some other data element (or more generally, an 
expression), e.g.


*rules*

/data[id2]/items[id21]/items[id15]/value[id50]/defining_code *matches 
*{[at19]} *implies exists */data[id2]/items[id21]/items[id20]


Here the logical intention is to mandate that the data at the second 
path, which is about details of transfer (i.e. discharge to other care) 
if the value of the datum at the first path, which is 'type of 
separation' = at19|transfer|. Other examples are mandating data 
containing details of tobacco use if the value of the data item 'tobacco 
use' /= at44|non-user|.


This also is not that easy to read, or clear in its intentions.

More recently, as part of the development of a simple expression 
language that can be used across openEHR (archetypes, Task Planning, GDL 
etc), I proposed some key improvements to expressions in archetypes, namely:


 * symbolic names for paths, done by bindings
 * an explicit 'check' instruction to make the intention of assertion
   clearer
 * a defined() predicate to replace the use of 'exists'

Examples of how these changes look are shown here in the working copy of 
the ADL2 spec 
. 
In this form, the above Apgar example becomes:


*rules*
*check *$apgar_total_value = $apgar_heartrate_value + 
$apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value + 
$apgar_colour_value


*data_bindings*

    content_bindings = <
    ["apgar_breathing_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">
    ["apgar_heartrate_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">
    ["apgar_muscle_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value">
    ["apgar_reflex_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value">
    ["apgar_colour_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value">
    ["apgar_total_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude">

    >

And the smoking example is:

*check *$is_smoker = *True **implies **defined *($smoking_details)

Note that this does not address the possible requirement of being able 
to state a formula that /sets /a field, or defines a purely computed 
value at a path.


We are still working on details of the expression language, variable 
binding idea and so on. I am interested in feedback on the approach 
shown in the spec, preferably provided here in the first instance.


- thomas

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

Useful openEHR terminology Links on specifications page

[Thomas Beale]

There are now some useful links to get to any openEHR terminology group 
on the specifications home page 
(scroll down) in one click.


- thomas


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

BASE Component 1.1.0 Release published

[Thomas Beale]

BASE component Release 1.1.0has been published 
 by 
theopenEHR SEC 
.


It contains a number of improvements to theArchitecture Overview 
, 
and formalises theFoundation 
andBase 
types 
specifications, 
consisting mainly of content previously in the RM Support Information Model.


- openEHR SEC

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

Re: DV_PROPORTION vs DV_QUANTITY for %

[Thomas Beale]

one thing to note: DV_PROPORTION is a more complex data structure. I 
would be tempted to try to determine what use has been made of this 
archetype so far - i.e. in creating real data. If no real data has been 
created, then it could in theory be changed.


- thomas

On 07/01/2019 12:11, Ian McNicoll wrote:

Hi Silje,

As you say, I think this a case of emerging clarity (or less fog of 
confusion!!) as the various use-cases emerge. As the primary author of 
both these archetypes, in retrospect I would probably keep 
inspired_oxygen as DV_PROPORTION and change pulse_oximetry to 
DV_QUANTITY but!!! I do not see any good argument for changing these 
now. We have to expect some degree of inconsistency, and live with it, 
to avoid unnecessary breaking changes.





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

Re: DV_PROPORTION vs DV_QUANTITY for %

[Thomas Beale]

On 05/01/2019 12:56, Ian McNicoll wrote:
There is a very clear use-case for having it there - O2 levels 
variably and equivalently described a FiO2 which is a unitary 
proportion or percent.


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


So in that case we need to upgrade the documentation for when to choose 
a DV_QUANTITY percent, and when a DV_PROPORTION %.


- thomas



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

Re: DV_PROPORTION vs DV_QUANTITY for %

[Thomas Beale]

Hi Silje,

See here 
<https://specifications.openehr.org/releases/RM/latest/data_types.html#_ratios_and_proportions>. 
But I think the % case may have been there since early 2000s and either 
% was not in UCUM, or perhaps it was, but we did not realise it. So 
ideally we should change the documentation to obsolete it in DV_PROPORTION.


- thomas

On 04/01/2019 20:40, Bakke, Silje Ljosland wrote:

In that case, I don't understand the use case for the 'percent' and 'unitary' 
variants of the DV_PROPORTION data type. What are they for?

Regards,
Silje

-Original Message-
From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Friday, January 4, 2019 8:38 PM
To: openehr-technical@lists.openehr.org
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %


On 03/01/2019 08:37, David Moner wrote:

I think DV_QUANTITY is the option here. Someone could argue that % is
not a proper unit, but it is, both in UCUM and SNOMED CT.

DV_PROPORTION should be only used when you want to maintain the
numerator and denominator explicitly separated, as a fraction, which
should not be the case with percentages. But it is true that the
definition of the type attribute in the specification is a bit
misleading: "Indicates semantic type of proportion, including percent,
unitary etc."

David is right on all counts - use DV_QUANTITY, but we should fix that line in 
the specification. Can someone raise a PR on that please.

- thomas



___
openEHR-technical mailing 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


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

Re: DV_PROPORTION vs DV_QUANTITY for %

[Thomas Beale]

On 03/01/2019 08:37, David Moner wrote:
I think DV_QUANTITY is the option here. Someone could argue that % is 
not a proper unit, but it is, both in UCUM and SNOMED CT.


DV_PROPORTION should be only used when you want to maintain the 
numerator and denominator explicitly separated, as a fraction, which 
should not be the case with percentages. But it is true that the 
definition of the type attribute in the specification is a bit 
misleading: "Indicates semantic type of proportion, including percent, 
unitary etc."


David is right on all counts - use DV_QUANTITY, but we should fix that 
line in the specification. Can someone raise a PR on that please.


- thomas



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

Re: Error in website

[Thomas Beale]

Ths XSD and JSON repo folders did not have index files - we have added 
some simple ones to display everything. We'll improve these over time.


- thomas

On 04/01/2019 14:20, Bert Verhees wrote:

Don't know where to tell this, but there is something not okay on:

https://specifications.openehr.org/releases/ITS/latest/index

Many links don't work 



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

Re: Christmas cleaning of the openEHR wiki...

[Thomas Beale]

On 19/12/2018 11:19, Ian McNicoll wrote:



Effectively empty:

  * https://openehr.atlassian.net/wiki/spaces/healthcare (mostly
empty pages, last edit in 2011)


there is some content here, but no idea who cares about it.



  * https://openehr.atlassian.net/wiki/spaces/ds (Demo default
Confluence space?)


seems to be Confluence help material - not sure if we should delete or not.



  * https://openehr.atlassian.net/wiki/spaces/CQ

I think Confluence creates this when we started using Questions - and it 
says not to delete...




  * https://openehr.atlassian.net/wiki/spaces/WEB

we can probably remove this, since we use Jira to manage web work now, 
but I need to check.




 *

Apparently abandoned:

  * https://openehr.atlassian.net/wiki/spaces/ADL
 (last three
edits 338, 965 and 1631 days ago)

this one is not abandoned - contains pages that are linked to from the 
Archetype specs release page 




  * https://openehr.atlassian.net/wiki/spaces/CIMI (last activity
in 2015)


contains material that should be retained somewhere - I'll have a look


  * https://openehr.atlassian.net/wiki/spaces/edu (two pages, the
most recent edited in 2012)


looks dead



  * https://openehr.atlassian.net/wiki/spaces/ontol (only one
page, edited in 2012)


not used AFAIK



  * https://openehr.atlassian.net/wiki/spaces/projects (last real
contribution 720 days ago)

the community should have a look at this one and decide if it is useful 
I think




  * https://openehr.atlassian.net/wiki/spaces/stds (last real
contribution 950 days ago)



we do actually use this, just not that frequently. I'll move the CIMI 
material here




  * https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)


 we use this for sysadmin; last update: 2018-06-11


  * https://openehr.atlassian.net/wiki/spaces/term (last activity
2014)



not used for a long time. I would move the SNOMED stuff under the STD space.



  * https://openehr.atlassian.net/wiki/spaces/oecom (last real
contribution 805 days ago)

this is a special space that we use for community stuff; don't know how 
much is needed of what is there, though...



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

[Thomas Beale]

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


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

Re: AW: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

On 18/12/2018 16:48, Sebastian Garde wrote:


Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus 
boils down to my question from before whether it is valid or not to 
just leave the version part out completely.


In my understanding the regex needs to be fully matched which means 
you cannot just leave it out completely – but it is not 100% clear 
from the specs as far as I can see (but see my excerpt from the ADL2 
specs from before).


if you are using the regex to validate ids, then you will need the full 
regex to match any valid id. If the regex is just to filter out ids that 
are validated elsewhere then you can minimise the regex.


If we assume the regex does NOT need to be a full match, then the 
validation errors from CKM below are bogus of course.


But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:


For example, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 would 
then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 
v11 etc. for example)


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] 
means that not only v0, v1, v2 are valid, but also v10, v15, v27 to 
name a few.


the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.


Now that you mention it, I do seem to remember we specified a very long 
time ago that those regexes did have to be full validating ones. So that 
means using something more like


openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where 
the trailing '.*' matches anything, and the validator regex ensures it 
is only semver dotted version patterns.


- thomas


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

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

For reference, these are the various regexes I use in the ADL workbench 
.



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

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.


is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically 
different archetypes - i.e. they contain some breaking change. So 
whether allowing any major version of an archetype in a slot is a good 
default probably needs to be thought about carefully.


- thomas

On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:


Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY 
archetypes, or ENTRY archetypes within COMPOSITIONs or SECTIONs). At 
the moment this has to be noted explicitly (whether because of tooling 
or the specifications, I don’t know), so that in order to include for 
example all historical versions and specialisations of the Body Mass 
Index archetype in a COMPOSITION or SECTION, I have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we 
ever make a v3 BMI archetype, this will then need to be added. This is 
a hassle when modelling archetypes in the first place, and it’s an 
even worse problem for governing them over time.


Based on the discussion I had with Sebastian, and with the kind help 
of some regex geeks on Twitter (you know who you are ), I propose 
one of the following as the default syntax for including any version 
of a given archetype in a SLOT:


 1. An explicit regex for the version number, for example

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
 2. Leaving out entirely the version part of the expression, for
example openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be /possible/ to include a specific version of 
the archetype, but that this should not be the default behaviour of 
the tools.


I don’t particularly care if one of these two suggestions, or an 
entirely different solution, is adopted, but this issue has to be 
decided and implemented soon.


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no <http://arketyper.no/>/ Twitter: 
@arketyper_no <https://twitter.com/arketyper_no>



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

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

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

[Thomas Beale]

They are already working on a local install version for that.

On 13/12/2018 14:58, Bert Verhees wrote:

On 13-12-18 13:08, Thomas Beale wrote:
No, it is under heavy development, and will definitely become the 
main tool for modellers - 


I don't hope so, it would be bad for the OpenEhr-promotion.

It forces people to make their templates known to a third party 
website, I can imagine that commercial companies do not want to do this.


Their data-structures are often regarded as their crown-jewels.



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

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

[Thomas Beale]

On 13/12/2018 06:47, Dileep V S wrote:

Do you have any idea on how to get an account for ADL designer?


just working on that.


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

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

[Thomas Beale]

No, it is under heavy development, and will definitely become the main 
tool for modellers - or maybe with LinkEHR it will be equally used as 
well (that is also well maintained). The UI tool is not open source; 
some of the core libs are I think. So you will not see current source 
code in Github or anywhere like that.


From what Diego is saying, LinkEHR is getting better at openEHR 
templates, so it may be that we have two excellent tools to work with, 
not a bad situation ...


- thomas

On 13/12/2018 05:35, Dileep V S wrote:
The last gitlab commit for this project is 3 year ago. Is that the 
latest version?





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

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

[Thomas Beale]

It's fully working but now I realise that you may have to apply for a 
login - they are still beta testing AFAIK. But it is already in 
significant use.


I'll enquire the status of self-registering.

- thomas

On 13/12/2018 04:50, Dileep V S wrote:
Have seen news in the mailing list and have been wanting to try it for 
sometime. Unfortunately the OpenEHR tools page link only seems to have 
a test account login. Is there a version that can be used for 
production? or at least save and rework with files securely?





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

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

[Thomas Beale]

Have you tried ADL designer 
yet? This is the tool 
modellers are migrating to for general modelling of archetypes and 
templates, and it supports ADL 1.4 and .oet templates.


- thomas

On 13/12/2018 03:21, Dileep V S wrote:

HI,

I have been using Archetype editor and Template designer so far and am 
experimenting with LinkEHR studio. I have managed to import, visualize 
and edit OpenEHR archetypes(1.4).


However I am not able to understand how to combine archetypes into a 
template (like we do in Template designer) and export OPTs.I am 
importing these OPTs into an EtherCIS server. Is this possible? if yes 
can somebody point to the documentation for this(the documentation 
from LinkEGR only talks about Archetypes)




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

Re: ID namespace for composer and healthcare facility

[Thomas Beale]

At the moment I think you can safely default the namespace attribute to 
a value like "EHR", "Demographic", "Terminology" etc, which acts as a 
service name or type.


Now, if you look at the OBJECT_ID sub-types 
<https://specifications.openehr.org/releases/BASE/latest/base_types.html#_identification_package>, 
you'll see that they are either UID-based - i.e. based on GUID or maybe 
OID (avoid if humanly possible), or reverse domain names. These are all 
already globally unique.


The subtypes ARCHETYPE_ID, TEMPLATE_ID (not in use) are also globally 
unique. To make archetype ids properly globally unique, they can/should 
have true namespaces prepended, as described here 
<https://specifications.openehr.org/releases/AM/latest/Identification.html#_source_artefact_identification>. 
Section 7 of that doc gives you some examples. The class that defines 
those identifiers is ARCHETYPE_HRID. All of these id types are for 
design artefacts, so I think not your primary concern right now. The 
type TERMINOLOGY_ID is the same, but less well controlled, but usually 
reliably global, because major terminologies tend to be in global use.


The remaining type, GENERIC_ID, is assumed to be a string with a scheme 
type that makes it unique, but might not. The example is things like 
patient hospital ids. Ideally, national patient ids, social security 
numbers etc are unique.


- thomas

On 13/12/2018 03:14, Dileep V S wrote:

Hi Thomas,
Thanks for the info.

Just to clarify my understanding, you feel that the namespace 
attribute in for information only and so can be set as we choose.


However, I am not sure that I understand your statement "all target 
OBJECT_IDs of the various concrete types are already globally unique". 
Do you mean using UUIDs for EHRID, PersonID etc? Can you elaborate 
some more one how this is being managed?




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

Re: Reference Model as Archetypes ?

[Thomas Beale]

You can always check conformance with the ADL Workbench, it will consume 
ADL1.4 and ADL2. And Archie now produces the same regression results as 
ADL WB, so it could be used as well, and in future, will probably become 
the main reference tool.


- thomas



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

Re: use_node semantics

[Thomas Beale]

Hi Georg,

the documentation for use_node in ADL2 is here 
<https://specifications.openehr.org/releases/AM/latest/ADL2.html#_internal_references_proxy_constraint_objects>. 
It applies nearly the same for use_node in ADL1.4, which is specified 
here 
<https://specifications.openehr.org/releases/AM/latest/ADL1.4.html#_internal_references>.


- thomas

On 12/12/2018 13:13, Georg Fette wrote:

Hello,
I am unsure about the semantics of the use_node keyword. Can the 
archetype branch that is attached at the place where use_node is 
mentioned be seen like when a preprocessor would paste the part of the 
referenced branch into the place where use_node is used ? In practice 
this could create problems when a recursive insertion of the 
referenced branch is inserted, but from a logical point of view is 
that interpretation correct ?
Is an archetype using use_node-branches equivalent to an archetypes in 
which the referenced branch have been explicitely pasted into the 
use_node places ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: ID namespace for composer and healthcare facility

[Thomas Beale]

Hi Dileep,

as far as I know, all target OBJECT_IDs of the various concrete types 
are already globally unique. I suspect the namespace attribute will not 
be used in the future, or will have just informational value. It would 
be useful to know what other implementers currently do with this attribute.


- thomas

On 12/12/2018 11:18, Dileep V S wrote:

Hi,
Compositions require id_namespace for composer and healthcare 
facility, along with id & id_scheme, to uniquely identify them. How do 
we ensure universal uniqueness for such name spaces? Is there any 
central registry where EHR systems are supposed to register their 
namespaces?





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

Re: Reference Model as Archetypes ?

[Thomas Beale]

I think this is more or less the same as a kind of archetype with no 
codes at all, only containing RM elements.


I was expecting something more like:

CLASS [Observation_code] matches {
    attributes matches {
    ATTRIBUTE [Observation_data_code] matches {
    name matches {"data"}
    ...
    }
    ATTRIBUTE [Observation_state_code] matches {
    name matches {"state"}
    ...
    }
    }
}

or you could do it with C_OBJECT and C_ATTRIBUTE, which is a workable 
meta-model.


- thomas

On 11/12/2018 10:58, Diego Boscá wrote:

As an example, this is the Observation archetype

https://pastebin.com/WhehexLR

El mar., 11 dic. 2018 a las 11:53, Diego Boscá (<mailto:yamp...@gmail.com>>) escribió:


It is basically AOM, serialized as ADL files

El mar., 11 dic. 2018 a las 11:51, Thomas Beale
(mailto:thomas.be...@openehr.org>>)
escribió:

Diego,

what do you use as the underlying information model in that case?
Presumably the BMM/UML meta-model, i.e. things like Class,
Attribute etc?

- thomas

On 11/12/2018 09:40, Diego Boscá wrote:
> Hi Georg,
>
> That's exactly how we define reference models with LinkEHR. We
> generated them from the XSD schemas (and more recently, from
BMM). It
> fits quite nicely with the archetype methodology (every
archetype is
> an specialization, which eases validation).
> If you want to try or test them you can download LinkEHR and
get them
> from there.
>
> Regards


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

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



-- 


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

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

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

VeraTech for Health SL
+34 654604676 
www.veratech.es <http://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
<mailto: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



--

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

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


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

VeraTech for Health SL
+34 654604676 
www.veratech.es <http://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...@ve

Re: Reference Model as Archetypes ?

[Thomas Beale]

Diego,

what do you use as the underlying information model in that case? 
Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?


- thomas

On 11/12/2018 09:40, Diego Boscá wrote:

Hi Georg,

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


Regards



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

Re: ADL specification question

[Thomas Beale]

Hi Georg,

the other answers are right, but for reference you may want to read the 
relevant part of the ADL specification (ADL2 version 
<https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_constraints_on_complex_types>; 
ADL1.4 version 
<https://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_structure_3>). 
The main thing to understand is that 'cardinality' applies to container 
attributes, and that 'occurrences' defines how often an object node may 
appear in the data.


The ADL2 version gives the clearer explanation, and the main semantics 
of cardinality and occurrences have not changed from one to the other.


- thomas

On 29/11/2018 10:09, Georg Fette wrote:


Hi Diego,
The items inside the CLUSTER look like this:

CLUSTER[at0001] matches {
   items cardinality matches {2..*; ordered} matches {
 ELEMENT[at0002] matches {
   value matches {
 DV_COUNT matches {*}
   }
 }
 ELEMENT[at0003] matches {
   value matches {
 DV_TEXT matches {*}
   }
 }
   }
}

It could be that I not yet fully understand ADL, therefore I would need to 
verify/falsify some assumptions I make:

- Both elements (at0002, at0003) have an implicit cardinality of "1..1" ?
- The keyword "ordered" just indicates that the items inside an instance of the 
cluster at0001 have to maintain the order in which they were defined. The order does not 
affect an enforced order of the types of the elements inside the cluster ?
- What is true?:
* The cluster at0001 may include the elements at0002 and at0003 in any order an 
unlimited amounts of them as long as the cluster includes at least 2 of them. The 
specification inside of at0001 just gives the set of possible elements that may appear as 
items of at0001. E.g. "at0003, at0003, at0002, at0003, ..."
* The cluster at0001 has to include at least 2 elements in the order given in the 
at0001 definition and the order may be repeat an unlimited amount of times, e.g. 
"at0002, at0003, at0002, at0003, ..."

Greetings
Georg

>Hello Georg,
>
>What (and how many) objects you have inside the items attribute?
>Think the cardinality as the "vector" capacity, and inside you can put them
>in order (depending on their occurrences, they may even not appear at all)
>
>Regards
>
>El jue., 29 nov. 2018 10:31, Georg Fette http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>>
>escribió:


Am 29.11.2018 um 10:30 schrieb Georg Fette:

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

Greetings
Georg



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

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

Re: Two-level modelling diagram

[Thomas Beale]

On 28/11/2018 17:56, Pablo Pazos wrote:

Do we need the user in the middle?


we could, although I learned a long time ago to only include relevant 
elements, and the point of this diagram is just one thing: where the 
models of information are made, and how they relate to the built system.




Another point, I always thought that diagram lacks some management, 
for instance the developer is not who manages the IT aspects of the 
system running in production, makes deployments, updates, etc.


well then we are into the cycle of software management, I'm not trying 
to represent any of that, just to show in a relatively simple way how 
the models relate to the system.




And thinking about this, there are at least two main flows: one is 
design-development-use, and the other is maintenance-evolution. I 
think the second one might be even more important than the first one, 
where domain experts get feedback from the users, and the IT team gets 
feedback from users and domain experts, for instance to make changes 
or create more reports or add UI elements. IMO this second flow is 
what gives openEHR a lot of value.


also true - but I would make a second diagram to show UI / UX feedback 
loop and evolution.


You can try to make some variations, just use the draw.io source at 
Github 
.


- t


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

Re: Two-level modelling diagram

[Thomas Beale]

I was already on it ;) (FWIW, I habitually leave out terminology from 
diagrams only because it's so pervasive that putting it in properly 
would always turn a simple piece of sushi into a bowl of spaghetti...)


For people who want the document context, and another well-known 
diagram, see here in the Architecture Overview 
.


- thomas

On 28/11/2018 13:28, Bakke, Silje Ljosland wrote:


I also like this diagram a lot, big improvement on the old one! 

Would it be relevant to add a cylinder for terminologies in the 
knowledge development environment part (with arrows to archetypes and 
templates), to show explicitly that they’re thought of and highly 
relevant?


Regards,

*Silje*



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

Two-level modelling diagram

[Thomas Beale]

This diagram 
(SVG) 
is a replacement for an old one used in a lot of papers. People who want 
a better diagram might like this one, from a more recent version of the 
Architecture Overview.


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

Better definition of 'system_id' attribute in openEHR sytems

[Thomas Beale]

Following SPECPR-99  and 
this email string 
 
from 2014, the imminent RM 1.0.4 release will include SPECRM-80 
, which improves the 
documentation about /system_id/, which is recorded in the EHR and also 
in AUDIT_DETAILS, i.e. on each committed version.


In response to this, I have added the following documentation to the 
Architecture Overview, and will also add further text and hot links to 
the specific locations in the EHR and Common parts of the RM. It would 
be useful to know if this agrees with the understanding of openEHR 
system implementers and users.





 6.1. The EHR System

The notion of a logical EHR /system/ is central to the openEHR 
architecture. In openEHR, a system is understood as a distinct logical 
repository corresponding to an organisational entity that is /legally 
responsible/ for the management and governance of the healthcare data 
contained within. This may be a regional health service that serves 
multiple provider enterprises or a single provider enterprise such as a 
larger hospital. The 'system' is therefore in general distinct from 
specific applications and also from provider organisations, even if in 
some cases it happens to be owned by a single provider. It is also 
distinct from any underlying virtualisation infrastructure or cloud 
computing facility, which may house multiple logical EHR systems in a 
multi-tenant fashion. This is clear by comparing the legal 
responsibilities of the infrastructure provider, which are for /generic 
IT service management/ to a procurer, which may be a healthcare data 
management entity. It is the latter that undertakes legal responsibility 
for the content, on behalf of one or more healthcare provider organisations.


The technical criterion for identifying an EHR system is that it is the 
entity that assigns version identifiers within a repository.



   6.1.1. System Identity

Within the openEHR architecture, a |/system_id/| attribute is recorded 
both within each patient EHR (|EHR| class), and also within the audit 
created with each commit of data to an EHR (|AUDIT_DETAILS| class). This 
identifier identifies the logical EHR system as described above, and may 
be of any form. Common forms include the reverse domain name and plain 
and structured string identifiers. The system identifier is /not assumed 
to be directly processable/, but may instead be used as a key, for 
example in a service maintaining location information.


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

Re: Postcoordinated terminology expressions in openEHR

[Thomas Beale]

I mostly agree with Ian, but with the small caveat that for very 
specific and well-known cases such as body laterality, you just /might 
consider/ post-coordination on body site e.g.


 * 56459004 |foot structure| : 272741003 |laterality| = 7771000 |left|)

However, even here, laterality often seems to be divided out in various 
ways depending on what you are talking about. E.g. anything to do with 
eyes, the whole exam is per-eye rather than each finding being marked as 
being on the 'eye, left' or 'eye, right'. In other places, 'left' and 
'right' don't even have symmetrical meanings e.g. the heart (think 
left-branch bundle etc).


Nevertheless, for those body sites where findings are reported as being 
on some X+left or right, I think we probably should consider 
post-coordination of the site and the laterality at some point. For 
everything else, it's a nice idea but forget it in data models.


Where it could be used is via a /mapping formula /for multiple data 
points, e.g. in an archetype. The archetype data would be defined 
populated as a structure (as today), but a 'post-coordination formula' 
that indicates how to bind the values of particular coded elements 
together to obtain a Snomed expression could be used to generate such 
expressions from the data, for consumption by inference engines. This is 
the only place where they can be usefully computed with, in my opinion.


Such a formula might look like this:

 * 47933007 |$pain_finding| : 363698007 |finding_site| = (
   $finding_site: 272741003 |laterality| =  $laterality)

where $pain_finding, $finding_site and $laterality are bound to paths in 
the archetype.


If the formula were evaluated, it might give this:

 * 22253000 |pain| : 363698007 |finding site| = ( 56459004 |foot
   structure| : 272741003 |laterality| = 7771000 |left| )

With minor adjustments in the binding part of the ADL2 grammar, such 
formula bindings could be accommodated fairly easily I would think.


Note: this is speculation, and has never been tried as far as I know. 
Even if it does, it's only for SNOMED, unless the SNOMED model of 
post-coordinated expressions is adopted by other terminologies...


- thomas


On 19/11/2018 13:32, Ian McNicoll wrote:

Basically - don't!!

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


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


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


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


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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
<mailto:ian.mcnic...@openehr.org>

Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 19 Nov 2018 at 13:20, Bakke, Silje Ljosland 
<mailto:silje.ljosland.ba...@nasjonalikt.no>> wrote:


Hi everyone,

We’ve recently started an informal and practically oriented
regular contact with the Norwegian SNOMED CT NRC. One of the
things they were interested in discussing was how to use
postcoordinated SNOMED CT (expression constraint language)
expressions with openEHR, which I know nothing about. Does anyone
have any knowledge about or experience with this?

Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no <http://arketyper.no/>/ Twitter:
@arketyper_no <https://twitter.com/arketyper_no>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto: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

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

openEHR BMM files have moved to new specifications-ITS-BMM repository

[Thomas Beale]

*Attention all users of the openEHR BMM files*:

these used to be in the Github repo reference-models 
<https://github.com/openEHR/reference-models>, but have now moved to 
specifications-ITS-BMM Github repo 
<https://github.com/openEHR/specifications-ITS-BMM>. They have also had 
numerous small errors fixed by Kristoffer Lundberg, Chief architect at 
Cambio Health Systems, for which we are very grateful.


The files are laid out in a different way, with the directory structure 
reflecting the new component structure.


/original   # BMMs from original openEHR, prior to 
separated components
/example# BMM containing documentation on 
format with examples
/components
/BASE   # BMMs for BASE component
/Release-1.0.0  # BMMs for Release-1.0.0 of BASE
/etc
/LANG   # BMMs for LANG component
/Release-1.0.0  # BMMs for Release-1.0.0 of LANG
/etc
/RM # BMMs for RM component
/Release-1.0.3  # BMMs for Release-1.0.3 of RM
/Release-1.0.4  # BMMs for Release-1.0.4 of RM
/etc
/PROC   # BMMs for PROC component
/Release-1.0.0  # BMMs for Release-1.0.0 of PROC
/etc

To use these files in tools, the recommended approach is to point the 
tool to the|components|(or|original|, if using Release 1.0.2) directory 
of a clone checkout area, and to manage a table of files identified by 
schema id (determined by meta-data inside the files), and to resolve the 
include references via this table.


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

Re: Parsing of Archetypes/Templates

[Thomas Beale]

On 12/11/2018 16:04, Bert Verhees wrote:

On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot 
do this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate 
anything. As I wrote this morning, LinkEhr also generates Schematron 
for validation purpose.


this already works (for nearly 10 years) and it validates against the 
XML schema standard. What it doesn't do is validate everything you want 
to validate, i.e. not all things in the archetypes. But it's good enough 
most of the time.


To do things properly, I agree, you would probably use Schematron + XSD, 
or personally I have always thought that Schematron + Relax-NG would be 
better.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


that might be an interesting thing to have in the openEHR toolkit. We 
are just now revising and re-organising all the openEHR XSDs, and also 
adding in some JSON-schemas. Any related artefacts that anyone wants to 
contribute, or fragments that could be used in something larger would be 
appreciated - it will all get posted in the specifications-ITS-XML git 
repo under the usual CC licence.


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

Re: Parsing of Archetypes/Templates

[Thomas Beale]

On 12/11/2018 09:44, Bert Verhees wrote:


Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot have 
an XSD to describe an archetype and check a dataset with it.


you can, it's called a Template Data Schema (TDS), and is generated from 
the Template Designer and I think the new Marand ADL-designer. Its 
intended exactly for checking data sets...


whether this is the real requirement being talked about here may be 
another question.


- thomas



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

GDPR and consent - Sitra's IHAN blueprint

[Thomas Beale]

Finland's Sitra institute (something like Fraunhoffer in Germany) has 
published a very interesting paper on a GDPR-compliant architecture for 
consent <https://media.sitra.fi/2018/09/25133347/180925-ihan-blueprint.pdf>.


I have not fully digested yet, but I thought I would share here.

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

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

[Thomas Beale]

I've just been thinking more about this problem. I agree we need to fix 
it, and it seems fairly likely adjusted rules for forming paths and 
storing archetype markers in data will be needed.


But... the archetype structure mentioned is a hack for getting around 
the lack of order-tracking attributes in the RM. We've had a look at 
this before (e.g. here 
) 
but I would suggest we need to think soon about additions to the ENTRY 
class or package to properly model requester and receiver meta-data.


- thomas

On 19/10/2018 09:56, Sebastian Garde wrote:


Hi all,

We have encountered an interesting issue with how to construct unique 
paths for slots when there is more than one slot on the same level, 
and both slots are filled with the same archetype.


In this case, the resulting paths for both seem to be the same in OPT 
and thus in the data. (The at/id code of the slot are not part of the 
path for a filled slot.)


Likewise, you cannot apply an annotation to only one of them, because 
they share the same path.


This seems to be a general problem, but let me explain it in more 
detail using a concrete example:


The problem manifests itself for example when you start using the 
Service Request Archetype in CKM 
(https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).


In the archetype’s protocol (see screenshot below), there are various 
slots, most importantly let’s look at the _Requester_ and the 
_Receiver_ Slot.


In a template (see 2^nd screenshot), both slots can be filled with the 
same archetype, technically, and it also seems reasonable from a 
content point of view to use the same archetype for both slots.


The problem is that this means that the paths are no longer unique – 
there is no way to differentiate between the Requester and Receiver 
information anymore as far as we can see in the OPT, and consequently 
in the data.


Also, if annotations are used on a path like this, these annotations 
would automatically be applied to both Requester and Receiver.


For example, the path for BOTH the Requester and Receiver, once filled 
with a service_request_information CLUSTER archetype is:


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

Is anybody already using this archetype (or a similar one) in their 
systems and is encountering this issue? Is anybody using workarounds 
for this?


One way this issue could be avoided/dodged is if the archetype wraps 
these slots in additional clusters, so that the resulting path is 
unique even if the same archetype is used inside slots on the same level.


It seems perfectly reasonable to me to construct archetypes the way 
this one has been constructed, but I am not sure if the implications 
are clear.


Is this something the SEC needs to have a look at if this is something 
that needs to be addressed somehow…or are we simply missing something?


Maybe at0141 for Requester / at0142 for Receiver need to be included 
in the path somehow (even if it is ugly)…




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

Re: AQL on versioned compositions

[Thomas Beale]

On 02/11/2018 00:00, Heather Leslie wrote:


Hi Dileep,

From a clinician/modeller’s point of view, each of the consultations 
or visits that you describe as screening, consult encounter, revisit 
encounters are discrete events and need to be recorded using a 
separate event COMPOSITION. Each clinical consult will be recorded 
independently including identifying the changes from visit to visit. 
As part of a consult a diagnosis may be marked as resolved and that 
should be included as part of the consult record.




yep, this is the way it should be in openEHR, and logically in any EHR. 
If you don't do it like this, the data probably won't make sense to 
other openEHR software, applications etc.


This information needs to be recorded once for medicolegal purposes 
and sensible querying. Similar data that needs both event based 
recording and sensible updated representation in summaries or 
persistent lists include medications, problem/diagnosis, 
immunisations, adverse reactions, social history, tobacco/alcohol 
summaries etc.


The question of where that data should be actually 1) stored vs 2) 
copied and displayed vs 3)displayed as the result of a query or 
4) is not implemented 
consistently as far as I understand. Implementers please correct me if 
you have documented consensus.


For medicolegal purposes the consult record needs to be able to be 
accurately displayed and reintegrated on request, even if the 
component data is stored in a mix of event and persistent COMPOSITIONS.




also correct.

I would think that you would also need to be able to keep a 
representation of the health summary, also primarily for medicolegal 
purposes, so that it could be determined precisely what the clinician 
viewed in that summary as they made a critical clinical decision, 
especially if it were to result in a bad outcome. That is one of the 
key reasons for the versioned persistent compositions.


And that will not prevent the patient summary being the last known 
status of the person – totally agree with your intent there. It’s just 
a question of how to be able to demonstrate what was the summary on a 
certain data, at a certain time.




You might consider the 'health summary' a 'document' of some sort, and 
you /could/ take the line that you are maintaining and updating just 
that summary rather than the constituent data. In that case, you could 
treat the summary as a persistent Composition and add versions to it as 
you say, but now your patient EHR doesn't contain any clinical event 
data, only the data of a manually pre-built summary of those events.


Generally it's much more useful to record the event Compositions and 
just compute the summary. This can be easily facilitated by use of 
Folders that represent episodes, in a fashion already done by some of 
the vendors (at least DIPS and Code24). There is a new change to the 
FOLDER type <https://openehr.atlassian.net/browse/SPECRM-56> in the RM 
that facilitates adding more data - this will appear in the next RM 
release, very soon.


hope this helps.

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

Re: AQL on versioned compositions

[Thomas Beale]

Dileep,

If you are querying the EHR (or demographics) repository for older 
versions, the usual way to understand this concept is similar to in e.g. 
Github or other DVCS systems, which is: you are stating a time-point in 
system time and you want to see the data versions that were current then.


AQL has the TIMEWINDOW clause to implement this 
<https://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_timewindow>. 
I don't know how widely this is implemented.


In addition, the EHR REST API 
<https://www.openehr.org/releases/ITS/latest/docs/ehr.html#directory-directory-get> 
allows access to the EHR directory (FOLDER structure) at given versions.


- thomas

On 30/10/2018 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 <http://healthelife.in/> e: dil...@healthelife.in 
<mailto:dil...@healthelife.in>




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


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: e-health services landscape - initial proposal, open forum

[Thomas Beale]

A revised version of the services landscape is now available here 
.


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

Re: e-health services landscape - initial proposal, open forum

[Thomas Beale]

As mentioned elsewhere, while I completely agree on the lifestyle / 
sports / wellness needs in the wider e-health context, at the moment I 
am not sure if special SOA services are needed or not, since these kinds 
of data can be committed to the EHR using the generic EHR service, just 
as for any other kind of data - it's just different archetypes. It may 
be that special services for e.g. performance tracking or whatever are 
needed, but for now I'm assuming all that stuff is done by applications, 
not services.


- thomas


On 23/10/2018 22:10, Bert Verhees wrote:



I miss lifestyle and sport-services which are not explicitly problem 
related. Maybe others have other suggestions, but I like to focus on 
these. I think that is the near future, and not already planning them 
in will be a missed chance. The meaning of the term Healthcare will 
change to its true meaning. Care related to Health, not only illness. 
Lifestyle data will be important, already now insurance companies are 
registering if customers smoke or do sport, and which sport. Some 
people write down everything they eat.


People use their smartphone to communicate and exchange information. 
Interestingly, an increasing number of people collect health data on 
their smartphone such as information about their mood, activity 
level, nutrition or vital signs including blood pressure or blood 
glucose levels. Medical research could greatly benefit from these 
‘real life’ data. I think OpenEhr must be prepared for this to come, 
give it room, embrace it.


The same counts for archetypes, there are no archetypes on CKM which 
are fit to register these kind of things.


I had this discussion already a few times on OpenEhr mailinglists, I 
only got laughters as reply, that is why I hesitate to discuss it 
here, but with this, I give it one more chance, just for fun, not 
expecting any serious result.




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

e-health services landscape - initial proposal, open forum

[Thomas Beale]

Every so often I get bored of what I am doing and start trying to draw 
one of those 'services roadmap' kind of diagrams. These often pretty 
pictures appear in slide presentations, in standards, whitepapers etc, 
but are not often used as a tool to help map out the road ahead. We do 
however need some sort of vision of the future for staking out new 
services. I like my latest version enough that I thought it would be 
worth putting up publicly to get reactions and input.


Please comment and/or add content to the wiki page 
.




- thomas

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

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

[Thomas Beale]

I'm becoming convinced that we need to make a technical change to allow 
the slot id be stored in the data, as suggested on the discussion thread 
already.


So my suggestion for modellers is: assume it will get solved, and do 
your modelling in the natural / preferred way (i.e. don't introduce 
hacks like extra CLUSTERs), and we'll work out an ADL-level solution.


It would help if you can add any detailed info to the description of the 
PR that Sebastian just created 
.


- thomas



On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:


Hi all! I hope the SEC will discuss and hopefully solve this issue in 
the upcoming meeting in Oslo. This is fairly serious from a modelling 
POV, as there are some archetypes that are based on the (in my opinion 
fair) assumption that it’s possible to tell two instances of the same 
CLUSTER in two parallel SLOTs apart. An example is “Communication 
capability” https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. 
We’d prefer not having to change the modelling to circumvent the 
technical issue, if possible. 


Regards,

*Silje*



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

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

[Thomas Beale]

On 23/10/2018 10:09, Sebastian Garde wrote:


So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.


I am not fussed whether it is prepended or appended, I can see tiny 
advantages for both.


The more interesting question to me is whether this is optional and 
only added when really needed or required.


There is this edge case, but I also wonder if a reasonable query on 
data would be to ask for anything inside a specific slot, no matter 
what it is filled with (as e.g. mandated by Template A vs Template B). 
This does not really seem to be (generally) possible - even if there 
are not two identical archetypes in different slots?




that would also require adding the slot node id, but I wonder how useful 
this particular query really could be... we never thought of it in 10 
years of using AQL AFAIK...


- thomas

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

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

[Thomas Beale]

I need to study this problem a bit more, but having read the posts here, 
I think the solution would potentially to allow the /optional addition/ 
of a '::at' appended to an archetype id at a root point. This means 
that all current systems and data remain valid. It is better if it is 
appended rather than prepended because it means the string id always 
starts with the archetype id (= the case today) and may have something 
on the end, and that would only be the case for this fairly rare use 
case. It would also be a fairly simple code upgrade to existing systems.


So I would agree with Diego's syntax below, but say that it is optional, 
and only required when needed, which appears to be this one edge case. 
If we can convince ourselves of this, this is a pretty easy change to 
the relevant template tools and also ADL2.


thoughts?

- thomas


On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management 
to be compatible with existing tooling, in our typical slot solving 
methodology (non-template mode) the original archetype slot node_id 
ends in the new object node_id. Information about which slot was 
solved in this node ended in a new attribute in the term definitions 
(we called that attribute 'DCM', but you get the idea). We modified 
the AOM model to have references to both current archetype and solved 
archetype in order to avoid node_id collisions in archetype definition 
time.



I think we have talked before about the need of splitting the 
archetype_node_id attribute into node_id / archetype_id, which I think 
would solve these problems. Another solution would be to include 
always the node id in the node id, even if you are using it to store 
the archetype_id, so paths would look like

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



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

SEC f2f meeting Oslo 5-7 Nov - agenda items welcome

[Thomas Beale]

TheopenEHR Specifications Editorial Committee (SEC) 
will 
be having a face to face meeting in Oslo, 5-7 Nov 2018, hosted courtesy 
ofDIPS . The agenda is 
beingput together here 
. 
Feel free to add items under 'Agenda Items'.


We will be aiming to complete new releases of the RM and BASE 
components, as well as a number of other burning issues.


- thomas

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

Re: AW: Seeking clarification regarding Assumed value

[Thomas Beale]

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


- t


On 09/10/2018 06:29, Sebastian Garde wrote:


Assumed value was a slick idea at the time, but I do agree with your 
sentiments now:


  * it is hardly or not at all processable,
  * where there is widespread consensus on something it may well be
assumed automatically by clinicians – but this is not because
someone put the assumed value in the archetype or not.
  * Elements where such consensus exists across professions/sectors
are probably rare anyway and universal consensus on an assumption
is hard to ascertain
  * challenges for UI
  * challenges for querying (assuming you even dare)
  * challenges for anybody to understand it, including the difference
to a default value (and what happens if there is both).

Not sure about the implications for dropping/deprecating this at this 
stage


Sebastian



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

Re: SHRINE for openEHR ?

[Thomas Beale]

There is not at the moment, although various people have been thnking 
about distributed AQL querying for some years now. THe interesting 
version is where server-side computation is used, which is more 
compliant with legislation that prohibits health data to flow out of 
systems to users with no care relationship.


We don't have a technical work-up of the solution for doing distributed 
queries yet (at least not a public one), so if you have technical 
proposals, we would be interested to see them.


- thomas


On 01/10/2018 08:54, Georg Fette wrote:

Hello,
Is there an equivalent to i2b2's SHRINE in the openEHR world ? SHRINE 
is a system that distributed an i2b2 query to a network of i2b2 
installations and aggregates the returned results.

Greetings
Georg



--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

[Thomas Beale]

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

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

[Thomas Beale]

It was added to the RM years ago to support quantities in lab results, 
which are sometimes of the form Y etc. If I had my time again, I 
would have moved the date/time types out a bit so they did not inherit 
this attribute. Usually it is Void.


- thomas



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

Re: DV_DURATION and magnitude_status?

[Thomas Beale]

Indeed it does, as may be verified with the ADL Workbench



On 24/09/2018 14:22, Ian McNicoll wrote:

Hi Diego,

Does DV_DURATION not inherit magnitude_status as a separate attribute 
from the RM?


https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042

Not sure it would work in archetyping constraint but in data it 
would/should just be


value: "P24H"
magnitude_status: "<"

Ian

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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
<mailto:ian.mcnic...@openehr.org>

Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 24 Sep 2018 at 17:08, Diego Boscá <mailto:yamp...@gmail.com>> wrote:


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



El lun., 24 sept. 2018 a las 17:39, Pieter Bos
(mailto:pieter@nedap.com>>) escribió:

Not sure if this is already in the RM version you use and not
sure if ADL 1.4 supports this, but can this be a DV_INTERVAL
of DV_DURATION?

Regards,

Pieter Bos

Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland"
mailto:silje.ljosland.ba...@nasjonalikt.no>>:

Hi,



I’ve got a use case where we need to represent a time duration
(of a symptom), which can be for example <24H or >3M. Is it
possible to represent this using the DV_DURATION data type,
like you can do with DV_QUANTITY and magnitude_status? If not,
what should we do?



Kind regards,
Silje Ljosland Bakke



Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no<http://arketyper.no/> / Twitter:
@arketyper_no<https://twitter.com/arketyper_no>



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

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



-- 


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

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

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

VeraTech for Health SL
+34 654604676 
www.veratech.es <http://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
<mailto: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
<mailto:openEHR-technical@lists.openehr.org>

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



____

formal openEHR guidelines, GDL, expressions, Task Planning: who will author them?

[Thomas Beale]

I've put up a wiki page with a draft of what a real world guideline 
<https://openehr.atlassian.net/wiki/spaces/spec/pages/344621059/openEHR+Expression+Language+EL> 
(for choosing breast cancer therapy, based on various input variables) 
might look like in the emerging openEHR Expression language 
<https://www.openehr.org/releases/BASE/latest/expression.html>.


The example on the page shows the guideline in two forms: the first is a 
more natural-language style syntax, and the second is something close to 
TypeScript, a web programming language.


We can make the Expression Language work in either style, very easily. 
The questions are:


 * what kind of professional will create these kinds of guidelines, and
   also rules inside archetypes
   
<https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_rules_section>?
 * what style of syntax is better to use?

It is early days for guideline and rule authoring, but it will certainly 
come. So it would be helpful to get some ideas from the community on 
this. You could reply here, or comment on the wiki page linked above.


thanks

- thomas beale


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

Re: MEDINFO 2019, Lyon, France.

[Thomas Beale]

l mailing list

openehr-clini...@lists.openehr.org 
<mailto:openehr-clini...@lists.openehr.org>


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

___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org 
<mailto:openehr-implement...@lists.openehr.org>

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



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


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

Re: Generic modeling and issues for querying

[Thomas Beale]

On 16/09/2018 10:15, Karsten Hilbert wrote:


Panels are like folders. Whether to define inhabitants
thereof by LOINC, by arbitrary instance links, or by other
means, is an implementation detail.


that is more or less the design concept of the current lab archetypes; I 
would just say that panels are not only a display concept, but also 
(usually) ordering-related. Regardless, any analyte can be displayed and 
queried on its own, in both the vanilla (generic) lab archetype model, 
or a variant that adds specific analyte specialisations as I have proposed.


openEHR data representation and querying are founded upon this 
fundamental principle - store how you like, query how you like.


- thomas

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

Re: Generic modeling and issues for querying

[Thomas Beale]

On 15/09/2018 22:45, Pablo Pazos wrote:
Thanks Thomas, that in fact seems to generate different nodeIDs for 
each analyte, thus avoids the querying issue.


right. The key is that it is done in specialisations - so the querying 
in the generic form based on the generic archetypes will still work, 
including with LOINC codes. I did not show how to include LOINC codes 
directly in the specialisations, but that could be done.




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.




that will be a short term state of affairs - the new Archie tool can 
read all these archetypes, but the UI is rough for now (but probably 
good enough for a techie like you ;)
Also, the soon-to-be-released Marand ADL-designer Mk2 will (I believe) 
have an ADL2 parser added at some stage, since it is AOM2 internally.


- thomas


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

Re: Generic modeling and issues for querying

[Thomas Beale]

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


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

Re: Identifying archetype nodes in AQL via terminology code

[Thomas Beale]

On 06/09/2018 09:46, Ian McNicoll wrote:

Hi Thomas,

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


under the covers, I don't see the point - the archetype codes are the 
only completely reliable codes in the system because they are 
definitional in their archetypes.


At the AQL level, as I say, I can imagine some sort of pre-processing, 
but it depends on unique binding as far as I can see.


So far I don't see the point, but you might have a good example which 
would help us think better about this question.


- thomas

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

Re: Identifying archetype nodes in AQL via terminology code

[Thomas Beale]

In openEHR as it stands now, the answer would be no, because the 
snomed-ct:263495000 code is just one binding to at0017. What is reliable 
in the data is the at0017 internal code.


In future, it is not out of the question that different types of OPTs 
would be generated that would treat bound terminology codes as if they 
were the structural ones, but this is probably a long way off. Some 
further ideas about this in the ADL2 spec 
<https://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_terminology_integration>, 
and also the OPT2 spec 
<https://www.openehr.org/releases/AM/latest/OPT2.html>.


It also might not be hard to preprocess AQL queries written like this 
into the standard form, but that would require that the code 
snomed-ct:263495000 be bound uniquely to at0017, and no other node code 
e.g. at0015. So doing this would require stricter binding rules than we 
currently have, and which I think are not semantically justifiable.


- thomas


On 06/09/2018 09:21, Georg Fette wrote:

Hello,
In AQL it is possible to constrain the value of a node to one of the 
codes that are allowed for that value (as specified in the respective 
archetype).
To find patients with gender (snomed-ct:248153007) male 
(snomed-ct:248153007) I could write something like this:


SELECT e FROMEHR e CONTAINSDEMOGRAPHICS d

WHERE d.items[at0017].value = 'snomed-ct:248153007'


Is it possible to identify the node of an archetype instead of its 
path parts (e.g. d.gender or d.items[at0017]) also with a terminology 
code, so the query would rather look like something like that:


SELECT e FROMEHR e CONTAINSDEMOGRAPHICS d

WHERE d.items['snomed-ct:263495000'].value = 'snomed-ct:248153007'


I am not very experienced with AQL so the queries are probably already 
syntactically wrong.

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Thomas Beale]

I continue to wonder what will happen when a cancer patient (perhaps in 
a moment of depression or disaffection with care) asks for the hard 
delete, gets better, then has a recurrence a few years later. What does 
the health system do when /all the notes are really gone/?


I think a better solution is to create a digital locked room when such 
EHRs are put, one-way encrypted with a giant key provided by the 
patient. Then when they have regrets, they can ask - nicely - for their 
record to come out of cold storage.


Another argument against total deletion is that a) the state has 
invested in helping sick patients and b) other citizens have a potential 
interest in health records belonging to those in the same major disease 
cohort, i.e. diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous 
deletions are certainly going to compromise research that looks at 
longitudinal Dx v treatments v outcomes. Perhaps perhaps permanent 
anonymisation is a better solution in this case, with the original 
patient being given the new EHR id.


I think GDPR has some way to go yet in healthcare...

- thomas


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


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

Re: Recommended versioning strategy for Templates

[Thomas Beale]

Dileep,

the Archetype Identification specification 
<https://www.openehr.org/releases/AM/latest/Identification.html> may 
provide some answers. It undoubtedly needs further development in this area.


- thomas


On 01/09/2018 15:04, Dileep V S wrote:

Hi,

As an EHR solution evolves, the templates also tend to evolve to an 
acceptable level, especially since the archetypes themselves are 
evolving. However, all the data recorded using different versions of 
the OPT should remain consistently and easily query-able with out the 
AQL becoming overly complex and difficult to manage.


So is there any best practices in versioning the templates as they 
evolve so that the incremental evolution does not break the AQLs. The 
question is do we use the OPT filename(visually identifiable), Name 
filed in template properties or any of the fields in authorship 
metadata for indicating the template version?


Secondly, is there any template best practices document?




--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Thomas Beale]

That would be the case if only the AQL spec were used for conformance 
testing. But conformance also relies on the RM, ADL and other specs, as 
you can see here 
<https://www.openehr.org/releases/CNF/latest/docs/openehr_platform_conformance/openehr_platform_conformance.html>. 
If you go to 6.2.2 and down to 'Directory Operations', you can see 
conformance tests for Folders. The first step is to make sure all 
systems implement just the basic structure the same way.


The worst case right now would be that a query that mentioned some 
FOLDER structure was run in Marand, DIPS, Code24, EtherCIS, EhrServer 
etc, with different results. This is partly because we have not agreed 
on how to use Folders (e.g. mark them in a certain way to represent an 
episode etc), and partly because some systems don't use them at all. 
Even systems that do have Folders may not use them in the same way (we 
know this is true). So Folder is a slight black hole in openEHR which we 
are actively working on in the SEC to tighten up, so that every 
implementation uses them in the same way.


The Querying conformance table 
<https://www.openehr.org/releases/CNF/latest/docs/openehr_platform_conformance/openehr_platform_conformance.html#_querying_component> 
also needs to be augmented to include Queries that reference Folders. A 
bit more work is needed to get all of this in place.


- thomas


On 21/08/2018 18:28, Birger Haarbrandt wrote:

Hi Thomas,

from my perspective, this approach (by not being explicit about the RM 
classes (and semantics) that need to be supported by the Contains 
keyword) led to a situation in which two vendors (Marand and DIPS) can 
claim that they have a valid implementation of openEHR but are not 
compatible. I can't even tell if Marand (not support Folders at all) 
or DIPS (using questionable overloading of the semantics) is more 
right or wrong with their approaches on this matter...


Birger




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

Re: AQL on specific list of compositions

[Thomas Beale]

Karsten,

Out of interest, is there a diagram or other GNUmed documentation / 
explanation of all this. It's pretty close to what I think openEHR is or 
should be doing; you have formalised more of this than we have so far, 
so it's good to have some reference points available.


- thomas


On 20/08/2018 10:28, Karsten Hilbert wrote:

On Mon, Aug 20, 2018 at 10:04:45AM +0100, Thomas Beale wrote:


Some of these Contsys definitions are problematic:

ENCOUNTER

But there is an encounter when the HcP interacts with the EHR without a
Patient (Virtually) present.

that would certainly be a subversion of the usual meaning of 'encounter'
(literally 'to meet') in English and all the latin languages at least... (in
Portuguese and Brazil health system, the word is 'atendimento', i.e.
attendance... - probably the same in Italian and Spanish).

It would be better ontologically to call such an event something else - in
openEHR it is a commit of a Contribution.

I agree. In GNUmed we tend to think of this as a "session",
in quite a technical sense, between the technical system and
_a_ ("one"-party, where one is by purpose, not by number) actor.

So, a tumor board meeting is a session, as long as the
patient (or a non-staff guarantor) is not present.

Perhaps it's the difference between ABOUT the patient as
opposed to WITH the patient.

A session is the frame within which the commit of a
Contribution occurs.

An encounter does need a session (implicit or explicit) in
order to technically manifest itself. But a session does not
need an encounter.

Waters get muddy when patient and system are involved only,
due to information asymmetry: What if the patient interacts
with the system and the system is programmed to reinforce
adherence. Patient types into a "Question: ___" GUI
field: "Should I continue this medication ?" And the system
answers:

Generally, you should continue as previously decided.
However, if you see fit to rethink that decision would you
like to:

- leave as is
- revisit the previously documented decision details
- decide something else now
- contact a HcP now
- book an appointment


I would suggest that most people think an episode of care is not limited to
one HCP, and is not always limited to one health issue, even if there is
usually one main 'problem' on admission. An episode of care is usually
thought of as care to resolve an issue for a patient by a team of HCPs
working in an integrated environment, e.g. a hospital. If the resolution of
the issue requires care that crosses institutions (usually the case), then a
different term is probably needed for that.

In GP land it feels more helpful to think of Episodes of Care
to relate to one "issue", "problem" each. Several episodes -
about currently-thought-to-be-different issues can overlap.

In GNUmed we over-arch episodes of care with "health issues".
Each health issue can have several (non-overlapping) episodes
over time. Each issue can be thought of to have several
episodes (technically) going on at different institutions
concurrently.

Each problem manifests as a thread, an episode of care for
that problem, running through one or several encounters. Each
encounter can interweave several threads. Each problem may
become identified to belong to a particular health issue, an
underlying "cause".

IOW, episodes and encounters are orthogonal in nature.
Problems are the labels of episodes. Health issues are the
containers for potentially several episodes.

At least in GNUmed.

Karsten


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

Re: AQL on specific list of compositions

[Thomas Beale]

And I meant to say: can you check if it has a PR, and if not, add one? 
In either case, you or Seref might add the text from his proposal as well.


- thomas


On 21/08/2018 16:25, Sebastian Iancu wrote:


Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it 
we did not explored further on. Could this still be considered in 
these discussions?



Sebastian I.




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

Re: AQL on specific list of compositions

[Thomas Beale]

I had forgotten this, but I think it will turn out to be a syntax 
equivalent to Seref's proposal. It is probably the kind of syntax man 
people would like to use, so we should certainly consider it; it maybe 
that both mechanisms should be put in, and respective users can then 
argue over who is using 'syntactic sugar' ;)


- thomas

On 21/08/2018 16:25, Sebastian Iancu wrote:


Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it 
we did not explored further on. Could this still be considered in 
these discussions?



Sebastian I.




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

Re: AQL on specific list of compositions

[Thomas Beale]

Hi Birger,

Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec 
- they are just used in examples. AQL doesn't actually know anytthing 
about particular types. Seref's intention is that it stays this way, and 
his proposed function, or some other equivalent resolver mechanism would 
be a generic addition to AQL that would, for openEHR structures be used 
for FOLDERs containing refs to COMPOSITIONs (actually 
VERSIONED_COMPOSITIONs), and also any other similar situation (e.g. in 
the demographic model).


- thomas


On 21/08/2018 15:52, Birger Haarbrandt wrote:

Hi Seref,

while I understand your argument regarding overloading of definitions 
(and I agree with your reasoning), I see a clear need to not treat 
folders as second class citizens in openEHR. Not including Folders in 
the official AQL spec and leaving this to vendor-dependent functions 
will not be helpful to allow portability. Especially, as the use of 
folders (especially when it can contain data in an ITEM_STRUCTURE) is 
becoming a common pattern to represent episodes of care.


Cheers,

--



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

Re: Strange behavior in Template designer 2.8.94 Beta

[Thomas Beale]

It's AOM2.x inside, but deals with ADL 1.4 and .oet files externally. 
It's now more or less BMM-driven I think. But also they made some 
compromises to make sure all the ADL 1.4 and .oet stuff works the way it 
did.


Archie is completely ADL/AOM2 of course. It may be that in the future 
they could use the Archie core, which I suspect is cleaner code, for the 
core of ADL-designer, but for now the main priority for that tool is to 
be a good replacement for the Archetype Editor + Template Designer, not 
to be mainly an ADL2 tool.


- thomas


On 20/08/2018 13:48, Pieter Bos wrote:

Has that been changed? Last time I checked and asked Marand it was ADL 1.4 
only. Or is it AOM 2.x but ADL 1.4?

Regards,

Pieter Bos

From: openEHR-technical  on behalf of 
Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Monday, 20 August 2018 at 13:04
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Strange behavior in Template designer 2.8.94 Beta


The new tool is AOM 2.x inside, but I have to admit I have not investigated how 
this particular problem is resolved in it.

- thomas

On 20/08/2018 11:42, Peter Gummer wrote:
Hi Hildi,


On 20 Aug 2018, at 19:13, Hildegard McNicoll 
mailto:hi...@freshehr.com>> wrote:

Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
have this problem anymore. As far as I know it is very close to being released 
now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

Peter


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


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Thomas Beale]

The new tool is AOM 2.x inside, but I have to admit I have not 
investigated how this particular problem is resolved in it.


- thomas


On 20/08/2018 11:42, Peter Gummer wrote:

Hi Hildi,

On 20 Aug 2018, at 19:13, Hildegard McNicoll > wrote:


Incidentally, the new web based ADL Designer tool developed by Marand 
doesn't have this problem anymore. As far as I know it is very close 
to being released now.



I’m curious — from a purely academic perspective, now, since 
unfortunately I’ve not been able to participate in the openEHR 
revolution for the last couple of years — how this new tool is able to 
do that. Does this require migrating to ADL 2.0? As I recall (and it 
could be my memory at fault here) this was a limitation of ADL 1.4, 
rather than of the Ocean Template Designer itself.


Peter


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

Re: AQL on specific list of compositions

[Thomas Beale]

that would be possible if we modify the meaning of the CONTAINS operator 
to mean contains-by-value (like ENTRYs inside a COMPOSITION) /or 
/contains-by-reference, which is the FOLDERs case - as you have long 
argued ;)


Not hard technically as far as I can see - but it does mean a 
modification to all existing AQL implementations, and of course AQL itself.


- thomas

On 20/08/2018 10:21, Ian McNicoll wrote:

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

I still want to do

Select c FROM EHR Contains folder x contains composition c

since logically folder x contains compositions.

Ian


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

Re: AQL on specific list of compositions

[Thomas Beale]

Well if you have access to a Folder, you don't need to do an AQL query, 
you can just retrieve the Folder structure and recurse through it, 
picking up direct refs to VERSIONED_COMPOSITIONs.


Creating Folders from the data on the other hand requires writing some 
queries that look for admissions and discharges, matching them up, and 
generating a Folder for each pair, named after the institution and/or 
dates of the stay.  A bit messy, but not hard to do, if one wants to 
post hoc add Folders to 'old' EHRs that never had them.


- thomas


On 20/08/2018 10:07, Ian McNicoll wrote:

Thanks Thomas,

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


How would/should we do...

Select all compositions referenced by Folder x.



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