Hi all. I had promised Derek that I would share this email with the
group. Just remembered ....
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
There were 3 systems represented in total. The openhie shared health
record (SHR), openhie hmis and the PROMIS system (used by PEPFAR in
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.