Bug in timezone serialization

The timezone for a DV_DATE_TIME was serialized three times instead of just once, in three different formats. This has been fixed.

The URL in the pom.xml in maven now points to the correct openehr repository, instead of the nedap one.

Equals, constructors, BMM -> JSON schema, configurable json mapping

Thanks to the joint efforts EHRBase and Nedap teams, we are proud to present Archie version 0.8.0. Included are:

Configurable JSON mapping.

You can:

• configure the type property (to be the standards based '_type' instead of '@type' for example).
• whether or not to include extra fields such as 'path', that potentially make javascript development easier, but the data bigger

Some more options are possible

Constructors in the RM

The reference model objects now have two sets of constructors:

• constructors with a minimal set of parameters
• the exact same constructors as the reference implementation
  This means the Archie RM is now even closer to being a drop-in replacement of the older OpenEHR reference implementation

Equals+hashcode methods in the RM

The reference model objects now all have equals and hashcode methods, that check for equality of the entire object tree.

Improved JSON Example generation

The JSON example generation has been improved so the resulting instances are valid in more cases

BMM to JSON Schema generator added

The JsonSchemaCreator converts a BMM schema to a json schema. This improved upon the standard specifications-ITS-JSON by checking all of the model, where the standard json schema stops as soon as inheritance is encountered.

The README.md has not yet been fully updated. It will be soon.

Small bugfix for slot-closing in the flattener

When in a specialised archetype a slot is closed, then after that the slot is filled with two archetype roots, the ordering of the C_OBJECTS in the resulting flat archetype was incorrect.
Note that you should not do this in this order (fill first, then close after), but it's not explicitly invalid. So don't do it, but Archie now correctly handles it in case someone does.

More bugfixes

The EHRBase team has started using Archie, and has submitted several contributions. The first few of their contributions can still fit in a minor version, so here it is - together with some fixes from the core Archie team.

The next release will be a major version, with more contributions from the EHRBase team.

Breaking changes

• JSON: EHRStatus.is_modifiable and EHRStatus.is_queryable were serialized without the is_. This has been changed. If anyone has used this before, please open an issue and we will add backwards compatibility.

bug fixes

• annotations in templates crossing archetype roots were incorrectly marked as invalid by the validator. This has been fixed.
• Some fixes in XML unmarshalling
• MultiplicityInterval is now Serializable
• More ISO 8601 formats are now supported in the datetime parsers
• path lookup in the RM with ADL 1.4 paths with at-codes now works

bugfixes

• MultiplicityInterval.toString() now works correctly
• The new CObject.effectiveOccurrences algorithm in the specification has been implemented, fixing some problems with archetypes.
• annotations are now being flattened, both in the flattener and operational template creator

Validation fixes and more

Feature

• Namespace added to ArchetypeID in the reference model, so you can now refer to namespaced archetypes from EHR data

• added AssumedValueFiller, which adds assumed values to the AOM in all cases where only one value is possible to fulfill a primitice object constraint

• added a flat_sum function to the expression language, which sums all input to one result

• Archie can now compile on JDK versions 10 and 11. There may be some layout issues in the javadoc output, they will be fixed at a later time

• Two minor obsolete and no longer used classes have been removed

Bugs

• In some setups the BuiltinReferenceModels did not work, most notably android and people with complicated classloader setup. This has been fixed.

Flat sum feature

The flat sum feature requires a bit of explanation. The OpenEHR expression language is a bit tricky with multiplicites: paths that refer to one element in an archetype can actually refer to more than one element in data. Archie solves this automatically in most cases, so clinicians can write simple expressions without having to think about that problem.
However, sometimes you cannot avoid this. For example if you would write:

/some/path = sum(/some/other/path[id3], /some/other/path[id4])

It is possible that there are two instances of some. The sum result will not be a single number, but will be a list of two numbers, and /some/path will be two fields that will be set with this integer.

We added flat_sum, which always adds all numbers, and always produces a single result. This is useful if you do not know how many instances there will be in data, but do want to sum all of them into a single number.

There will likely be more flat_ functions in the future.

ADL 1.4 conversion and more

The biggest feature in this release is an ADL 1.4 converter. Note that this converter is a first release. As such, it is wise to test this feature first before relying on this conversion in any production environment.

During the conversion new node ids are generated for nodes that do not have a node id in ADL 1.4, but need one in ADL 2. This means there can be several strategies for generating these node ids. This has not yet been standardized by openehr. Until then, you need to rely on a single converter for these conversions.

Breaking changes

• assumed value is no longer set unless it is explicitly in the ADL file. Before it was set on a constraint with a single possible value automatically
• The deprecated P_BMM implementation has been removed - only the new implementation remains.

Other Features

• better compliance with the standard XSDs
• support the new serialized_type bmm notation
• parse p_bmm term codes for enums (but not yet implemented in bmm)
• always sets single and multiple in the ADL 2 parser if a reference model metadata or bmm is passed
• built in reference models updated with latest BMM
• the RM Object Validator now works on RM instances where you do not have the archetype, validating default constraints
• better and translatable validation messages in the archetype validator
• some minor bug fixes

0.5.8 - Fixes in ArchieRMInfoLookup

This release adds some fixes to the meta-information about the implementation of the RM. This includes fixes to property names, existence and cardinality.
This fixes some problems in the RM Object Validator as well.

This does not change any serialization, and the java API of the RM remain exactly the same - just the mapping to the OpenEHR metadata now aligns more correctly.

ODIN/ADL serialization bugfixes

Small bugfixes for issues in 0.6.0 that generated exceptions, or invalid ADL in some cases.

RM 1.0.4 compliance, new P_BMM, Example instance construction and native ODIN serialization

This version contains:

• The RM implementation has been verified against the 1.0.4 BMM models, and fixed where needed
• The ExampleJsonInstanceGenerator, a tool that constructs valid json example instances of RM Objects, based on an operational template.
• A Jackson dataformat implementation for ODIN: Native ODIN serialization of arbitrary java objects
• A complete rewrite of the P_BMM implementation, with improved validation.
• Android 8.0/API level 26 support, including faster initialization time

P_BMM implementation: Breaking changes

The P_BMM implementation removes all state from the P_BMM models, and makes the code much easier to understand and maintain for future releases.
This does mean the P_BMM models do not entirely match the P_BMM specification anymore, because the specification contains processing state in the models. For example, the P_BMM model no longer contains a reference to BmmModel, but a separate class has been made that is the result of a P_BMM to a Bmm conversion. Where the processing state is not involved, the new P_BMM implementation aligns more closely to the specification and is directly mapped to and from ODIN.
See the Readme for more details.
The old P_BMM implementation has been deprecated and will be removed in 0.7.0. If you use only the BuiltinReferenceModels with the built in tools, you will not have to change anything. If you use your own tools based upon the BMM, you may need to do some minor changes. If you have your own tools based upon the P_BMM, there may be bigger changes to your code needed.

ExampleJsonInstanceGenerator

Generates RM Object instances based on a BMM model. Because the BMM model does not contain enough information to do this in all cases, this is currently OpenEHR RM specific. It is possible to extend this implementation for other reference models - all the OpenEHR RM specific parts are in separate methods.

Native ODIN serialization in Jackson

This outputs native ODIN for any class that is annotated with jackson annotations. See the Readme for usage details. All ODIN generation in Archie, for example in serializing Archetypes and P_BMM, has been replaced with this implementation.
There are some tricky situations where the generated odin cannot be automatically parsed in Archie without extra annotations or custom mapping. This is especially the case when serializing lists of non-primitive objects: ODIN requires a Map syntax in this case ('keyed/indexed list', which is the exact same syntax as a Map!), so the serializer then must serialize to a Map with an integer index as key.
As this is a rather unusual syntax, there is no standard support in Jackson. So, this cannot be automatically be parsed/mapped to a List by Jackson, meaning this will either require custom mapping, or will require a Map in your java-object instead of a List.
This does not apply to Lists of Strings, Integers, Longs, Reals, Doubles, URIs, Date, DateTime, Time, Duration and Period objects, which in ODIN can just be lists without an index.

RM 1.0.4 compliance: Breaking changes

The verification against the BMM has resulted in some changes in the model, and some changes in the official BMM release where it did not match the specification. This means there are some backwards incompatibilities. The JSON by Archie versions 0.5.5 and earlier should be parsable by this release, it accepts all earlier misspellings. JSON generated by version 0.6.0 will not be parsable by releases 0.5.6 and earlier, and should mostly but not completely be parsable by version 0.5.7.

JSON parsing bugfix

The changes in release 0.5.6 were meant to be backwards compatible. Unfortunately they were not - 0.5.5 JSON could not be parsed with 0.5.6. This release fixes that problem.

Note that 0.5.5 cannot parse the JSON created by 0.5.6 or 0.5.7. This is easily fixed in your own application by configuring the Jackson ObjectMapper as in #76, or of course by upgrading to 0.5.7.

Version 0.5.7 is much less strict in when it requires and can accept the '@type' parameter, so this problem should not reoccur in future versions

Sorry for any inconvenience causes by this problem.