Test data set identifiers and organisation

Conformance Issue list
1

All,
I have been looking at the question of organising the _resources area more systematically for the openEHR copy of the EhrBase test framework.

Today it looks like this:

minimal_obs_templates
minimal_obs_templates712×888 98.9 KB

So all those files in the first group really belong under the template Minimal_observation. I thought about making a directory called that, and pushing all the files down into it. In some cases we might want to improve the name, but a name like Minimal_observation seems ok to me, unless we want more than one kind of ‘minimal observation’.

Anyway, elsewhere there are just data files whose name makes it obvious (we hope) which templates they are based on. E.g.

minimal_obs_data_sets
minimal_obs_data_sets620×640 67.9 KB

So good names for templates are important. One thing we could do here is to use ADL2 style names, i.e. openEHR-EHR-COMPOSITION.minimal_observation.v1 and similar - which makes it a bit clearer that the RM structure is in fact a COMPOSITION (nearly always) but the design intent is a ‘minimal composition’. This might be a step too far, and maybe current tools will choke on it.

I have asked @pablo if he has better ideas.

The big picture problem: we now have diverging code bases of the openEHR and EhrBase versions of the Test (robot) files. I have checked in Git and there are many small changes on the EhrBase _resources area from @wlad . @birger.haarbrandt - I think we need to consider the consequences of this more seriously!

2

Hi Tom,

can you elaborate on this part?

The big picture problem: we now have diverging code bases of the openEHR and EhrBase versions of the Test (robot) files. I have checked in Git and there are many small changes on the EhrBase _resources area from @wlad . @birger.haarbrandt - I think we need to consider the consequences of this more seriously!

I think that we need to work with a fork and occasional merges in the future as the purposes will be a bit different. But I’m very open for any suggestions how can make this work

3

We didn’t do a fork in the end, just a copy. Because we have changed all the identifiers on the test cases from the original, and reformatted into Asciidoctor markdown from Github markdown, I am not sure that we would have been able to succeed with much automatic merging.

Main problem is that this process has taken (much) longer than I expected, so of course work continues in EhrBase (entirely normal!). But we need to think strategically: Vita will be like any other company that has to show it can pass the openEHR conformance framework. It would obviously be much easier for Vita to adopt the openEHR core, and treat its extras (that @pablo stripped out when he provided the copy) as additions.

Right now we have two conformance code bases to maintain.