This page is an starting point on an effort to build a "test base" with sample artifacts to help us on practical implementations and to share some ideas, problems and solutions. It's like a CKM for techies :D

The idea:

Create a public repository with:
- archetypes
- templates (structural, gui, etc)
- OTPs (operative templates, flattened, complete, concrete)
- term sets
- composition and extract instances
  - XML
  - JSON
Correct/improve current XSDs (http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)
Create some use cases and service definitions
- Create composition from data
- Get composition by id
- Push composition to some service
- TBD
- ...
Play around creating, sending and receiving artifacts from/to our services
Maybe publish our experience on some paper
- Distributed & open effort to make things work

The focus:

Knowledge artifacts: we want to concentrate on flat archetypes and operative templates, things that will be used by EHR systems, and no so much on source archetypes (artifacts for clinical modeling).
Serialization formats: the main use of XML, JSON and other serialization formats is to implement and test clinical data communication (IM instances), not for knowledge artifacts (archetypes, templates). As term sets are data also, maybe the serialization formats can be used for those artifacts too.
Artifacts, services and repositories:
- Now we are trying to see what artifacts were developed individualy, what problems we have with our implementations, trying to improve and harmonize all that, etc. then we'll look for a location for all that.
- Right now we are on a previous stage than deciding the physical location of the files.
- Maybe some of us can focus on artifacts and others on services & repositories (where to put the artifacts and how to access them).
- Idea about sharing common artifact processing tasks as public services: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007085.html

PP:
I really like the idea of having different repositories sharing the same artifacts, this can be a good technical proof of concept of a distributed CKM. (not a new topic, but maybe a forgotten one: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2011-September/002201.html). If some of you want to open the access to your services, I can write clients for the EHRGen project (http://code.google.com/p/open-ehr-gen-framework/) to consume artifacts and evaluate how it all works together.

Plan?:

Since we need "something" to test our tools, the first artifacts will be generated by hand, but when we reach a stable point on testing and we agree in the "test set" definition (e.g. our systems pass all the "test sets" we generate, and all test sets are consistent/have the same element structure in the same way), we can think of test set automation (develop some code to create test sets in a semi? automatic way). It is very important to have this as a clear objective because creating test by hand do not escalate well and is error prone. How we will do this? is a discussion we need to have.

be sure that RM XSDs are correct compared to the specs.
have some RM XML instances are correct validated against XSDs. (Rong Chen said:The xml-binding component in the Java reference implementation does> just that. It binds RM object instance to generated XML objects that> can be serialized according to published XSD.)
have RM XML instances generated for some flat archetypes or OTPs, with the referenced source archetypes and term sets accessible too.To flatten archetypes we'll need to do some development.
create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps.
create some test cases in our own projects to be sure we are ok, maybe share those tests and results.
maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not.

Collaborators

If you want to join this effort, please add your name here in alphabetical order, and choose a code name (2 or 3 chars).

Athanasios Anastasiou (AA)
Erik Sundvall (ES)
Pablo Pazos (PP)
Shinji Kobayashi (SK)
Diego Bosca (DB)
...

Artifact governance

Just to start with a clear view of what we have and in which state, each published artifact will be under the collaborator's name, because each one of us might have different versions (maybe structurally different, with different tweaks and fixes) of those artifacts. Then we will try to converge on a common version for each artifact type.

Please attach files to this page and link them in the sections below. Please add a small description to each file, like "what it represents" and if you have tweaked the format or fixed some problem with the format, please comment about that too.

XML schemas

Some community members have reported some issues with current schemas, here we will document those issues and try to solve them.

AA:

A Clinical Knowledge Manager (CKM) bug used to produce XML where the order of some elements was not preserved and therefore these documents were failing when validated against the published XSDs [FIXED]
A CKM bug used to produce XML with an additional <any_allowed> element that was not defined in the published XSDs [FIXED]
Failure to parse certain archetypes in XML with the error "Missing element error" on DV_CODED_TEXT elements ("cannot accept wildcard content CODE_PHRASE") [ACK / IN PROCESS ]
The published "Template.xsd" possibly needs to be reviewed as its structure does not seem to reflect the one intended for openEHR Templates [SEE COMMENT BELOW]
- Specifically, there are two outstanding issues:
  a) Concerning element classes defined within the current Template.xsd (such as "archetyped" / "ARCHETYPED", "content_item" / "CONTENT_ITEM" and others) and;
  b) Concerning the whole structure of the current Template.xsd.
- COMMENT: It is possible to obtain a working version of a Template by downloading & installing the Ocean Template Designer and then copying across the file [templateDesignerInstallDir]/Schemas/CompositionTemplate.xsd. That XSD contains a few abstract classes with common names to existing classes (such as "archetyped", "content_item" and others). These should not be considered to be relevant to the existing classes and the CompositionTemplate.xsd should be used as a stand-alone XML file.

ES:

TBD

PP:

xsd_load.groovy
- Code that loads the RM XSDs and validates a XML Composition instance
- I think there is a problem with the code, loading multiple XSDs, I'm gonna try to put all into one XSD and see how it does.

SK:

XML is not on the mainstream in Ruby.
However, Ruby can easily generate and parse XML or other serialisation formalism. Communication test or transform to other formalism would be a Ruby work.

DB:

ADL syntax is able to express more things than the XML syntax. I have detected differences mainly on domain types (assumed values, lists, etc.)

XML Composition instances

Some community members had created composition instances in XML format. Here we will try to join those efforts, publishing some samples, evaluating problems with current implementations and proposing possible solutions.

AA:

TBD
...

LiU (ES):

openEHR-composition-instances-LiU-2012-05-14.zip: A zip with Comoposition instances - may contain invalid data, do not use as a definite reference.
example-ehr-id.xml: An entire EHR entry containing the compositions in the "anna" directory of the above zip. They are wrapped in VERSIONED_OBJECTs that are weapped in an EHR object. One of the compositions also (in addition to the original) contains a slightly updated version of one composition. This file contains some nodes with the added "eee" namespace covering things (EHR root object etc) not included in the openEHR
Access to a test server where you can query similar documents (using AQL) can be granted upon request by contacting erik.sundvall@liu.se

PP:

I've created a valid dummy composition XML to test the schema validation.

SK:

Now, trying on Rails

DB:

Working on the generation of instances with random data (WIP)
Provided that we have an archetype and data available in any legacy XML format and its XSD, we can generate an XQuery to transform that data into RM-compliant XML instances. We can provide this transformation script for the test base cases.
Our opensource project EHRFlex can generate instances from the visual interfaces. (system is RM independent, but for the moment only full support for EN13606 archetypes exists)

Flat archetypes:

PP:

I'm working on archetype flattening, following indications made by Thomas (http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007023.html).
- My first flattened archetype: http://www.openehr.org/wiki/download/attachments/33619970/out.adl (I'll upload the flattener code soon)
The objective is to produce a piece of code that can take a set of archetypes and generate a set of flat archetypes exclusively for Compositions.
How I plan to do it: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012q2/007084.html
The result will be published here, and we can use those archetypes to generate RM instances in various serialized forms.
Added: initial proposal for a flattening algorithm of ADL 1.4 archetypes: http://www.openehr.org/wiki/pages/viewpage.action?pageId=35454983 (ideas are welcome)

Other artifacts:

Composition instances in other format, such as YAML, JSON

Queries and results

LiU (ES):

SELECT v/uid/value as composition_id, c/name/value as composition_title, c/context/start_time/value as comp_start_time, c/context/end_time/value as comp_end_time, c/context/health_care_facility/name as comp_facility, c/context/setting/defining_code/code_string as comp_setting FROM Ehr [uid=$current_ehr_uid] CONTAINS VERSION v CONTAINS COMPOSITION c
Results in a response like: encounter-query-result.xml (In our current demo that response is used by a HTML5/JavaScript/jQuery based overview GUI generated by code running on the client side.).