New openEHR Discourse site replacing mailing lists

[Thomas Beale]

eedback category called 
something like 'New Category Request: cat-grooming services for older 
felines' (well, ok, possibly something a little more domain-relevant). 
People who would like this category to be created can do a 'like' (the 
heart symbol). If you are in mailing list mode, a reply with the text 
'+1' will have the same effect. If we get reasonable interest, we will 
create the new category.



 Is there a site code of conduct?

There is. We all naturally expect a continuation of the many years of 
civilised and collegial discussion of the past. Here is the site code of 
conduct <https://discourse.openehr.org/faq> - please read!



   What's Next?

Many active discussions, we hope. We have set up the Discourse facility 
in a reasonable (we think) way in order to get going. If you think 
anything can be done better, please let us know in the Site Feedback 
category.


Over to you...


 Appreciation

We would like to acknowledge the time and effort of Dr Marcus Baw, UK, 
who was the prime mover for the move to Discourse, and who performed the 
site installation and configuration.


--
Thomas Beale
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

How to write Github commit messages to connect to openEHR Jira issues

[Thomas Beale]

We have been doing this for a few years now, but we have installed the 
new Jira connector for Github projects under openEHR. Here is a 
refresher on the instructions for writing commit messages if you are 
trying to connect to a Jira issue.


https://openehr.atlassian.net/plugins/servlet/ac/com.github.integration.production/github-post-install-page

- thomas



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

Re: Archie version 0.6.0 released

[Thomas Beale]

Once again excellent work from Pieter's team at Nedap!

On 12/02/2019 13:03, Pieter Bos wrote:


Today I’m pleased to announce another major release of the Archie 
library. This release brings a number of new features and improvements:


  * A tool that constructs valid json example instances of RM Objects,
based on an operational template. Can be parsed to RM Objects.
  * Native ODIN serialization of arbitrary java objects using the
Jackson library, now used in Archetype and P_BMM serialization
  * The library is now supported on Android, Android 8.0/API level 26
and higher, including faster initialization time
  * The RM implementation has been verified against the 1.0.4 BMM
models, and fixed where needed
  * A complete rewrite of the P_BMM implementation, with improved
validation. The new implementation is much easier to understand
and maintain

Because of the last two features, this version may require some 
changes to your existing code. For more information, see 
https://github.com/openEHR/archie/releases/tag/0.6.0 and the readme.


Regards,

Pieter Bos

Nedap Healthcare



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

Re: query writing question 2

[Thomas Beale]

seems to support something - search for 'identifiedEquality' in the 
grammar part of the AQL spec 
.



On 09/10/2018 11:40, Seref Arikan wrote:

Hi Tom,

I remember reading this somewhere. Can you remember if the current 
antlr grammar supports that embedded adl syntax?


Cheers
Seref



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

Re: API's

[Thomas Beale]

On 15/07/2018 20:52, Bert Verhees wrote:

On 15-07-18 11:19, Thomas Beale wrote:


Bert,

the addition of business-level transactional APIs, e.g for medication 
list, e-pharmacy, or other business level functions is certainly 
intended and envisaged. It's just not the first step.


Such APIs would convert relatively simple transactional concepts e.g. 
get_medication_list(), suspend_medication() etc to what may be 
non-trivial information structures defined by specific archetypes, 
which would be valuable for the reasons you say. Also: they improve 
data interoperability because complex structures (say, Care Plans) 
are guaranteed to always be the correct structure due to the API, 
whereas manual creation might end up with different variations.




I agree, thanks for your reply. What I would find interesting is that 
there would be an API-set, which is defined from good reasoning, how a 
specific API should look like. I found an example on the Internet from 
a Californian startup, which may be far from complete and maybe there 
is otherways much to improve, but they incorporate also Wellness and 
we don't see that a lot. But the final judgment I let that to people 
who studied for it.


https://hub.humanapi.co/docs/overview


I just had a look at this. It's pretty low-level. See Medications API 
<https://reference.humanapi.co/#medications> for example. It seems to be 
a competitor to FHIR in some way, since it is not using FHIR.


Anyway, there are two kinds of things we can do, both more advanced than 
this.


The first is to generate APIs from templates, in the same way we 
generate a TDS (Template Data Schema, which is an XSD) from a template. 
All we need to do to build a transformer, not hand-build APIs (that's 
last century thinking). This means we would have a way to generate an 
API from any template, i.e. any content. This kind of API is one way to 
get data out of a system.


The second interesting thing to do is to design transactional API models 
for things like 'Medication List' and 'Care Plan', which have a 
functional interface. In the first instance we could do this in UML 
(same approach as the current Abstract Platform Service model 
<https://www.openehr.org/releases/SM/latest/docs/openehr_platform/openehr_platform.html>) 
or IDL, and build a generator to output REST APIs. This style of API is 
functional and transactionally oriented, and is the basis of writing 
changes into the system.


If there are people interested in working on either of these, we can put 
together a working group (or two).


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

Re: Announcing Archie version 0.4

[Thomas Beale]

This is excellent work, and has proven to be a great test for the AM 
specifications <http://www.openehr.org/releases/AM/latest/docs/index>, 
helping me to find various errors. But the main interest is that we will 
be able to build new tools such as a Java/JS replacement for the ADL 
Workbench, and of course things like a high-quality, BMM-driven runtime 
archetype validating kernel for EHR systems, workflow implementations 
and many other components.


- thomas

On 31/01/2018 15:18, Pieter Bos wrote:

Hi,

We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.

Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.

It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.

We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.
Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.

Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.

Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.

Regards,

Pieter Bos
Nedap Healthcare
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org


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

Re: Announcelist

[Thomas Beale]

Hi Bert,

we are currently testing Discourse as a new mailing list / discussion 
system (thanks to Marcus Baw). Hopefully this will be done in the next 
few weeks, and if the archive conversion worked, we can convert to that 
system.  We'll certainly put at least one extra 'announce' list in as 
per that discussion, and of course, the community will have more freedom 
to create more lists - although having too many lists (as in HL7) can 
also be a problem.


- thomas


On 19/12/2017 12:12, Bert Verhees wrote:

Hi everybody,

In the beginning of the year we had the idea of having an announce 
list for implementers, hosted by the OpenEhr foundation.


The discussion starts here:

https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09912.html 



The occasion was that Pablo announced a new version of his Cloud 
EHRServer to this list. It was on Christmas day 2016.


That discussion starts here

https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09902.html 




Isn't that a nice date to do something good?


A few days later, Thomas came with the idea of having a community 
based announce-list.
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09911.html 



Then Ian came with the idea of becoming a member of the Industry 
partner group and in this way have more visibility for projects
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09910.html 



I see that there is an Individual Membership for only 15 Euro per 
year, which is a nice price for individuals.
But I don't see any way these Individual Membership can have some 
announcement visibility.


Maybe it is hidden somewhere per accident, or isn't it yet arranged?

Because it is one year ago, now, and it is almost Christmas again, 
wouldn't it be a nice occasion to arrange an announcement-list 
read/write accessable for some group of individuals for low cost, or 
even better, for free?


Thanks very much

Bert


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





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

Updates to UML, package paths; new global class index.

[Thomas Beale]

A few improvements for users and implementers of the specifications.

*class indexes*: I've improved the UML extractor that generates the UML 
diagrams and tables used in the specifications, to generate better class 
index lists, including a global one for the whole of openEHR 
<http://www.openehr.org/releases/BASE/latest/docs/global/index.html>. 
You can use these indexes to search for a class name in a normal 
browser; the link you find will drop you into the relevant class 
definition in the relevant specification. See highlighted links on the 
spec page below.


*package path corrections*: in doing this work, we found some 
inconsistent package structures. In some places, the component level 
(i.e. 'am', 'base' etc) was missing. I have corrected these. Mostly 
no-one will care, but one change was needed for AOM2 - the packages 
under org.openehr.am were called 'aom' etc rather than 'aom2', which is 
required to avoid clashes in class libraries that contain AOM 1.4 
implementation. For the latter, we just stick with 'aom' rather than 
'aom14', since this is historical.


This change can be ignored by nearly everyone, but if AOM2 implementers 
want to, they can rename their 'aom' packages to 'aom2', with minimal 
annoyance in most language development environments. Some of the UML 
diagram names were also changed to be consistent, which enables the 
converter to rely on fewer special directives. As a result, some deep 
URLs for diagrams have also changed.


The global UML site <http://www.openehr.org/releases/trunk/UML/> has 
been updated to include these changes.


The CR SPECPUB-6 <https://openehr.atlassian.net/browse/SPECPUB-6> 
documents this update.


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

Re: Versioning of archetypes: Minor or major changes?

[Thomas Beale]

thought possible, can make a receiving system’s validation
mechanism protest.

Thoughts?

Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

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

Tel. +47 40203298

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




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


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

Re: Mandatory elements in archetypes, and user interfaces

[Thomas Beale]

On 10/11/2017 11:21, Boštjan Lah wrote:

On 10 Nov 2017, at 14:19, Thomas Beale <thomas.be...@openehr.org> wrote:

you can't restrict from 1..1 => 0..* in a template - it's not allowed in any 
restriction algebra, of which ADL is an example.

If it is thought that no occurrnces constraint might be needed in any 
derivative archetype or template, the original parent should have 0..1 or 0..* 
as appropriate.

Yes, but I think making all archetypes generic like Gerard suggests is not a 
good idea.



I agree. Where there is a focal element that can't be null (in the 
programming sense) it should be 1..1 or 1..*; that's part of the 
semantic definition. Archetypes are about data; what goes on in the 
screen is more complicated sometimes. Particularly with pre-filled 
and/or defaulted fields.


- thomas

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

Re: Mandatory elements in archetypes, and user interfaces

[Thomas Beale]

Hi Silje,

On 10/11/2017 08:47, Bakke, Silje Ljosland wrote:


Crossposting this between the clinical and implementers lists, since 
it belongs in both:


In some archetypes, one or more elements are set as mandatory 
(typically occurrences 1..1 or 1..*), because the rest of the concept 
makes no sense without this particular element recorded. Examples are 
Problem/diagnosis name in Problem/diagnosis, and Temperature in Body 
temperature. This is not intended to mean that it’s mandatory to enter 
data into the element in a UI, but that this particular element is 
mandatory in any persisted composition that uses the archetype.




and that it should have a value, but the value may be derived by other 
means, e.g. a default value, or just set to 0 or other equivalent.


Recently however, we received a request to change the Head 
circumference element in the Head circumference archetype from 1..1 to 
0..1 because the element being mandatory in the archetype 
automatically made the UI form builder mandate the entering of data 
into the UI field, and removing the archetype on the fly made more 
unnecessary clicks.




I'm not sure I understand; what was the reason the head circumference 
should not have been visible on the form? A value doesn't have to be 
entered; the form can use default value or current value pre-fill.


In a fit of mental hiccups, I agreed with and performed this change, 
but have since realised this is wrong, because:


·A mandatory archetype element is not the same as a mandatory UI field

·A mandatory UI field is more like a field where you only allow 
persisting non /null/ values, while a mandatory archetype element can 
be persisted with a /null/ value without a problem.




well it depends on what you mean by a 'null' value; in mainstream 
programming languages, this means /no value/, i.e. nothing. This is not 
the same thing as an empty string or zero-valued number.


What does 'a mandatory UI field' mean? It could mean:

 * must be displayed and filled
 * must be displayed; will be prefilled in some way and may be
   optionally filled by the user


How are implementers actually handling this? Do you separate UI field 
mandation and archetype element mandation?


Kind regards,
*Silje Ljosland Bakke*

**




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

Re: Mandatory elements in archetypes, and user interfaces

[Thomas Beale]

On 10/11/2017 10:24, GF wrote:

Hi,

Even when elements make no sense when both are recorded, even then 
1..1 is a problem in Archetypes.
It is up to the implementer to decide to restrict 0..n further in the 
Template.


you can't restrict from 1..1 => 0..* in a template - it's not allowed in 
any restriction algebra, of which ADL is an example.


If it is thought that no occurrnces constraint might be needed in any 
derivative archetype or template, the original parent should have 0..1 
or 0..* as appropriate.


- thomas


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

Re: Versioning implementations

[Thomas Beale]

ovider (e.g. 
emergency) that also looks at version 12 (since that is the latest 
recorded one) and immediately after the consultation records a 
version 13. See the merge conflict? In this case it might need to be 
resolved by the care takers contacting each other to agree on 
possibly conflicting persciptions. What happens today without 
openEHRs ability to at least detect a merge conflict is not always 
good for patient safety.


Many openEHR implementations today are single-care provider systems 
and then you don't handle/detect the conflicts using the system, but 
hopefully some other way.


I agree that a distributed versioning could be specified as optional 
in some openEHR conformance profile for single-care provider systems, 
but it should certainly not be taken away from the openEHR 
specifications! This also means that the version identifiers used in 
the specs (e.g. 
8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider 
.org::12) should still contain the system id (e.g. 
ehr.examplecareprovider .org) even in single-care provider systems so 
that they can later be upgraded (or their possibly signed data can be 
moved) to a system capable of full distributed versioning.


Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
<mailto:erik.sundv...@regionostergotland.se> (previously lio.se 
<http://lio.se>) http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se 
<mailto:erik.sundv...@liu.se>, http://www.imt.liu.se/~erisu/ 
<http://www.imt.liu.se/%7Eerisu/>


On Mon, Aug 21, 2017 at 10:58 PM, Pablo Pazos 
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>> wrote:


I agree. The singleton is not one persistent compo, but the
instance associated with an OPT of a persistent compo. When
talking about singleton instances we should define what is
considered the "class" :) My mistake.

In the case of care plans, different care plans will be defined
by different OPTs, same for medication lists if needed and
modeled that way (some systems might only need one medication
list, one problem list, etc. by EHR).

But again, these are all clinical modeling decisions. A bad model
might represent different care plans with the same OPT, and of
course this breaks the singleton concept, but we are talking
about subjectiveness here, so there are no hard rules (call it
probabilistic singleton).


Best,
Pablo.


On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees
<bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote:

Pablo, one small remark, a persistent composition is not
really a singleton. Not conceptually. A patient can have more
care - plans, for example, at different care - institutions
or multiple care - takers at a single institution, or have
multiple medication-lists.

Bert


On ma 21 aug. 2017 19:24 Pablo Pazos
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>>
wrote:

Hi Bert, excellent questions!


On Aug 21, 2017 5:55 AM, "Thomas Beale"
<thomas.be...@openehr.org
<mailto:thomas.be...@openehr.org>> wrote:


On 21/08/2017 09:09, Bert Verhees wrote:

On 21-08-17 02 <tel:21-08-17%2002>:51, Pablo
Pazos wrote:

@Bert Persistent records are a well know
pattern in ehrs and it's usefulness should
not be under question. Of course systems that
focus on primary care might not implement
them. But for hospital or even regional /
national records need a wider view of the
patient, persistent shows their value.

Hi Pablo, two questions

Which problem do you solve with persistent
records which cannot be solved in another way? Do
you agree that persistent records are the only
reason to have branching/merging necessary?


well they are likely to be the most common element of
an EHR to which branches and merging would be
applied. However they are ubiquitous and are also
likely to be extended to things like care plans and
so on. But in principle, branch and merge could
happen to anything in the record, e.g. for reasons
like adding competing translations of clinical notes etc.

- thomas





Adding to Thomas, we can view this from three points of
view: technical implementation, clinical modeling, and

Re: Versioning implementations

[Thomas Beale]

On 21/08/2017 10:45, Bert Verhees wrote:

On 21-08-17 10:54, Thomas Beale wrote:



well they are likely to be the most common element of an EHR to which 
branches and merging would be applied. However they are ubiquitous 
and are also likely to be extended to things like care plans and so 
on. But in principle, branch and merge could happen to anything in 
the record, e.g. for reasons like adding competing translations of 
clinical notes etc.


It is true that care-plans for a single patient for a single case can 
be written by more care-takers simultaneously, but one could argue if 
they, in that case, belong in the same composition?
Wouldn't it be better to have more care-takers for one patient on a 
single case have their own compositions, and are grouped by folders 
outside the compositions?


well how a care plan is designed is up to clinical designers. The usual 
idea is to have an updatable, evolving plan (potentially for each major 
problem), shared across care providers.


- thomas


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

Re: Versioning implementations

[Thomas Beale]

On 21/08/2017 09:09, Bert Verhees wrote:

On 21-08-17 02:51, Pablo Pazos wrote:
@Bert Persistent records are a well know pattern in ehrs and it's 
usefulness should not be under question. Of course systems that focus 
on primary care might not implement them. But for hospital or even 
regional / national records need a wider view of the patient, 
persistent shows their value.

Hi Pablo, two questions

Which problem do you solve with persistent records which cannot be 
solved in another way? Do you agree that persistent records are the 
only reason to have branching/merging necessary?


well they are likely to be the most common element of an EHR to which 
branches and merging would be applied. However they are ubiquitous and 
are also likely to be extended to things like care plans and so on. But 
in principle, branch and merge could happen to anything in the record, 
e.g. for reasons like adding competing translations of clinical notes etc.


- thomas


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

Re: Versioning implementations

[Thomas Beale]

Naturally I am all for revising the specs (it's what we do ;) and 
throwing out dead stuff. But one thing I have realised over the years is 
that many of the scenarios (such as multi-system syncing) we thought of 
in the 1990s and early 200s are only just coming onto the radar now. 
Progress is much slower than many of us thought.


Consequently, some types of implementation experience gained so far - 
particularly anything cross-enterprise or regional - is not going to be 
an indicator to the future. Of course, some kinds of experience, say 
with using the RM, or ADL 1.4, AQL etc, has been giving us all the 
feedback that we needed to make the updates we are currently making to 
the specifications.


Probably what we should consider in this case is an update to the Change 
control spec that describes a variant or guideline for using the model 
to implement linear versioning, while allowing for later addition of 
branched versioning when/if needed.


- thomas


On 18/08/2017 12:49, Pablo Pazos wrote:
From Thomas comments, it is clear that we have such last two use 
cases, internal versioning and cross-system versioning / sync / 
consolidation.


Consider people here is talking about their own experience with the 
specs under the use case they implemented. We can argue that internal 
versioning is needed in 100% of the implementations while cross-system 
is a much less implemented case. This doesn't mean that the current 
specs are not usable and useful in abstract, but we should 
contextualize the discussion by use case and by the frequency each is 
implemented.


 For internal versioning it is clear that distributed versioning spec 
generate some friction at implementation time. IMO we need to address 
both use cases trying to minimize friction for new developers. That 
can improve the quality of the specs without print anything out.


Also, I would like to hear more about implementations of both use 
cases and the challenges implementers had to really validate the idea 
of addressing both use cases explicitly in the specs.


Cheers,
Pablo.


On Aug 18, 2017 5:39 AM, "Seref Arikan" 
<serefari...@kurumsalteknoloji.com 
<mailto:serefari...@kurumsalteknoloji.com>> wrote:


I did not realise that this discussion reached the point of
suggesting that distributed versioning is taken out from the
specs. I have been designing and implementing lots of openEHR data
syncing functionality which relies on the distributed versioning
specifications. I have heaps of work pending, which will also use
that part of the specs. I can tell you that the current specs have
worked just fine for me so far and they are up to the same high
quality as the rest of the specifications, so they are absolutely
usable and useful.

The challenges of distributed versioning does not eliminate the
need for them, so I cannot agree with the suggestion to remove
them.  Sure, move them around in the specs all you want, but
please keep them.

All the best
Seref


On Fri, Aug 18, 2017 at 9:15 AM, Thomas Beale
<thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote:

Hi,

distributed versioning with branching was included to allow
syncing of data gathered about the same patient in different
EHR repositories. For most data, syncing the repos is trivial,
since it's different data.

The classic cases of potential clashes is medication list,
problem list, basic clinical demographic data, etc. If a sync
was started and two medication lists are found that are forks
of a single earlier one, a manual merge will be required.

We are only just starting to see the implementation of systems
where syncing may be a question, so although there may be
adjustments to make to the branched versioning model, I would
not be in favour of throwing it out at this point.

We are however going to move it to the BASE component and make
it a standalone model.

- thomas


On 21/06/2017 09:19, Pablo Pazos wrote:

Hi Bert, see below

On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees
<bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote:

Hi Pablo, I did it a few years ago, just dumped
not-current versions in a slow XML database, because, in
normal cases they are never queried, and when they need
to be queried, there can always be found a faster solution.

But of course, this was a linear version system. ExistDB
supports distributed versioning on XML out of the box.
And you can also use a normal, not OpenEHR, version
system like Git or VCL.

But when looking at how OpenEHR works, is there ever need
of merging? Do people edit concurrently same datasets? I
thin

Re: post coordinated expressions

[Thomas Beale]

we will certainly look into doing this one as quickly as possible.


On 02/02/2017 18:03, Bert Verhees wrote:
I wonder what the decision will be. Will the current ADL specs be 
adjusted to support also post coordination? The grammar change is 
trivial. Several organizations in the Netherlands would really welcome 
that. Can we have an indication about this?


This also, because the migration to ADL 2.0, also after it is ready 
defined, will take several years.


Thanks
Bert



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

Re: ADL AOM

[Thomas Beale]

On 02/12/2015 07:57, Bert Verhees wrote:

Thomas Beale schreef op 1-12-2015 om 20:42:


Bert

things that you might think about that I have not done yet:

  * whether we put error branches in the grammar -  I had a lot of
these in the old .y grammars. All gone for now.


I like to see them, can you post a link?


ADL - 
https://github.com/openEHR/adl-tools/blob/master/components/adl_compiler/src/syntax/adl/parser/adl_2_parser.y
CADL - 
https://github.com/openEHR/adl-tools/blob/master/components/adl_compiler/src/syntax/cadl/parser/cadl_2_parser.y


typical example of code:

c_complex_object_id: type_identifier V_ROOT_ID_CODE

{

if object_nodes.is_empty then

create $$.make ($1, $2)

else

abort_with_error (ec_VARND, <<$2, Id_code_regex_pattern>>)

end

}

| type_identifier V_ID_CODE

{

if not object_nodes.is_empty then

create $$.make ($1, $2)

else

abort_with_error (ec_VARCN, <<$2, Root_id_code_regex_pattern>>)

end

}






  * whether to put labels on sub-parts of parser rules - will
generally only be determinable by implementers - it's hard for me
to guess where to put these

Also here, can you give a list and example what it is you are writing 
about


https://theantlrguy.atlassian.net/wiki/display/ANTLR4/Actions+and+Attributes 
- look for 'labels'



  * there are still a few outstanding annoyances

Please list them, now I am diving into it, I can as well take some 
time for that.


https://github.com/openEHR/adl-antlr/issues

- thomas

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

Re: ADL AOM

[Thomas Beale]

Bert

things that you might think about that I have not done yet:

 * whether we put error branches in the grammar -  I had a lot of these
   in the old .y grammars. All gone for now.
 * whether to put labels on sub-parts of parser rules - will generally
   only be determinable by implementers - it's hard for me to guess
   where to put these
 * there are still a few outstanding annoyances

If you can document somewhere how to do the CamelCase conversion, I will 
add it to the comments and/or main ADL spec somewhere (i.e. we don't 
want to change the case in the original files, but we do want to make it 
easy for people wanting CamelCase to do a simple operation to get it, so 
their code looks normal).


- thomas


On 01/12/2015 16:59, Bert Verhees wrote:

Hi,

I am trying to generate an AOM from a grammar, I used a some 
open-sourced of stuff from Pieter Bos and Thomas Beale.
I modified the grammar, f.e. to let it generate camelCase, and I need 
to do more with the grammar, still studying it..


I do it just for fun, that is all.

I wanted you to know, so that there are no future misunderstandings

https://github.com/BertVerhees/adl-aom

best regards
Bert

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





--

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