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:

The focus:

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.

  1. be sure that RM XSDs are correct compared to the specs.
  2. 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.)
  3. 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.
  4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps.
  5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results.
  6. 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).

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:

ES:

PP:

SK:

DB:

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:

LiU (ES):

PP:

SK:

DB:

Flat archetypes:

PP:

Other artifacts:

Composition instances in other format, such as YAML, JSON

Queries and results

LiU (ES):