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

[Anastasiou A .]

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
Subject: Syntax for including archetypes in SLOTs, regardless of version

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 / Twitter: 
@arketyper_no

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

RE: Archetype pattern

[Anastasiou A .]

Just to note, we do not disagree here. My main point is that for someone to 
make use of all this "machinery" we are referring to here, they first have to 
be aware of it.

I am keeping an eye on this discussion with great interest.

All the best
Athanasios Anastasiou




From: Bert Verhees [mailto:bert.verh...@rosa.nl] 
Sent: 16 February 2018 13:04
To: Anastasiou A.
Cc: openehr-technical@lists.openehr.org
Subject: Re: Archetype pattern

Dear Athanasios,

A pattern must be imposed so strongly to an archetype, that even a clinician 
cannot escape them. That is the idea. Conforming to SNOMED may not be the best 
idea, but it is not a bad idea. It is a restriction which impose connections 
and hierarchy and still allows a user needed level of granularity

Bert


On 16-02-18 10:24, Anastasiou A. wrote:
Hello Bert and all
 
Thank you for your reply, please see below:
 
> every path unpredictable if there is no pattern used, so you can find many 
> examples of your own
 
Alright, sounds like a pattern by itself :) I cannot say this brings an obvious 
example to mind.
This unpredictability though might be due to another reason (please see below).
 
> So clinicians and technicians create different archetypes, how about the 
> medical informatics specialists, how about other cultures, how about people 
> in between?
> I am sure that every person creates different archetypes, especially when you 
> look at the small details which are so important when querying.
> ...
> A similar kind of semantic pattern is also in SNOMED but then tailored to the 
> clinical world.
 
I think that this goes right to "the heart of the problem" and the keyword here 
is "Culture", or maybe even isolated cultures.
Even people from the same discipline cannot get to communicate sometimes. 
 
SNOMED and openEHR were not developed together. When you develop a model you 
have an objective in mind. The model is built to be able to answer a specific 
question (or range of questions). SNOMED is built with a different set of 
specifications and its granularity does not have to conform to anything other 
than its specifications.
 
So, you either try to make best use of both "tools" in isolation or, you stand 
back and think about integrating them (but again with a specific objective in 
mind).
 
In either case, I think that anyone who wants to start working in this domain 
needs to have a basic understanding of a few things (e.g. What is this thing 
called a "Data Model", what does the process look like, what is object 
orientation, what is abstraction, what constitutes an entity, what constitutes 
an attribute, what constitutes a relationship, what types of relationships are 
there and what do they mean in context and many other "basics".) as well as 
other models they are going to have to work with.
 
Otherwise, you get those "unpredictable results".
 
My experience has been that before you get people "excited" and engaged with 
this type of work, they first have to understand what it is and what is the 
value it brings to THEIR work. 
 
Most of the times, if you mention "Data Modelling" to someone from a health 
related environment (whether research or clinical), they immediately think 
numerical models. 
 
Finite modelling, is not even on the map. Someone is more likely to have 
(simply) heard of the logistic equation as a model of growth rather than 
generalisation as a way of specialising an entity. And we are talking "simple 
marketing" here. Just to have heard the term, they don't have to know exactly 
what it is.
 
So, for this environment, Patterns are Science Fiction. If someone doesn't get 
abstraction, they will not "arrive" at patterns.
 
This creates a mismatch between the technical and clinical communities which 
can probably be lowered by educating each other. I am probably equally 
frustrated about all the different types of Blood Pressure as a clinician is 
with all the different types of data structures but both are necessary, we are 
not trying to waste each other's time. I too need to know what the domain looks 
like to understand the objectives that the models are trying to satisfy. I am 
not saying that the clinicians are "lacking", I am "lacking" too :D
 
All the best
Athanasios Anastasiou
 
 
 
 
From: Bert Verhees [mailto:bert.verh...@rosa.nl] 
Sent: 15 February 2018 16:29
To: Anastasiou A.
Subject: Re: Archetype pattern
 
On 15-02-18 16:52, Anastasiou A. wrote:
Hello Bert
 
I think that this is an interesting topic from a number of aspects.
 
Can I please ask what do you mean by "clinicians create archetypes with 
unpredictable paths"? Can you provide one or two examples?
Hi Athanasios, in fact is every path unpredictable if there is no pattern used, 
so you can find many examples of your own.
I think the EHR-classes in the RM is too coar

RE: Archetype pattern

[Anastasiou A .]

Hello Bert and all



Thank you for your reply, please see below:



> every path unpredictable if there is no pattern used, so you can find many 
> examples of your own



Alright, sounds like a pattern by itself :) I cannot say this brings an obvious 
example to mind.

This unpredictability though might be due to another reason (please see below).



> So clinicians and technicians create different archetypes, how about the 
> medical informatics specialists, how about other cultures, how about people 
> in between?

> I am sure that every person creates different archetypes, especially when you 
> look at the small details which are so important when querying.

> ...

> A similar kind of semantic pattern is also in SNOMED but then tailored to the 
> clinical world.



I think that this goes right to "the heart of the problem" and the keyword here 
is "Culture", or maybe even isolated cultures.

Even people from the same discipline cannot get to communicate sometimes.



SNOMED and openEHR were not developed together. When you develop a model you 
have an objective in mind. The model is built to be able to answer a specific 
question (or range of questions). SNOMED is built with a different set of 
specifications and its granularity does not have to conform to anything other 
than its specifications.



So, you either try to make best use of both "tools" in isolation or, you stand 
back and think about integrating them (but again with a specific objective in 
mind).



In either case, I think that anyone who wants to start working in this domain 
needs to have a basic understanding of a few things (e.g. What is this thing 
called a "Data Model", what does the process look like, what is object 
orientation, what is abstraction, what constitutes an entity, what constitutes 
an attribute, what constitutes a relationship, what types of relationships are 
there and what do they mean in context and many other "basics".) as well as 
other models they are going to have to work with.



Otherwise, you get those "unpredictable results".



My experience has been that before you get people "excited" and engaged with 
this type of work, they first have to understand what it is and what is the 
value it brings to THEIR work.



Most of the times, if you mention "Data Modelling" to someone from a health 
related environment (whether research or clinical), they immediately think 
numerical models.



Finite modelling, is not even on the map. Someone is more likely to have 
(simply) heard of the logistic equation as a model of growth rather than 
generalisation as a way of specialising an entity. And we are talking "simple 
marketing" here. Just to have heard the term, they don't have to know exactly 
what it is.



So, for this environment, Patterns are Science Fiction. If someone doesn't get 
abstraction, they will not "arrive" at patterns.



This creates a mismatch between the technical and clinical communities which 
can probably be lowered by educating each other. I am probably equally 
frustrated about all the different types of Blood Pressure as a clinician is 
with all the different types of data structures but both are necessary, we are 
not trying to waste each other's time. I too need to know what the domain looks 
like to understand the objectives that the models are trying to satisfy. I am 
not saying that the clinicians are "lacking", I am "lacking" too :D



All the best

Athanasios Anastasiou









From: Bert Verhees [mailto:bert.verh...@rosa.nl]

Sent: 15 February 2018 16:29

To: Anastasiou A.

Subject: Re: Archetype pattern



On 15-02-18 16:52, Anastasiou A. wrote:

Hello Bert



I think that this is an interesting topic from a number of aspects.



Can I please ask what do you mean by "clinicians create archetypes with 
unpredictable paths"? Can you provide one or two examples?

Hi Athanasios, in fact is every path unpredictable if there is no pattern used, 
so you can find many examples of your own.

I think the EHR-classes in the RM is too coarse grained to guarantee 
predictable pattern. We can also see that in the WIKI from Heather Leslie.



I quote: "It has been observed on many occasions that even with identical 
clinical requirements, a clinical modeller and a technical modeller will build 
quite different archetypes. Which archetype best represents the data recording 
requirements? In most cases it will be the clinical modeller's attempt which is 
more useful, although technical input will be required to ensure it will be 
implementable."



So clinicians and technicians create different archetypes, how about the 
medical informatics specialists, how about other cultures, how about people in 
between?

I am sure that every person creates different archetypes, especially when you 
look at the small 

RE: Archetype pattern

[Anastasiou A .]

Hello Bert

I think that this is an interesting topic from a number of aspects.

Can I please ask what do you mean by "clinicians create archetypes with 
unpredictable paths"? Can you provide one or two examples?

Also about the "something, that is: PATTERN", David Hay has written an 
excellent book "Data Model Patterns: Conventions of Thought", which 
although old (by now), is very well structured. A partial listing of its table 
of contents so that you get what I am trying to say here:
The enterprise and its world
Things of the enterprise
Procedures and Activities
Contracts
Accounting
The Laboratory
Material Requirements and Planning
Process Manufacturing
Documents

The "The enterprise and its world" section outlines basically every "system 
user" database, I dare say, ever.

Are you thinking about taking a look at the healthcare environment and then 
coming up with openEHR patterns that can commonly address each?

I think that this could be done even automatically, given the existence of 
enough archetypes / templates and the fact that they are machine readable with 
enough semantics to infer commonalities and structure.

All the best
Athanasios Anastasiou



-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: 15 February 2018 15:41
To: For openEHR technical discussions
Subject: Archetype pattern

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she also 
concludes that clinicians are better modelers then technicians.

Well, that depends, of course it is very important to have domain-knowledge 
when modeling data, and clinicians have the best domain-knowledge. So from that 
point of view, she is right.

But what we have seen until now is that clinicians create archetypes with 
unpredictable paths. And that is bad, because it makes it very difficult to 
find data and it makes it easy to miss important data, because some data were 
on a path where one did not expect them.

OpenEhr works fine to find data which are on a known or predictable path, but 
what if data are on an unknown path?

Let me explain by comparing this to a classical relational health-application. 
There are similarities.

I have seen classical relational systems which experienced a wild-grow in 
number of tables, I have seen once in a prestigious university-hospital where 
they had a grown of 7000 tables in 20 years, more then one per day!! No one 
understood the meaning of all the tables and data, no one dared to use data he 
did not understand, many data were and still are redundant. Every new 
development in the ICT starts with designing new tables.

How can in such a situation a clinician research a persons medical record, even 
with the help of the current technical staff, this is often impossible. So, 
important information can get lost. Adding to this are software-updates which 
often cause a clean-up, and that clean-up is also done by people who do not 
always know what they clean up. People live long, and a medical problem they 
had 30 years ago can be important to find to solve a current problem. So old 
data, and understand them, and be able to find them, can be important.

This can also happen with archetypes. Every new development in a application 
can start with a new archetype, and at a moment there can be thousands. It is 
impossible for a clinician to search all possible paths for medical 
information, even with the help of the current technical staff this can be 
impossible.

The old data-hell situation will not be solved by OpenEhr if there is not 
something behind it. And that something, that is: PATTERN

It is not only a clinical thing to understand how pattern in paths are best 
modeled, it is in fact also a technical thing. Clinical knowledge is not 
stable, the thinking about clinical facts change all the time, what now is 
important is tomorrow maybe not. So the pattern need a technical, mathematical 
base, that, something like Codd-normalization, but of course then applicable to 
archetypes.

The Wiki from Heather Leslie is a good starting point for the design of pattern 
and stop the proliferation of paths.

I described an approach to solve this problem in a blog, one and a half year 
ago.

http://www.bertverhees.nl/openehr/medical-data-context/

I had some discussion about that, but many had problems against the use of 
SNOMED in this context. So, maybe read it and forget SNOMED ad find something 
else to structure the medical data.

Bert


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

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

RE: Blockchain

[Anastasiou A .]

I agree, I was referring to more use cases with the outlook of incorporating 
blockchain into the existing 
openEHR model. Not blockchain itself.

(The bit about interacting parties is the "maybe add it in the service model" 
(?))





-Original Message-
From: Bert Verhees [mailto:bert.verh...@rosa.nl] 
Sent: 13 November 2017 12:17
To: Anastasiou A.; For openEHR technical discussions
Subject: Re: Blockchain

Not very far from now (looking into the future, Scotty and Captain Kirk), 
health information will be a worldwide web.
Mayor players are diving into this trillion dollar business.

Health information will need to be accessible, and blockchain can be used to 
guard all interaction between systems.
You can find dozens of documents which handle about this.

In the Netherlands Nictiz is busy with it.

For example read this (sorry, only Dutch) 
https://www.nictiz.nl/SiteCollectionDocuments/Whitepapers/Blockchain_in_de_zorg.pdf

Summarizing:
- Blockchain is needed when interacting parties do not trust or know each other
- A trusted third party cannot be found or is not desirable
- Validity en transparency of transactions is important
- Stored or interchanged data are very important


On 13-11-17 13:02, Anastasiou A. wrote:
> Perhaps an optional Blockchain capability could be added in the service 
> model, at points where an
> "internal" system had to interface with one or more "external" systems.
>
> For example, you could provide access to a specific dataset and blockchain 
> calls that
> modify its state.
>
> This would then also require the extension of the service model for verifying 
> certain actions
> against the blockchain.
>
> Within the RM, there is the Feeder System Audit 
> (http://www.openehr.org/releases/RM/latest/docs/common/common.html#_feeder_system_audit)
>
> It's a new concept, still needs use cases about it I think.
>
> All the best
> Athanasios Anastasiou
>
>
>
>
>
>
>
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Bert Verhees
> Sent: 13 November 2017 11:47
> To: For openEHR technical discussions
> Subject: Blockchain
>
> How are the plans about blockchain for OpenEhr? Is there any plan to 
> incorporate it in the standard, or is it regarded as a technical implementers 
> business?
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

RE: Blockchain

[Anastasiou A .]

Perhaps an optional Blockchain capability could be added in the service model, 
at points where an 
"internal" system had to interface with one or more "external" systems.

For example, you could provide access to a specific dataset and blockchain 
calls that 
modify its state.

This would then also require the extension of the service model for verifying 
certain actions 
against the blockchain.

Within the RM, there is the Feeder System Audit 
(http://www.openehr.org/releases/RM/latest/docs/common/common.html#_feeder_system_audit)
 

It's a new concept, still needs use cases about it I think.

All the best
Athanasios Anastasiou







-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: 13 November 2017 11:47
To: For openEHR technical discussions
Subject: Blockchain

How are the plans about blockchain for OpenEhr? Is there any plan to 
incorporate it in the standard, or is it regarded as a technical implementers 
business?

Bert


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

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

RE: Random / Synthetic Data Generation over Templates

[Anastasiou A .]

Hello Ian

Yes, that is what I understood and these services would be very useful indeed.

A forward “model” for a 4 digit hexadecimal number could be something like K = 
“[0-9A-F] [0-9A-F] [0-9A-F] [0-9A-F]”.
K recognises things like “0F0F”, “”, etc. Using K in reverse would be to 
use the regular expression to generate (all the) strings that would match the 
model.

Similarly, a Template is a model that “matches” its data with constraints 
dictated by ADL and a reverse model would be a Template that is used to 
generate (all the) data that would conform with it. Of course, this can be done 
in a “typical” way, i.e. match the data type, or in a more realistic way by 
taking into account the condition (i.e. synthetic data).

All the best
Athanasios Anastasiou







From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: 18 April 2017 10:03
To: For openEHR technical discussions
Subject: Re: Random / Synthetic Data Generation over Templates

Hi Athanasios,

I'm not quite sure what you mean by 'reverse models'?

A couple of CDR vendors have implemented services that allow you to generate a 
dummy composition for any template that is registered with the CDR. That is 
nice but even nicer would be to have a service that allowed a dummy composition 
to be generated 'on-the-fly' from a submitted template, without leaving the 
template permanently on the CDR.

Ian

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

[https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
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 18 April 2017 at 07:43, Anastasiou A. 
mailto:a.anastas...@swansea.ac.uk>> wrote:
Hello Pablo and all

Thank you very much for the quick response. That’s not too far from what I had 
in mind.

Ian, were you asking about “reverse” models offered as a service?

All the best
Athanasios Anastasiou



From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Pablo Pazos
Sent: 14 April 2017 01:34
To: For openEHR technical discussions
Subject: Re: Random / Synthetic Data Generation over Templates

In my case i have that in my To Do list. I want to complete the services with 
an XML instance validator based on the OPT constraints, not just on the XSD. It 
will take some time to have a usable release.

On Thu, Apr 13, 2017 at 5:20 PM, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
Would there be any interest in making these services available if we could find 
some free uk hosting? I guess ideally we should post the template and get back 
a sample composition without any actual persistence of either.

On Thu, 13 Apr 2017 at 18:39, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
Yeah, LinkEHR can do that

Regards

El 13/4/2017 17:37, "Anastasiou A." 
mailto:a.anastas...@swansea.ac.uk>> escribió:
Hello everyone

I remember some time ago, there was a tool that given a detailed template 
description, it would populate it with random data taking
into account only knowledge about the datatype.

I vaguely remember Heather Leslie mentioningit but I may be wrong.

Is that functionality available from one of Ocean’s tools? (e.g. the Template 
Designer)

Is similar functionality available through other tools? (e.g. LinkEHR, other).

Looking forward to hearing from you
Athanasios Anastasiou



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

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



--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

RE: Random / Synthetic Data Generation over Templates

[Anastasiou A .]

Hello Pablo and all

Thank you very much for the quick response. That’s not too far from what I had 
in mind.

Ian, were you asking about “reverse” models offered as a service?

All the best
Athanasios Anastasiou



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: 14 April 2017 01:34
To: For openEHR technical discussions
Subject: Re: Random / Synthetic Data Generation over Templates

In my case i have that in my To Do list. I want to complete the services with 
an XML instance validator based on the OPT constraints, not just on the XSD. It 
will take some time to have a usable release.

On Thu, Apr 13, 2017 at 5:20 PM, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
Would there be any interest in making these services available if we could find 
some free uk hosting? I guess ideally we should post the template and get back 
a sample composition without any actual persistence of either.

On Thu, 13 Apr 2017 at 18:39, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
Yeah, LinkEHR can do that

Regards

El 13/4/2017 17:37, "Anastasiou A." 
mailto:a.anastas...@swansea.ac.uk>> escribió:
Hello everyone

I remember some time ago, there was a tool that given a detailed template 
description, it would populate it with random data taking
into account only knowledge about the datatype.

I vaguely remember Heather Leslie mentioningit but I may be wrong.

Is that functionality available from one of Ocean’s tools? (e.g. the Template 
Designer)

Is similar functionality available through other tools? (e.g. LinkEHR, other).

Looking forward to hearing from you
Athanasios Anastasiou



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

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



--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>


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

Random / Synthetic Data Generation over Templates

[Anastasiou A .]

Hello everyone

I remember some time ago, there was a tool that given a detailed template 
description, it would populate it with random data taking
into account only knowledge about the datatype.

I vaguely remember Heather Leslie mentioningit but I may be wrong.

Is that functionality available from one of Ocean's tools? (e.g. the Template 
Designer)

Is similar functionality available through other tools? (e.g. LinkEHR, other).

Looking forward to hearing from you
Athanasios Anastasiou


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

RE: inheritance of archetypes

[Anastasiou A .]

Imagine combining all of this with GDL 
(http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a specialised
version of a similar DSL to describe archetype / template aware GUIs.



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: 01 March 2017 09:15
To: openehr-technical@lists.openehr.org
Subject: Re: inheritance of archetypes




On 01/03/2017 09:03, Bert Verhees wrote:
Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be discussed 
separately.
I do that because in the other message, I describe a real problem which needs a 
solution, and this message is about thinking about a solution in the 
archetype-framework, which will takes for years to come (if it will come, maybe 
I am wrong in my proposal).
-
When talking about specializing. Specializing an archetype is nothing more then 
copying an archetype and add/change some constraints in them.

Only in older ADL 1.4 tools. In ADL2, specialisation is fully 
defined
 and implemented in the ADL Workbench, and more recently in the ADL-designer 
project. it works just like an OO 
programming language. There are dozens of examples in the test 
archteypes,
 and also in the CKM archetypes, which when they are read into ADL Workbench, 
are re-engineered into differential form.

This has been the case for over 5 years, with the implementation in ADL 
Workbench being available for around 4. (You can see the revision 
history
 of the AOM2 spec).

Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the parent-classes are 
read to understand the child class. There is no need to process all the 
sourcecode of the child-classes to adapt the changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. Easier to 
maintain code (and one definitely need a test framework).

Imagine that dreaded generic labtest archetype in the other message, I wrote 
today.
How convenient would maintainability become if specializations where really and 
life-inherited from parent archetypes?

Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and add the 
appropriate terminology binding?

Maybe we could, in case of lab-test, just created the child archetypes only in 
memory and on the fly, needing only a few keywords to describe the changes. We 
could take a look at hibernate for Java (or many other ORM-frameworks).
They do not deliver the classes needed for handling specific databases, they 
offer a framework to create/generate those classes.

One could argue that specializations are not always inherited like classes in 
programming languages. That is true. What I suggest here maybe limited to the 
cases where it is real inheritance.

Best regards
Bert Verhees

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

Re: Terminology bindings in openEHR

[ANASTASIOU A .]

Hello Eneimi

The Data Value entities hold information on which terminology a specific 
encoded term may be coming from to enforce further data validation.


What you describe in your question, involving FHIR, is what happens when 
you interact with a terminology server 
(https://en.wikipedia.org/wiki/Terminology_server).


openEHR itself does not specify the terminology server part (yet), which 
is what you would use if you wanted to lookup the codes that will then 
makeup your values.


The binding can be handled in a number of ways. You could create your 
own simple lookup service based on the raw datasets of ICD, READ, 
SNOMED, LOINC and others as it was done in OSHIP 
(http://bazaar.launchpad.net/~higorpinto/oship/cr-ehr/view/head:/oship/src/oship/rxterms/createrxterms.py), 
use LexBIG (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2732233/) as it 
was done in opereffa 
(http://www.openehr.org/pt/news_events/releases.php?id=33) or CTS 
(http://clinfowiki.org/wiki/index.php/Common_Terminology_Services) as in 
the LinkEHR editor (http://linkehr.com/).


Hope this helps.

All the best
Athanasios Anastasiou
Lecturer in Health Data Science | Darlithydd mewn Gwyddoniaeth Data Iechyd


Data Science Building (First Floor) | Yr Adeilad Gwyddor Data (Llawr Cyntaf)
Swansea University Medical School | Ysgol Feddygaeth Prifysgol
Singleton Park | Parc Singleton
SWANSEA SA2 8PP | ABERTAWE SA2 8PP
Wales, United Kingdom | Cymru, Y Deyrnas Unedig

Phone | Ffôn +44 (0) 1792 60 6292
Email | Ebost a.anastas...@swansea.ac.uk

On 03/05/2016 12:24, Eneimi Allwell-Brown wrote:

Hi,

Can I get  some insight into how terminology bindings work in openEHR,
or how they are supposed to work?

It appears openEHR supports multiple terminologies, in addition to its
own internal coding structure (at). I think there’s a whole
terminology service dedicated to this. But my confusion is how to
implement the feature.

In the Ocean Template designer as well as the Archetype editor, there
are features that allow us specify what terminology we want to use and
to ‘manually’ input the codes we want to represent. Some data elements
already have fixed ‘Valuesets’ (e.g. Regular, Irregular as Coded_text
values for the ‘Regular?’ element in the Pulse archetype).

When I use free online tools to create a FHIR resource for upload to a
FHIR repository, where ‘CodeableConcepts’ exist the form field has a
code/database lookup service to LOINC, SNOMED CT, internal FHIR codes
etc., so that as I enter the first three characters of the concept I
want the system presents a list of options which I can override if I
don’t find what I want. When I select the concept I want, the system
inputs the correct code as well as the URL of the source terminology
server.

I want to imagine openEHR supports this sort of ‘lookup’ to existing
terminologies, but how do I accomplish this? Otherwise how does it
handle terminology binding?

Thanks.


___
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

AQL ANTLR4-grammar

[ANASTASIOU A .]

Hello everyone

Please see further below regarding a few first steps towards "converting" 
Chunlan's .g files in combination with Eiffel's lexer files to ANTLR's syntax. 
My main motivation for doing this was to produce syntax diagrams for ADL and 
AQL but very early on I realized that there was no point writing just the EBNF 
because I could be deriving the ANTLR representation of the grammar and from 
that be able to produce a parser as well.

This was going well, until I realised that:

1) Certain definitions could be defined once and re-used in multiple places
2) Some definitions looked almost exactly the same but had different names 
depending where they were applied
3) Some definitions would become obsolete / would not be able to co-exist 
because of the way ANTLR expresses a grammar
4) Some definitions included conditional parsing with states and they were 
becoming a bit indecipherable for me
5) Meantime, ADL 2.0 came along

I have specific examples for the above in a document were I kept notes as I was 
going on which I intend to share. Part of it was also put at an earlier email 
to Thomas...but this was long time ago by now.

The problem is that right now I am "on the road" (and have been for a few weeks 
now), writing this just before I go into class at St. Andrews and cannot talk 
about this to the level of detail I would love to :D

However, the key messages emerging from my experience are these:

A) I would appreciate help from people who wrote the .g and Eiffel YACC files 
because these are not exactly documented. We need to know how some definitions 
came to existence and more importantly, if we have two definitions that are 
almost identical, which one do we keep?

B) !!!We need testing cases!!! for each definition. This became essential as I 
was going on and had to jump back and forth changing definitions. Of course, 
when you do that, it has an impact on every definition uses the modified part. 
My tool of preference was Python. The Python ANTLR target code generation was 
recently reworked and it works almost exactly as its JAVA counterpart. It could 
be used to create quick test code through a makefile or something.

C) I found it easier to work bottom-up. So, if we were to quickly get 
elementary data types / definitions out of the way relatively quickly then the 
real work can start on parts of the grammar that are not exactly 
straightforward :)


Repositories at:
A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax

Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf
 

I hope this helps, had a quick look at the MedInfo stuff and it looks really 
exciting!

All the best
Athanasios Anastasiou





From: openEHR-technical [openehr-technical-boun...@lists.openehr.org] on behalf 
of Thomas Beale [thomas.be...@oceaninformatics.com]
Sent: 03 July 2015 11:10
To: For openEHR technical discussions; For openEHR clinical discussions
Subject: Re: openEHR specifications - the future is Asciidoctor + MagicDraw?

Athanasios,

excellent suggestion. I haven't even looked at building in syntax diagrams 
right now, but your timing is perfect - I was contemplating how to put the ADL 
grammar into the new style spec in a nice way. Currently grammar is generated 
as an HTML page (as per links on this wiki 
page<https://openehr.atlassian.net/wiki/display/ADL/ADL+2+parser+resources>) 
which is ok, but the source file is not in a re-usable form (it's a .y file 
containing Eiffel code - but it would be the same problem with any language 
like Java or C etc) and the lexer files are also not re-usable or easily 
publishable.

So we need to solve this in a way that makes the lexer and parser grammar files 
primary, and then all other files based on them. All of this goes for AQL as 
well.

Both ADL and AQL grammars can undoubtedly be improved - there is not only one 
grammar for a language - so making changes for computability doesn't have to 
break the language definition. I suspect that if we can get some optimal 
grammars sorted out for Antlr, they will become the 'primary files' for these 
languages in the ecosystem. Shinji is also after the same thing, and I think 
has done some work on ADL grammar for Antlr.

So we need to do some work here, and your work looks like a good starting point.

As soon as we have a few more gremlins sorted out in the main toolchain, I'll 
get myself up to speed on your and Shinji's work here and hopefully we can 
create a solution which I think then really will make for a powerful 
models+documentation+programming toolchain.

- thomas

On 03/07/2015 10:56, ANASTASIOU A. wrote:
Hello Thomas

This is looking really good and much more usable and lite than shifting through 
PDFs.


Just a small suggestion / question.


Will it be possible to have (possibly automatically updated 

Re: openEHR specifications - the future is Asciidoctor + MagicDraw?

[ANASTASIOU A .]

Hello Thomas

This is looking really good and much more usable and lite than shifting 
through PDFs.



Just a small suggestion / question.


Will it be possible to have (possibly automatically updated from a 
single model) syntax diagrams for ADL / AQL?




A first step for AQL can be found at:
https://bitbucket.org/aanastasiou/openehr-aql-syntax

Some progress has also been made towards EBNF for ADL at:
https://github.com/aanastasiou/adl_ebnf

Both of these attempts to map the languages were made with the view of 
creating syntax diagrams which are immensely useful when trying to 
provide the bigger picture to people with minimal technical background.



The ADL EBNF hit some snags because of various differences in the 
definitions across different files but in general, it is a 
straightforward task.



Happy to join forces if something like this is already underway.


All the best
Athanasios Anastasiou

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

ADL 1.5 definitions

[ANASTASIOU A.]

Hello Thomas

Thanks for letting me know.

There's no problem in waiting for a couple of days for you to clean up
the ADL 1.5 definitions. In any case, this is not going to be a
'walk-in-the-park' :)

I did however try to take a different approach in the hope that it might
produce results more quickly. You can read all about it here:
https://github.com/aanastasiou/adl_ebnf

In essence, i remembered that Tim Cook's Python reference implementation
included the definition of a parser for ADL 1.4 through the (incredibly
useful but slightly slow) pyparsing package.

Pyparsing allows the definition of parsers using a very nice object
oriented interface and its definition reads almost like natural
language. So, going from that to an EBNF form is much easier than
reverse engineering the yacc-like files (to my eyes at least :) ).

So, in a nutshell, the plan would be to arrive at a valid definition of
ADL 1.4 and then augment it with those key parts that are different in
ADL 1.5.

The current set of EBNF definitions is not that big, so if anyone wants
to pitch in either by reviewing the current definitions or contributing
additional ones, please do so.

I hope that we can arrive at a good definition of ADL 1.5 in EBNF, it's
a great resource to have and it can be used for a number of things.

All the best
Athanasios Anastasiou





On 17/03/2014 19:07, Thomas Beale wrote:
> On 17/03/2014 16:31, ANASTASIOU A. wrote:
>> Hello Thomas
>>
>> Thank you for the quick response. I guess i am going to have to go
>> through the yacc style files and get the definitions...it's been
>> sometime since i last used that family of tools. I am primarily
>> interested in ADL 1.5, for the new way of handling slots and for
>> bringing in the "template" level of modelling.
>
> Athanasios,
>
> if you want to wait a couple of days, I'll clean the ADL 1.5 parser up
> to be pure, as I already had the idea to relegate the current mixed
> parser to 'ADL 1.5 transitional'.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.

ADL 1.5 definitions

[ANASTASIOU A.]

Hello Thomas

Thank you for the quick response. I guess i am going to have to go
through the yacc style files and get the definitions...it's been
sometime since i last used that family of tools. I am primarily
interested in ADL 1.5, for the new way of handling slots and for
bringing in the "template" level of modelling.

All the best
Athanasios Anastasiou






On 17/03/2014 10:25, Thomas Beale wrote:
>
> I've put up a new page on this here
> <http://www.openehr.org/wiki/display/spec/ADL+1.5+parser+resources>.
> Please note that there are a few legacy rules that you don't need to
> care about if you are doing pure 1.5. We'll make a pure version of these
> parser grammars at some point. The ones at this link are straight from
> the software, so they are always the 'latest' , and also implemented, so
> you can trust they work in at least one place.
>
> Re: AQL, our current approach is to do writes/updates via APIs,
> including things like SMART-flavoured APIs that are specific to the
> content, e.g. allergies list, medications list and so on. I think this
> approach is easier for app writers to deal with, and seems to be the way
> the world is going these days (think SMART/FHIR).
>
> - thomas
>
> On 17/03/2014 09:45, ANASTASIOU A. wrote:
>> Hello everyone
>>
>> Are there any resources that define the structure of ADL 1.5? As always,
>> BNF would be great but other files that could help in deriving BNF would
>> also be useful.
>>
>> Also, can i please ask if there are any plans to update the archetype
>> query language with the rest of the operations that could be carried out
>> over openEHR? At the moment, AQL supports data manipulation only and
>> specifically querying. What about other operations such as update /
>> insert / delete?)
>>
>> Looking forward to hearing from you
>> Athanasios Anastasiou
>> 
>> [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
>>
>>
>> This email and any files with it are confidential and intended solely
>> for the use of the recipient to whom it is addressed. If you are not
>> the intended recipient then copying, distribution or other use of the
>> information contained is strictly prohibited and you should not rely
>> on it. If you have received this email in error please let the sender
>> know immediately and delete it from your system(s). Internet emails
>> are not necessarily secure. While we take every care, Plymouth
>> University accepts no responsibility for viruses and it is your
>> responsibility to scan emails and their attachments. Plymouth
>> University does not accept responsibility for any changes made after
>> it was sent. Nothing in this email or its attachments constitutes an
>> order for goods or services unless accompanied by an official order form.
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.

ADL 1.5 definitions

[ANASTASIOU A.]

Hello everyone

Are there any resources that define the structure of ADL 1.5? As always,
BNF would be great but other files that could help in deriving BNF would
also be useful.

Also, can i please ask if there are any plans to update the archetype
query language with the rest of the operations that could be carried out
over openEHR? At the moment, AQL supports data manipulation only and
specifically querying. What about other operations such as update /
insert / delete?)

Looking forward to hearing from you
Athanasios Anastasiou

[http://www.plymouth.ac.uk/images/email_footer.gif]

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.