ADX connectathon report back

Hi all. I had promised Derek that I would share this email with the
group. Just remembered ....

Hi Derek

Here's a brief summary. A bit patchy because (to make matters worse)
I don't have my laptop with me here in Oslo which I used in Cleveland.
I'm also copying Andreea and Steven who were there with the PROMIS
system. Between you all you can put me right if my memory takes me
astray.

There were 3 systems represented in total. The openhie shared health
record (SHR), openhie hmis and the PROMIS system (used by PEPFAR in
Tanzania).

We tested:
1. openhie as datastructure content creator - the generated dsd's (we
tried 2 different dataset structure definitions) were tested
successfully against the gazelle schematron tester. Off-script we
also tested the schema generation and used this to validate content
from data content creators.

2. we successfully tested SHR and PROMIS as data content creators
using one of the 2 sample datasets - ie. the HIV dataset. Neither of
the systems had available malaria data so we were not able to test the
malaria dataset. The HMIS was also successfully tested as a content
creator (for both datasets) but I don't think that really counted
formally as it was the HMIS which in turn consumed the data.

3. we tested HMIS as a data content consumer of the content generated
by SHR, PROMIS (and itself)

4. PROMIS was originally registered as a content consumer, but
unfortunately they had not managed to get the functionality
implemented in time (a big release got in their way). So they
withdrew from that actor role.

So most of what we set out to achieve was achieved, albeit with much
too small a sample of systems, but hopefully we push that better next
time. The two areas we can say remain relatively untested are the
production of disaggregated data and the consumption of data content
from or by a system other than hmis.

There were a two issues which surfaced which should form the basis of CPs:

1. We need to revisit the documentation around the sample files in
the text. There are a number of places in the profile where we
liberally (and correctly) allow for xsd:any extensions. So we have
some attributes in our examples which illustrate this. Implementors
have taken these to be perhaps required and slavishly reproduced them.
It would make more sense if I could be more precise, but suffice to
see we need to add some explanatory text around these samples.
(always the danger of including examples in standards writing)

2. There was an issue which emerged (and took us a little by
surprise). The @id attribute on the Code in SDMX v2.1 is of type
IDTYPE. This causes problems as we find many code identifiers in our
use cases which do not fit this restriction (for example oids fail
validation because the IDTYPE doesn't permit full stops). I am really
not sure why they have done this as it doesn't make a lot of sense -
IDTYPE constrains uniqueness within the document, but where that
document contains a number of codelists there isn't a good case for
enforcing this uniqueness across lists for example. Anyway, its maybe
going to require a little thought. I don't have the solution off the
top of my head, but we will find one. It doesn't actually cause a
problem with the real world at either end - just the intermediate
subterranean world of the sdmx dsd.

Best i can do as report back for now. Hopefully others will chime in.

Hi Bob,

Thanks for sharing this with the openHMIS community.
Quick question: you are referring to a “next time”. Did you agreed on a date yet?

Cheers,

Matthieu

···

On Tuesday, 23 February 2016 14:03:15 UTC+1, Bob Jolliffe wrote:

Hi all. I had promised Derek that I would share this email with the

group. Just remembered …

Hi Derek

Here’s a brief summary. A bit patchy because (to make matters worse)

I don’t have my laptop with me here in Oslo which I used in Cleveland.

I’m also copying Andreea and Steven who were there with the PROMIS

system. Between you all you can put me right if my memory takes me

astray.

There were 3 systems represented in total. The openhie shared health

record (SHR), openhie hmis and the PROMIS system (used by PEPFAR in

Tanzania).

We tested:

  1. openhie as datastructure content creator - the generated dsd’s (we

tried 2 different dataset structure definitions) were tested

successfully against the gazelle schematron tester. Off-script we

also tested the schema generation and used this to validate content

from data content creators.

  1. we successfully tested SHR and PROMIS as data content creators

using one of the 2 sample datasets - ie. the HIV dataset. Neither of

the systems had available malaria data so we were not able to test the

malaria dataset. The HMIS was also successfully tested as a content

creator (for both datasets) but I don’t think that really counted

formally as it was the HMIS which in turn consumed the data.

  1. we tested HMIS as a data content consumer of the content generated

by SHR, PROMIS (and itself)

  1. PROMIS was originally registered as a content consumer, but

unfortunately they had not managed to get the functionality

implemented in time (a big release got in their way). So they

withdrew from that actor role.

So most of what we set out to achieve was achieved, albeit with much

too small a sample of systems, but hopefully we push that better next

time. The two areas we can say remain relatively untested are the

production of disaggregated data and the consumption of data content

from or by a system other than hmis.

There were a two issues which surfaced which should form the basis of CPs:

  1. We need to revisit the documentation around the sample files in

the text. There are a number of places in the profile where we

liberally (and correctly) allow for xsd:any extensions. So we have

some attributes in our examples which illustrate this. Implementors

have taken these to be perhaps required and slavishly reproduced them.

It would make more sense if I could be more precise, but suffice to

see we need to add some explanatory text around these samples.

(always the danger of including examples in standards writing)

  1. There was an issue which emerged (and took us a little by

surprise). The @id attribute on the Code in SDMX v2.1 is of type

IDTYPE. This causes problems as we find many code identifiers in our

use cases which do not fit this restriction (for example oids fail

validation because the IDTYPE doesn’t permit full stops). I am really

not sure why they have done this as it doesn’t make a lot of sense -

IDTYPE constrains uniqueness within the document, but where that

document contains a number of codelists there isn’t a good case for

enforcing this uniqueness across lists for example. Anyway, its maybe

going to require a little thought. I don’t have the solution off the

top of my head, but we will find one. It doesn’t actually cause a

problem with the real world at either end - just the intermediate

subterranean world of the sdmx dsd.

Best i can do as report back for now. Hopefully others will chime in.