Archie 0.7.0 - ADL 1.4 to ADL 2 conversion

[Pieter Bos]

I’m pleased to announced the release of Archie version 0.7.0. This version 
brings the ability to import ADL 1.4 files to AOM 2, and to convert them to ADL 
2.

This makes it possible to generate ADL 2 archetypes directly from within 
java-based ADL 1.4 tools. Note that there are some things you need to be aware 
of if you’re planning to do this, see the Archie readme for more information.

In addition, compliance to the XML and JSON schemas and to the RM specification 
has been improved, it is now possible to validate RM objects without supplying 
an archetype, the archetype validation messages have been improved and can now 
be translated into different languages, and the P_BMM implementation is updated 
to parse the latest P_BMM features.

Documentation can be found at the readme of https://github.com/openEHR/archie . 
See the release notes on github for more information about this release.

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: Archie version 0.6.0 released

[Pieter Bos]

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

Date: Wednesday, 13 February 2019 at 14:03
To: "openehr-implementers@lists.openehr.org" 

Subject: Re: Archie version 0.6.0 released


However... there is the question of post-processing the flattened output ('Raw 
OPT' in the diag below) to do things like choosing/reducing languages, possibly 
removing annotations, reducing terminology bindings, potentially replacing 
inline at- and ac-codes with their binding values (i.e. concept or value-set 
refs from actual terminologies).

See here in the OPT2 
spec<https://specifications.openehr.org/releases/AM/latest/OPT2.html#_types_of_opt>.
 These post-processing stages are what need further specification.

The only post-processing stage we implemented is language removal.

With respect to preserving lineage in templates, this was contemplated in the 
Archetype Identification 
spec<https://specifications.openehr.org/releases/AM/latest/Identification.html#_supporting_archetype_based_querying>,
 but not integrated into any other specification at this stage.

The current OPT 2 specification says even the specialization statement should 
be removed from an OPT. I ignored that at least in the AOM when implementing 
operational templates, to need source forms of archetypes slightly less often

Regards,

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

[Pieter Bos]

From: openEHR-implementers  on 
behalf of Seref Arikan 
Reply-To: For openEHR implementation discussions 

Date: Tuesday, 12 February 2019 at 20:48
To: For openEHR implementation discussions 

Subject: Re: Archie version 0.6.0 released

Thank you. Please see inline

On Tue, Feb 12, 2019 at 7:02 PM Pieter Bos 
mailto:pieter@nedap.com>> wrote:
I mean OPT2, which is according to the ooenehr specifications a flattened 
archetype with extra operations performed on it, such as including and 
flattening all archetype roots in the same tree, including their 
terminologies,and replacing all use_node with a copy of the tree to be used. 
Very useful. Can be expressed in ADL.
I did not realise that opt2 was fully defined. I thought it was ongoing work. 
I'll have to go and check it now :)

The OPT2 specification status is development. However, both the AOM 2 and ADL 2 
specification contain all features needed for operational templates and the OPT 
2 specification is good enough to implement. It saves a lot of development 
time, you only have to add very little amount of functionality in your tools to 
support the use_node and use_archetype constructs, the OPT generator does most 
of the work for you.


Archie does not support the 1.4 xml OPT format.
Thanks for the clarification.

Note that xml bindings are in place for the AOM, but I wouldn't use them for 
interoperability because they were written before an official xsd has been 
published - I'm actually not sure if an official AOM 2 xsd currently exists.
Could you please clarify which official XSD you're referring to? AOM2?

Well you were looking at the XML bindings in Archie, so I thought I’d give a 
bit of comment on the status of them. So yes, AOM 2. I see that Sebastian Iancu 
has recently added AOM 2 XSDs to 
https://github.com/openEHR/specifications-ITS-XML. I’m not sure about their 
status, but I’ll check if we can compare them to the Archie XML bindings soon.

Regards,

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

[Pieter Bos]

I mean OPT2, which is according to the ooenehr specifications a flattened 
archetype with extra operations performed on it, such as including and 
flattening all archetype roots in the same tree, including their 
terminologies,and replacing all use_node with a copy of the tree to be used. 
Very useful. Can be expressed in ADL.

Archie does not support the 1.4 xml OPT format.

Note that xml bindings are in place for the AOM, but I wouldn't use them for 
interoperability because they were written before an official xsd has been 
published - I'm actually not sure if an official AOM 2 xsd currently exists.

Note that there is also the concept of a template, which is also an archetype, 
but is different from an operational template - templates are authored, opts 
are generated, often generated from a template.

Regards,

Pieter Bos

Op 12 feb. 2019 19:12 schreef Seref Arikan :
Hi Pieter,

Excellent work, many thanks for all the effort your team put into this library. 
Could you clarify something? When you say an operational template, do you mean 
a flattened archetype as per ADL 2.0? (that's the impression I got looking at 
the code)

I'm a bit behind re adl 2.0; does your implementation imply that an opt 
according to 2.0 specs is no different than an archetype? I can see that you 
declared some xml bindings in your OperationalTemplate class which seam to 
refer to type names from opt 1.4 .

In summary I'm a bit confused :) Could you briefly explain how Archie team sees 
the relationship between opt 1.4 and 2.0 ?

All the best
Seref


On Tue, Feb 12, 2019 at 1:04 PM Pieter Bos 
mailto:pieter@nedap.com>> 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<mailto: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

Archie version 0.6.0 released

[Pieter Bos]

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

Archie version 0.5.0 released

[Pieter Bos]

Today I’m pleased to announce the release of Archie version 0.5.0. Archie is an 
open source OpenEHR library for archetype modelling and implementing EHRs, 
based on ADL 2, written in Java. This release brings two new features, one for 
modeling and one of EHR implementations: Archetype diffing and validating RM 
Objects against archetypes.

The diff operation extends the set of archetype modeling tools already 
available in Archie. It makes editing specialized archetypes much easier by 
allowing users to edit the flat form of these archetypes. It generates ADL 2 
archetypes, including differential paths for more compact specialized 
archetypes and it adds sibling order markers to support reordering nodes in 
specialized archetypes. Together with the flattener, archetype validation, ADL 
serialization and BMM models, Archie now includes a full set of features to 
create archetype modelling tools. We are using Archie ourselves to create an 
ADL 2 archetype modeling tool. Limited early access is available by sending me 
an e-mail.
The RM Object validator validates objects against archetypes, and allows for 
validation of user input against clinical models.

The library can be found at https://github.com/openehr/archie under the Apache 
2 license, and is available through Maven Central.

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: ADLParsers for ADL 1.4/2.0

[Pieter Bos]

Hello Georg,

The ADL workbench can convert adl 1.4 to adl 2.0 archetypes. It is available 
from the OpenEHR website. Archie parses and validates the output from the 
converted CKM correctly - in fact that is one of the included automated tests.

Regards,

Pieter Bos
Nedap Healthcare

> Op 20 feb. 2018 om 10:47 heeft Georg Fette  het 
> volgende geschreven:
> 
> Hello,
> I am currently trying to get a feeling for using the Java utilities that 
> exist for openEHR and startet with the tools that exist as Maven repositories 
> at https://mvnrepository.com.
> I am currently experimenting with the ADLParser 1.0.71. As a test example I 
> downloaded from the Clinical Knowledge Manager the archetype 
> "openEHR-EHR-OBSERVATION.blood_pressure.v1" and exported it as an .adl-file. 
> When parsing this file I receive an archetype instance but when invoking 
> ToString() on it I get a StackOverflowException. Am I doing something wrong, 
> is this a bug or are the archetype exports from CKM not specification 
> compliant ?
> Alternatively I think about rather using Archie as the toolbox for building 
> my openEHR applications. But the ADLParser in Archie only supports ADL 2.0. 
> Is there an equivalent for CKM supporting ADL 2.0 from where I can get a rich 
> variety of archetype examples for experimenting ? Or are there converters 
> that convert ADL 1.4 archetypes to ADL 2.0 ?
> 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-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

Re: Announcing Archie version 0.4

[Pieter Bos]

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

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan 
mailto:serefari...@kurumsalteknoloji.com>> 
het volgende geschreven:

Hi Peter,

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

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
mailto:peter.gum...@gmail.com>> wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

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

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

Peter


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

___
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

Re: Announcing Archie version 0.4

[Pieter Bos]

And due to several small bugs, we’re at version 0.4.2. Should be available soon 
at maven central.

For anyone wanting to test Archie without writing code, we’ve also created a 
command-line archetype validator. Works with all included BMM reference models, 
including OpenEHR and CIMI.

To use:

1.   Download adlchecker.zip version 0.4.2 from the releases page of the 
archie github repository, at https://github.com/openEHR/archie/releases.

2.   Unzip

3.   Make sure you have a java 8 JRE installed and that typing ‘java 
-version’ in a command/terminal window shows you installed java version 1.8.x

4.   Run bin/adlchecker (linux, OS X) or bin/adlchecker.bat (windows) from 
a terminal/command prompt and follow the instructions to point it at your 
archetypes

Note that it only supports ADL 2, not 1.4. It can also output the flat ADL.

If you find any issues, they can be reported at the github repository.

Regards,

Pieter Bos
Nedap Healthcare

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

Date: Wednesday, 31 January 2018 at 19:13
To: "openehr-implementers@lists.openehr.org" 
, Openehr-Technical 

Subject: Re: Announcing Archie version 0.4




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

Announcing Archie version 0.4

[Pieter Bos]

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

Re: Mandatory elements in archetypes, and user interfaces

[Pieter Bos]

How we handle this:

In our forms, if an archetype root or archetype slot is optional, it renders a 
remove button that works on a single click. In case it is pressed accidentally, 
it will then render an add button to add it again.
In addition, if a user does not press the remove button and does not enter any 
data in any fields in an optional part, we consider that part to be not 
included in the resulting data. So far that approach works well for any models 
we have and is straightforward to use.

You could even add a ‘there is no data, but I want this part to be included’ UI 
element. We have not encountered a use case for that yet which cannot already 
be handled by the null_flavour of Element.

With these approach, the problem you mention does not exist in cases where the 
head circumference is sometimes but not always needed.

For cases where you don’t even want to see the input field at all, ever, we 
support templates. We use ADL 2, but it should be possible in OPT 1.4. Then if 
some users never need the head circumference, they can just set the occurrences 
of the use_archetype to {0} in a template, and the standard or in your case 
national archetype does not have to be changed.

Regards,

Pieter Bos

From: openEHR-implementers  on 
behalf of "Bakke, Silje Ljosland" 
Reply-To: For openEHR implementation discussions 

Date: Friday, 10 November 2017 at 11:47
To: "openehr-implementers@lists.openehr.org" 
, "For openEHR clinical discussions 
(openehr-clini...@lists.openehr.org)" 
Subject: Mandatory elements in archetypes, and user interfaces

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.

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

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

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

Re: Versioning implementations

[Pieter Bos]

We have the data structures set up in our database to handle branching and 
merging. But we do not yet support it for users and do not currently have plans 
to build it.

The merge process looks like it could be complicated for users.

Regards,

Pieter Bos

Op 21 jun. 2017 om 03:06 heeft Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Hi all,

I had this questions in mind for a long time: did someone implemented the 
distributed versioning of openEHR?

The specs define a great distributed versioning mechanism but it is a little 
trickier to implement. Also there is no clear who will do the work of managing 
that, and how that structure will be queried. It is very difficult to me to 
think of an amendment sent to an EHR and that not being available for all the 
parties looking at the EHR of the patient.

In the case of the EHRServer I built, only linear versioning is possible, there 
is only one latest version for each compo, and queries only get data from 
latest versions.

Just wondering, what do others did for versioning and what policies do you have 
if you implemented the distributed approach in terms of branching, merging and 
querying.


Thanks!

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

Operational templates, archetype_ref in C_ARCHETYPE_ROOT and node id

[Pieter Bos]

A quick question of an implementation detail to which I’m hoping is a simple 
answer ☺

When we create an Operational Template, we should fill the archetype roots with 
a copy of the structure of the other archetype. Then the node id of the 
C_ARCHETYPE_ROOT is set to the id of that archetype.

This makes it much easier to work with these templates in many cases, since 
they can be sent to the UI and the UI does not need to retrieve other 
archetypes to render something and requires much less logic.

Also in templates you can define overlays of other archetypes.
However, I have a use case where I want to be able to detect which archetypes 
are used in C_ARCHETYPE_ROOTS in an operational template and link to that 
archetype. In the current Operational Template creation of Archie, I set both 
the node id and the archetype_ref of the C_ARCHETYPE_ROOT to the archetype id 
of the overlay, not the parent archetype.
This means that the archetype id used in the archetype_ref of the 
C_ARCHETYPE_ROOT is only valid within the context of the template and cannot 
just be retrieved from the generic top level archetype repository. I can work 
with that, but it just does not sound like a good  solution.

That brings me to my question:
What should the values of the following two fields of C_ARCHETYPE_ROOT be in 
the resulting operational template, in the case that the C_ARCHETYPE_ROOT in 
the template points to an overlay of an archetype:
node_id:
archetype_ref:

Should this be:
node_id: archetype id of overlay
archetype_ref: archetype id of parent of overlay

Or something else?

Regards,

Pieter Bos


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

Re: Archie version 0.1.0 released

[Pieter Bos]

Hello Diego,

That is possibly, but has some complications:

To make a dual licensing approach work in this case it would requires us to 
release Archie under the AGPL, combine it with adl2-core and get a license from 
Marand to use their contributions to the resulting library in our products 
combined with a license from us to them to use our contributions in their 
products. Also all future contributors will have to sign a document allowing to 
use their contribution to be released under a different license by Marand and 
Nedap.

That would leave the resulting combined library still unusable for other 
non-GPL projects by others.

I would prefer another way forward :)

Regards,

Pieter Bos



On 18/05/16 11:10, "openEHR-technical on behalf of Diego Boscá" 
 
wrote:

>Nice wok Piter!
>
>I've seen quite a lot of open source projects with dual licensing.
>Maybe this is the way to go so we can please everyone
>
>Regards
>
>2016-05-18 11:06 GMT+02:00 Pieter Bos :
>> Hi Ian,
>>
>> Good to hear this work is being appreciated.
>>
>> It could certainly be possible to merge Archie with the existing adl2-core 
>> library. I think the adl2-core library looks like it has good quality code 
>> and decent API. It could be interesting because although there is quite a 
>> bit of overlap in functionality, Archie has functionality that adl2-core 
>> does not have, and adl2-core has functionality Archie does not yet have. If 
>> the owners of that library are willing to relicense their code or at least 
>> parts of their code under a different license, it could be interesting. 
>> We’re open to releasing this code under a different license, but only if the 
>> resulting work can be used in non-GPL software.
>>
>> Regards,
>>
>> Pieter Bos
>> Nedap Healthcare
>>
>> From: openEHR-technical 
>> mailto:openehr-technical-boun...@lists.openehr.org>>
>>  on behalf of Ian McNicoll mailto:i...@freshehr.com>>
>> Reply-To: For openEHR technical discussions 
>> mailto:openehr-techni...@lists.openehr.org>>
>> Date: Wednesday 18 May 2016 at 10:42
>> To: For openEHR technical discussions 
>> mailto:openehr-techni...@lists.openehr.org>>
>> Cc: 
>> "openehr-implementers@lists.openehr.org<mailto:openehr-implementers@lists.openehr.org>"
>>  
>> mailto:openehr-implementers@lists.openehr.org>>
>> Subject: Re: Archie version 0.1.0 released
>>
>> Hi Pieter,
>>
>> This looks a really interesting and valuable piece of work. Many thanks for 
>> your efforts - hopefully others will want to contribute. It would be nice if 
>> we could somehow bring this work and the existing AOM2/ADL2 work together 
>> (or at least not duplicate work). I appreciate there is a different 
>> licensing approach but I don't think that is necessarily set in stone.
>>
>> 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?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
>> 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 17 May 2016 at 12:53, Pieter Bos 
>> mailto:pieter@nedap.com>> wrote:
>> A few months ago I announced the development of an open source Java openEHR 
>> library called Archie. It has progressed enough that I’m now pleased to 
>> announced the release of version 0.1.0 of Archie. It supports the latest ADL 
>> 2 and reference model versions and is licensed under the Apache license.
>>
>> The documentation and source can be found at 
>> https://github.com/nedap/archie. It’s available at Maven Central at 
>> com.nedap.healthcare:archie:0.1.0 .
>>
>> Why another library?
>>
>> The existing open source openEHR libraries were either ADL 1.4 or published 
>> under the Affero GPL. This means there is no library available for non-GPL 
>> ADL 2 openEHR projects. We are building a non-GPL openEHR implementation, so 
>> we needed a library and wrote it. We believe the openEHR community benefits 
>> from having up to date open source tools, so we decided to release Archie.
>>
>> Features:
>>
>>   *   ADL parser, including a generic ODIN to Java objects mapper
>>   *   Archetype Object Model
>>   *   The EHR part of the Reference Model
>&g

Re: Archie version 0.1.0 released

[Pieter Bos]

Hi Ian,

Good to hear this work is being appreciated.

It could certainly be possible to merge Archie with the existing adl2-core 
library. I think the adl2-core library looks like it has good quality code and 
decent API. It could be interesting because although there is quite a bit of 
overlap in functionality, Archie has functionality that adl2-core does not 
have, and adl2-core has functionality Archie does not yet have. If the owners 
of that library are willing to relicense their code or at least parts of their 
code under a different license, it could be interesting. We’re open to 
releasing this code under a different license, but only if the resulting work 
can be used in non-GPL software.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Ian McNicoll mailto:i...@freshehr.com>>
Reply-To: For openEHR technical discussions 
mailto:openehr-techni...@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 10:42
To: For openEHR technical discussions 
mailto:openehr-techni...@lists.openehr.org>>
Cc: 
"openehr-implementers@lists.openehr.org<mailto:openehr-implementers@lists.openehr.org>"
 
mailto:openehr-implementers@lists.openehr.org>>
Subject: Re: Archie version 0.1.0 released

Hi Pieter,

This looks a really interesting and valuable piece of work. Many thanks for 
your efforts - hopefully others will want to contribute. It would be nice if we 
could somehow bring this work and the existing AOM2/ADL2 work together (or at 
least not duplicate work). I appreciate there is a different licensing approach 
but I don't think that is necessarily set in stone.

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?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
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 17 May 2016 at 12:53, Pieter Bos 
mailto:pieter@nedap.com>> wrote:
A few months ago I announced the development of an open source Java openEHR 
library called Archie. It has progressed enough that I’m now pleased to 
announced the release of version 0.1.0 of Archie. It supports the latest ADL 2 
and reference model versions and is licensed under the Apache license.

The documentation and source can be found at https://github.com/nedap/archie. 
It’s available at Maven Central at com.nedap.healthcare:archie:0.1.0 .

Why another library?

The existing open source openEHR libraries were either ADL 1.4 or published 
under the Affero GPL. This means there is no library available for non-GPL ADL 
2 openEHR projects. We are building a non-GPL openEHR implementation, so we 
needed a library and wrote it. We believe the openEHR community benefits from 
having up to date open source tools, so we decided to release Archie.

Features:

  *   ADL parser, including a generic ODIN to Java objects mapper
  *   Archetype Object Model
  *   The EHR part of the Reference Model
  *   Basic APath-queries on AOM and RM objects
  *   Flattener
  *   Operational template creation
  *   Easy to use APIs for object creation, terminology lookup, archetype model 
tree walking and constraint checking
  *   RM serializes to XML in accordance with the openEHR-published XSD, or to 
JSON using jackson
  *   AOM serialization to JSON for easy use in JavaScript based 
web-applications.
  *   Tools for reference model object creation and attribute setting based on 
archetype constraints
  *   Pluggable reference model architecture: the reference model can be 
swapped for some other implementation and the tools keep working

Experimental features:

These features are included, but the API and implementation of these features 
will probably change in the coming versions:

  *   Rules evaluation (with some minor syntax changes for now, see the project 
readme)
  *   Full APath and XPath expression evaluation on reference model objects 
using the JAXP–implementation of your choice

Future releases and contributions

We’re continuing the development, so there will be more releases in the near 
future. If you want to contribute: pull requests and issue reports are very 
welcome!

Regards,

Pieter Bos
Nedap Healthcare


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

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

Archie version 0.1.0 released

[Pieter Bos]

A few months ago I announced the development of an open source Java openEHR 
library called Archie. It has progressed enough that I’m now pleased to 
announced the release of version 0.1.0 of Archie. It supports the latest ADL 2 
and reference model versions and is licensed under the Apache license.

The documentation and source can be found at https://github.com/nedap/archie. 
It’s available at Maven Central at com.nedap.healthcare:archie:0.1.0 .

Why another library?

The existing open source openEHR libraries were either ADL 1.4 or published 
under the Affero GPL. This means there is no library available for non-GPL ADL 
2 openEHR projects. We are building a non-GPL openEHR implementation, so we 
needed a library and wrote it. We believe the openEHR community benefits from 
having up to date open source tools, so we decided to release Archie.

Features:

  *   ADL parser, including a generic ODIN to Java objects mapper
  *   Archetype Object Model
  *   The EHR part of the Reference Model
  *   Basic APath-queries on AOM and RM objects
  *   Flattener
  *   Operational template creation
  *   Easy to use APIs for object creation, terminology lookup, archetype model 
tree walking and constraint checking
  *   RM serializes to XML in accordance with the openEHR-published XSD, or to 
JSON using jackson
  *   AOM serialization to JSON for easy use in JavaScript based 
web-applications.
  *   Tools for reference model object creation and attribute setting based on 
archetype constraints
  *   Pluggable reference model architecture: the reference model can be 
swapped for some other implementation and the tools keep working

Experimental features:

These features are included, but the API and implementation of these features 
will probably change in the coming versions:

  *   Rules evaluation (with some minor syntax changes for now, see the project 
readme)
  *   Full APath and XPath expression evaluation on reference model objects 
using the JAXP–implementation of your choice

Future releases and contributions

We’re continuing the development, so there will be more releases in the near 
future. If you want to contribute: pull requests and issue reports are very 
welcome!

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: New open source ADL2-Library

[Pieter Bos]

Good to hear you appreciate our effort. While developing Archie we found
issues in both the ADL-antlr grammar and the Marand ADL-designer. We¹re
very happy to see how soon after we reported them the issues were fixed -
Often even within a matter of minutes after reporting. So it already has
helped the compatibility of different tools - we can now parse the ADL2
output of the adl-designer.

About our motivation: we develop and sell software for the Dutch care
market. Our current EHR-implementation works great for many organizations,
but is not flexible enough for some others. That is why we are looking at
openEHR and developing prototypes for the next version of our EHR. When we
realised the improvements in ADL 2 and the limitations of the java
reference implementation we decided we needed to switch to ADL2.

We found out there was no open source tool available we could use. So we
developed Archie and released it under the Apache license - so others will
more easily be able to develop their own tools, whether open or closed
source. And because we think that for a platform like openEHR - the more
people using it, the more benefit there is to anyone using or developing
openEHR-based software.
o.

Regards,

Pieter Bos
Nedap Healthcare

>
>--
>
>Date: Fri, 30 Oct 2015 07:57:24 +0100
>From: Erik Sundvall 
>To: For openEHR implementation discussions
>   
>Cc: ?ystein Nytr? 
>Subject: Re: New open source ADL2-Library
>Message-ID:
>   
>Content-Type: text/plain; charset="utf-8"
>
>Great news!
>
>Apache 2 is a good licensing choice, that is what we recommend for openEHR
>open source projects, although some contributors have felt reasons to use
>other licences.
>
>Apache 2 for example makes it easier for some companies to allow staff to
>spend paid working time on improving industry/community-shared open source
>components that they use in their closed or open platforms. Nowadays I'd
>guess more openEHR software implementation work is done by business
>employees during paid time than by volunteers using their spare time.
>
>Having more ADL2 parsers does bring some extra benefits:
>- compatibility tests and discussions can clarify the specification if
>needed
>- more of the possible design space is explored by more teams that can
>learn from each other
>
>However having a dozen of open source ADL2 parsers would probably be a
>waste of developer effort.
>
>I think the same goes for archetype/template editing tools, having a
>handful of tools explores more options and brings up more good discussions
>than having a single one, but having too many would potentially be a waste
>of developer effort.
>
>If you want to, then please to tell us a little bit more about the
>context/product that you will be using the parser in.
>
>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 (previously
>lio.se)
>http://www.regionostergotland.se/cmit/
>Link?ping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/
>
>On Wed, Oct 28, 2015 at 7:34 PM, Bert Verhees 
>wrote:
>
>> Thanks very much, Pieter, great job!
>>
>> Bert
>> Op 28 okt. 2015 18:20 schreef "Pieter Bos" :
>>
>> I would like to announce a new open source ADL2 library, written in
>>Java.
>>> It is based on the ANTLR-grammar released very recently by Thomas
>>>Beale.
>>>
>>> You can find it at https://github.com/nedap/archie
>>>
>>> It is still very much in development, but it is now at a state where it
>>> could be of use to people. It currently features:
>>>
>>> - an ADL2-parser that parses the full definition, specialises,
>>> terminology, value sets and (a subset of) rules sections
>>> - an archetype object model implementation
>>> - a flattener that can also make operational templates - still needs
>>> testing and work!
>>> - basic path queries with node ids and node meanings.
>>> - an experimental Archetype treewalker for openEHR reference models ?
>>>it
>>> can save you many instanceof calls.
>>>
>>> It parses most valid ADL2 files i?ve tested it with into an archetype
>>> object model. That includes most of the content of the clinical
>>>knowledge
>>> manager. We?re currently using this same library for an openEHR
>>> implementation and we will add features, fixes and tests to it as we
>>> progress.
>>>
>>> You might ask, why a new library? Don?t we have adl2-core already? The
>>> an

New open source ADL2-Library

[Pieter Bos]

I would like to announce a new open source ADL2 library, written in Java.
It is based on the ANTLR-grammar released very recently by Thomas Beale.

You can find it at https://github.com/nedap/archie

It is still very much in development, but it is now at a state where it
could be of use to people. It currently features:

- an ADL2-parser that parses the full definition, specialises,
terminology, value sets and (a subset of) rules sections
- an archetype object model implementation
- a flattener that can also make operational templates - still needs
testing and work!
- basic path queries with node ids and node meanings.
- an experimental Archetype treewalker for openEHR reference models ­ it
can save you many instanceof calls.

It parses most valid ADL2 files i¹ve tested it with into an archetype
object model. That includes most of the content of the clinical knowledge
manager. We¹re currently using this same library for an openEHR
implementation and we will add features, fixes and tests to it as we
progress.

You might ask, why a new library? Don¹t we have adl2-core already? The
answer is quite simple: licensing.
We could not use the adl2-core library for our projects, because it would
require us to release the entire project under the (A)GPL. So we ignored
the existing library and built our own. And now we release Archie under
the Apache license. This means you should be able to use it in any project
you like.

Want to help? Great! There¹s a list of missing functionality on the github
page. Just fork and create a pull request. Or just report any issues you
find on the github issue tracker.

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