Introductions

[bobj]

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

HIV_Indicators.cql (13.9 KB)

measure-hiv-indicators.xml (8.88 KB)

measurereport-data-sample.xml (974 Bytes)

data-sample.xml (15.7 KB)

···

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi Carl and all

Hope you are enjoying first day. I'd like to make sure you all get to
meet Ismael from HISP TZ as you move forward with connectathon. I
don't think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh backend
access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR "rendition" of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

[bobj]

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful
implementation also seems to pre-suppose such a bundle).

···

On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Hi Carl and all
>
> Hope you are enjoying first day. I'd like to make sure you all get to
> meet Ismael from HISP TZ as you move forward with connectathon. I
> don't think Ismael has been that involved with ADX work but he is
> quite familiar with DHIS2 and API and (importantly) he has ssh backend
> access to the sandbox at openhie.dhis2.org.
>
> Ismael, I have explained in separate mail that James has setup
> metadata for an ADX dataset on the linode in order to give early
> exposure to the upcoming new ADX HIV profile from IHE.
>
> Carl and Bryn have been working on a FHIR "rendition" of ADX and I
> think will be interested to see how this ADX HIV dataset might look
> using that form.
>
> Enjoy.
>
> Bob.

[Kariuki_James_M_CDC]

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

···

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Hi Carl and all
>
> Hope you are enjoying first day. I'd like to make sure you all get
> to meet Ismael from HISP TZ as you move forward with connectathon.
> I don't think Ismael has been that involved with ADX work but he is
> quite familiar with DHIS2 and API and (importantly) he has ssh
> backend access to the sandbox at openhie.dhis2.org.
>
> Ismael, I have explained in separate mail that James has setup
> metadata for an ADX dataset on the linode in order to give early
> exposure to the upcoming new ADX HIV profile from IHE.
>
> Carl and Bryn have been working on a FHIR "rendition" of ADX and I
> think will be interested to see how this ADX HIV dataset might look
> using that form.
>
> Enjoy.
>
> Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl_Leitner1]

Hi all,

I am in meetings for the next few hours so won’t have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:

https://www.hl7.org/fhir/profiling.html

This should let us say “use this value set for these disaggreators” etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven’t done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the “ragged right” to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

···

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) wmo7@cdc.gov wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.

I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,

James

-----Original Message-----

From: open-hmis@googlegroups.com open-hmis@googlegroups.com On Behalf Of Bob Jolliffe

Sent: Friday, September 21, 2018 7:13 AM

To: Open HMIS open-hmis@googlegroups.com

Subject: Re: Introductions

Begging the question …

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).

On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:

1. I can’t see the period or orgUnit dimensions on the data sample.

I think its important to see how this will work.

2. I don’t see where the dimensions get bound to codelists/valuesets

3. It seems like the way of handling multi-dimensionality

(stratification?) is to concatenate individual dimensions with a

joining ‘:’. This looks ugly (requiring a parser within a parser)

and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can

comment on above.

In a general sense I am a little uneasy. As I said yesterday I am

personally not fond of, or wedded to, sdmx. It was a means to an

end. I would willingly jump to something simpler. James or Derek

might have their own affections. The concern I have, looking back

over these examples, is that I am not really convinced that this is

any less obtuse than sdmx. For the moment, as per my 3 quick q’s

above, the examples are incomplete so hard to say. Besides the fact

that it is FHIR (which I understand brings with it an inherent warm

glow and probably will attract funding) I still fail to see much

attraction.

The measure report data sample is certainly far uglier than adx data

message. So there is no way that I would support replacing the

existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx

data message could be derived from a FHIR Measure resource. I suspect

these examples were taken by running xslt against existing sdmx dsd

which is grand, but it looks like the underlying codelists/valuesets

were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which

brought together the valuesets required for a particular dataset

(orgunits, dataelements, sex, age_group etc). I had mistakenly

thought these was somehow defined in the Measure but it looks like

they are not. (I had raised the possibility of defining such a bundle

last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR

stuff could provide a kind of drop-in replacement for the SDMX dsd, in

which case I was happily prepared to embrace it. But I am not seeing

that at all. I think quite a few things to resolve. Maybe Derek can

grant us more time.

Cheers

Bob

---------- Forwarded message ---------

From: Bryn Rhodes bryn@databaseconsultinggroup.com

Date: Fri, 3 Aug 2018 at 19:11

Subject: Re: Introductions

To: Bob Jolliffe bobjolliffe@gmail.com

Cc: Carl Leitner litlfred@gmail.com, Kariuki, James M.

(CDC/CGH/DGHA) wmo7@cdc.gov, ismail yusuf

ismailkoleleni@gmail.com, Carl Fourie carl.fourie@jembi.org

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and

I worked on a mapping that we think will work quite well. The Jembe

team worked on an ADX->MeasureReport mediator and we made a lot of

progress on representing the indicator definitions in FHIR and CQL.

I’ve attached examples, please note these are rough, but this is the

direction we’re heading. We’re hoping to make more progress tomorrow.

Regards,

Bryn Rhodes

bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl and all

Hope you are enjoying first day. I’d like to make sure you all get

to meet Ismael from HISP TZ as you move forward with connectathon.

I don’t think Ismael has been that involved with ADX work but he is

quite familiar with DHIS2 and API and (importantly) he has ssh

backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup

metadata for an ADX dataset on the linode in order to give early

exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR “rendition” of ADX and I

think will be interested to see how this ADX HIV dataset might look

using that form.

Enjoy.

Bob.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[bobj]

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)

···

On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:

Hi all,

I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
  Profiling - FHIR v5.0.0

This should let us say "use this value set for these disaggreators" etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Hi all
>
> I am just forwarding these snippets which were shared after the openHIE meetup.
>
> I have a couple of questions/observations:
> 1. I can't see the period or orgUnit dimensions on the data sample.
> I think its important to see how this will work.
> 2. I don't see where the dimensions get bound to codelists/valuesets
> 3. It seems like the way of handling multi-dimensionality
> (stratification?) is to concatenate individual dimensions with a
> joining ':'. This looks ugly (requiring a parser within a parser)
> and a step backwards towards categorycombooptions.
>
> Maybe some of those who were involved creating these examples can
> comment on above.
>
> In a general sense I am a little uneasy. As I said yesterday I am
> personally not fond of, or wedded to, sdmx. It was a means to an
> end. I would willingly jump to something simpler. James or Derek
> might have their own affections. The concern I have, looking back
> over these examples, is that I am not really convinced that this is
> any less obtuse than sdmx. For the moment, as per my 3 quick q's
> above, the examples are incomplete so hard to say. Besides the fact
> that it is FHIR (which I understand brings with it an inherent warm
> glow and probably will attract funding) I still fail to see much
> attraction.
>
> The measure report data sample is certainly far uglier than adx data
> message. So there is no way that I would support replacing the
> existing adx data message, though I am not wedded to the sdmx dsd.
>
> It remains to be seen whether an xsd schema and schematron for an adx
> data message could be derived from a FHIR Measure resource. I suspect
> these examples were taken by running xslt against existing sdmx dsd
> which is grand, but it looks like the underlying codelists/valuesets
> were simply picked from the dsd but otherwise clobbered.
>
> It looks like you would still need a FHIR bundle of some sort which
> brought together the valuesets required for a particular dataset
> (orgunits, dataelements, sex, age_group etc). I had mistakenly
> thought these was somehow defined in the Measure but it looks like
> they are not. (I had raised the possibility of defining such a bundle
> last year in Naples)
>
> So lots of questions. I was kind of hoping yesterday that the FHIR
> stuff could provide a kind of drop-in replacement for the SDMX dsd, in
> which case I was happily prepared to embrace it. But I am not seeing
> that at all. I think quite a few things to resolve. Maybe Derek can
> grant us more time.
>
> Cheers
> Bob
>
> ---------- Forwarded message ---------
> From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
> Date: Fri, 3 Aug 2018 at 19:11
> Subject: Re: Introductions
> To: Bob Jolliffe <bobjolliffe@gmail.com>
> Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
> (CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
> <ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>
>
>
> Hi Bob,
>
> We made some good progress today, I met Ismail and James, Pierre, and
> I worked on a mapping that we think will work quite well. The Jembe
> team worked on an ADX->MeasureReport mediator and we made a lot of
> progress on representing the indicator definitions in FHIR and CQL.
>
> I've attached examples, please note these are _rough_, but this is the
> direction we're heading. We're hoping to make more progress tomorrow.
>
> Regards,
> Bryn Rhodes
> bryn@databaseconsultinggroup.com
>
>
> On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
> >
> > Hi Carl and all
> >
> > Hope you are enjoying first day. I'd like to make sure you all get
> > to meet Ismael from HISP TZ as you move forward with connectathon.
> > I don't think Ismael has been that involved with ADX work but he is
> > quite familiar with DHIS2 and API and (importantly) he has ssh
> > backend access to the sandbox at openhie.dhis2.org.
> >
> > Ismael, I have explained in separate mail that James has setup
> > metadata for an ADX dataset on the linode in order to give early
> > exposure to the upcoming new ADX HIV profile from IHE.
> >
> > Carl and Bryn have been working on a FHIR "rendition" of ADX and I
> > think will be interested to see how this ADX HIV dataset might look
> > using that form.
> >
> > Enjoy.
> >
> > Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bobj]

Hi James

Yes I think so too. Though as Carl has pointed out, it might be that
what I naively calling a "bundle of valuesets" can be captured more
neatly in a FHIR profile.

I can imagine it might take the form of a layered approach. The first
layer being a profile that says there should be valuesets (somewhere)
for core concepts of of dataElement, orgUnit. Country specific (and
dataset specific within countries) might then profile the profile by
adding additional valuesets (eg age group and sex), and potentilly
adding content to the abstract orgUnit and dataelement valuesets etc

···

On Fri, 21 Sep 2018 at 12:42, Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Hi all
>
> I am just forwarding these snippets which were shared after the openHIE meetup.
>
> I have a couple of questions/observations:
> 1. I can't see the period or orgUnit dimensions on the data sample.
> I think its important to see how this will work.
> 2. I don't see where the dimensions get bound to codelists/valuesets
> 3. It seems like the way of handling multi-dimensionality
> (stratification?) is to concatenate individual dimensions with a
> joining ':'. This looks ugly (requiring a parser within a parser)
> and a step backwards towards categorycombooptions.
>
> Maybe some of those who were involved creating these examples can
> comment on above.
>
> In a general sense I am a little uneasy. As I said yesterday I am
> personally not fond of, or wedded to, sdmx. It was a means to an
> end. I would willingly jump to something simpler. James or Derek
> might have their own affections. The concern I have, looking back
> over these examples, is that I am not really convinced that this is
> any less obtuse than sdmx. For the moment, as per my 3 quick q's
> above, the examples are incomplete so hard to say. Besides the fact
> that it is FHIR (which I understand brings with it an inherent warm
> glow and probably will attract funding) I still fail to see much
> attraction.
>
> The measure report data sample is certainly far uglier than adx data
> message. So there is no way that I would support replacing the
> existing adx data message, though I am not wedded to the sdmx dsd.
>
> It remains to be seen whether an xsd schema and schematron for an adx
> data message could be derived from a FHIR Measure resource. I suspect
> these examples were taken by running xslt against existing sdmx dsd
> which is grand, but it looks like the underlying codelists/valuesets
> were simply picked from the dsd but otherwise clobbered.
>
> It looks like you would still need a FHIR bundle of some sort which
> brought together the valuesets required for a particular dataset
> (orgunits, dataelements, sex, age_group etc). I had mistakenly
> thought these was somehow defined in the Measure but it looks like
> they are not. (I had raised the possibility of defining such a bundle
> last year in Naples)
>
> So lots of questions. I was kind of hoping yesterday that the FHIR
> stuff could provide a kind of drop-in replacement for the SDMX dsd, in
> which case I was happily prepared to embrace it. But I am not seeing
> that at all. I think quite a few things to resolve. Maybe Derek can
> grant us more time.
>
> Cheers
> Bob
>
> ---------- Forwarded message ---------
> From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
> Date: Fri, 3 Aug 2018 at 19:11
> Subject: Re: Introductions
> To: Bob Jolliffe <bobjolliffe@gmail.com>
> Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
> (CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
> <ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>
>
>
> Hi Bob,
>
> We made some good progress today, I met Ismail and James, Pierre, and
> I worked on a mapping that we think will work quite well. The Jembe
> team worked on an ADX->MeasureReport mediator and we made a lot of
> progress on representing the indicator definitions in FHIR and CQL.
>
> I've attached examples, please note these are _rough_, but this is the
> direction we're heading. We're hoping to make more progress tomorrow.
>
> Regards,
> Bryn Rhodes
> bryn@databaseconsultinggroup.com
>
>
> On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
> >
> > Hi Carl and all
> >
> > Hope you are enjoying first day. I'd like to make sure you all get
> > to meet Ismael from HISP TZ as you move forward with connectathon.
> > I don't think Ismael has been that involved with ADX work but he is
> > quite familiar with DHIS2 and API and (importantly) he has ssh
> > backend access to the sandbox at openhie.dhis2.org.
> >
> > Ismael, I have explained in separate mail that James has setup
> > metadata for an ADX dataset on the linode in order to give early
> > exposure to the upcoming new ADX HIV profile from IHE.
> >
> > Carl and Bryn have been working on a FHIR "rendition" of ADX and I
> > think will be interested to see how this ADX HIV dataset might look
> > using that form.
> >
> > Enjoy.
> >
> > Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[derek.ritz]

Hi all.
Please, let’s commit to using the time we need to use in order to come up with the proposal we can all support. I will happily leverage whatever influence I have as an IHE QRPH PLanning co-chair to give us some wiggle room. Also, I will be attending the October meeting in Chicago and so can advocate in-person for whatever consensus-based work item or white paper proposal we come up with.

James – given what Carl is suggesting, we could consider targeting a profile to replace DSD with a MeasureReport definition (rather than a white paper). I think our decision of which option to favour should depend on the relative maturity of MeasureReport vs DSD. If MeasureReport is still too nascent to support a profile, then a white paper should be preferred, i think.

I tend to agree with James and Bob regarding favouring, at this juncture, the existing ADX message format. Carl, I fully appreciate the benefits of being able to engage with and leverage the FHIR community – but we would be unwise, in my view, to discount the value of the community of support we’ve already established within our DHIS2 and PEPFAR communities around the current ADX message format. For our LMIC-focused use cases, these are crucial communities.

Lastly – I would like to suggest that the development of CQL “maps” that can be used to express reportable data elements in terms of operations on underlying FHIR resources is, to my mind, a thing of value and importance all by itself. I’d love to see this proposed as a profile work item because of how valuable it would be as an “upstream foundation” of so many of QRPH’s other research and quality-measure profiles. Just a thought…

Warmest regards,

Derek

···

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[Kariuki_James_M_CDC]

Hi Derek,

Derek, If we start working on a white paper and prototype FHIR pieces that are a good replacement for the DSD (describes the aggregate metadata well and produces
and ADX message), is it possible to convert this to profile in the middle of the cycle?

Please see my comment inline on options for replacing DSD.

Thanks

James

On Behalf Of Derek Ritz

···

Hi all.

Please, let’s commit to using the time we need to use in order to come up with the proposal we can all support. I will happily leverage whatever influence I have as an IHE QRPH PLanning co-chair to give us some wiggle room. Also, I will
be attending the October meeting in Chicago and so can advocate in-person for whatever consensus-based work item or white paper proposal we come up with.

James – given what Carl is suggesting, we could consider targeting a
profile to replace DSD with a MeasureReport definition (rather than a white paper). I think our decision of which option to favour should depend on the relative maturity of MeasureReport vs DSD. If MeasureReport is still too nascent to support a profile,
then a white paper should be preferred, i think.

I think a key considerations is whether we can derive validation schemas (XSD and schematron) for an ADX data message from a FHIR Measure resource. Given the
recent development by Bob to generate validation schema for various data sets, I think it is important to leverage this process as it was one of the drive behind ADX version 2.1.

I agree that the maturity of FHIR resources that we use to replace the SDMX based DSD and being able to derive the validation schema from the FHIR based “DSD”
created are key to deciding whether we submit a profile or white paper proposal.

I tend to agree with James and Bob regarding favouring, at this juncture, the existing ADX message format. Carl, I fully appreciate the benefits of being able to engage with and leverage the FHIR community – but we would be unwise, in
my view, to discount the value of the community of support we’ve already established within our DHIS2 and PEPFAR communities around the current ADX message format. For our LMIC-focused use cases, these are crucial communities.

Lastly – I would like to suggest that the development of CQL “maps” that can be used to express reportable data elements in terms of operations on underlying FHIR resources is, to my mind, a thing of value and importance all by itself.
I’d love to see this proposed as a profile work item because of how valuable it would be as an “upstream foundation” of so many of QRPH’s other research and quality-measure profiles. Just a thought…

Warmest regards,

Derek

On Fri, Sep 21, 2018 at 8:24 AM Carl Leitner litlfred@gmail.com wrote:

Hi all,

I am in meetings for the next few hours so won’t have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:

https://www.hl7.org/fhir/profiling.html

This should let us say “use this value set for these disaggreators” etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven’t done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin
into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the “ragged right” to see if the
proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) wmo7@cdc.gov wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com open-hmis@googlegroups.com On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS open-hmis@googlegroups.com
Subject: Re: Introductions

Begging the question …

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:

1. I can’t see the period or orgUnit dimensions on the data sample.
   I think its important to see how this will work.
2. I don’t see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
   (stratification?) is to concatenate individual dimensions with a
   joining ‘:’. This looks ugly (requiring a parser within a parser)
   and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q’s
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes bryn@databaseconsultinggroup.com
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe bobjolliffe@gmail.com
Cc: Carl Leitner litlfred@gmail.com, Kariuki, James M.
(CDC/CGH/DGHA) wmo7@cdc.gov, ismail yusuf

ismailkoleleni@gmail.com, Carl Fourie carl.fourie@jembi.org

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I’ve attached examples, please note these are rough, but this is the
direction we’re heading. We’re hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl and all

Hope you are enjoying first day. I’d like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don’t think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at
openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR “rendition” of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl_Leitner2]

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).
  
If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

···

On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)
On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:

Hi all,

I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
Profiling - FHIR v5.0.0

This should let us say "use this value set for these disaggreators" etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi Carl and all

Hope you are enjoying first day. I'd like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don't think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR "rendition" of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl_Leitner2]

First off, I am agreed that the ADX message is prettier than anything we get out of FHIR natively.

That being said, I think we will have increased uptake on ADX if we (eventually) have a FHIR representation as there are a number of FHIR libraries that will allow programmatic generation of “mADX/ADX on FHIR” messages and leverage the FHIR ecosystem. To be clear, I am not proposing that any of the ADX work goes away w/ mADX and one constraint we would have on mADX is that there is a clear bijection of messages between ADX and mADX. Doing so will allow us to preserve all the existing ADX work, in particular for those systems producing or consuming ADX messages. This should be viewed as providing an alternate and equivalent message format.

Cheers,

-carl

···

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[derek.ritz]

james – i’m sure we could convert from white paper to profile… it’d be at the pleasure of the committee to do so.

···

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[bobj]

Carl I think the current proposal needs more than light editing.

I don't think it correctly states the problem as it is but jumps
directly to MeasureReport as the "solution" to a json version of ADX
for a bundle of reasons which I don't think are necessarily valid.
And if it is just to get to a json format we know there is an easier
way.

The problem as I understand it is that we currently only have SDMX to
represent the structural metadata of a data message, and SDMX (unlike
the data message of adx) is complex and does not enjoy much traction
in the world. Consequently, whereas we have seen some uptake of the
ADX data message in the world, there is very little interest in the
exchange of SDMX DSD. And no known instances of it having happened in
the wild.

We would like to explore whether FHIR can provide us with a more
palatable way to achieve the functionality of the DSD. Perhaps this
is using a Measure/MeasureReport or perhaps something more bespoke.
Somewhere between a bundle and a profile. I don't think we have that
answer at this point.

I am not sure if these motivations are really captured in the existing
proposal. But maybe let us at least try to describe the problem as it
is and leave the way open for the committee to pursue a solution.

Cheers
Bob

···

On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).

If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

> On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Thanks Carl. Agree. But do you see these as two proposals or one?
>
> (sorry if I forgot about thread re colons)
> On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:
>>
>> Hi all,
>>
>> I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
>> Profiling - FHIR v5.0.0
>>
>> This should let us say "use this value set for these disaggreators" etc.
>>
>> My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.
>>
>> If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)
>>
>> Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).
>>
>>
>>
>>
>> Cheers,
>> -carl
>>
>> On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:
>>>
>>> Hi Bob and all,
>>>
>>> We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
>>> I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.
>>>
>>> Thanks,
>>> James
>>>
>>> -----Original Message-----
>>> From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
>>> Sent: Friday, September 21, 2018 7:13 AM
>>> To: Open HMIS <open-hmis@googlegroups.com>
>>> Subject: Re: Introductions
>>>
>>> Begging the question ....
>>>
>>> Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?
>>>
>>> The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
>>> On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>>>>
>>>> Hi all
>>>>
>>>> I am just forwarding these snippets which were shared after the openHIE meetup.
>>>>
>>>> I have a couple of questions/observations:
>>>> 1. I can't see the period or orgUnit dimensions on the data sample.
>>>> I think its important to see how this will work.
>>>> 2. I don't see where the dimensions get bound to codelists/valuesets
>>>> 3. It seems like the way of handling multi-dimensionality
>>>> (stratification?) is to concatenate individual dimensions with a
>>>> joining ':'. This looks ugly (requiring a parser within a parser)
>>>> and a step backwards towards categorycombooptions.
>>>>
>>>> Maybe some of those who were involved creating these examples can
>>>> comment on above.
>>>>
>>>> In a general sense I am a little uneasy. As I said yesterday I am
>>>> personally not fond of, or wedded to, sdmx. It was a means to an
>>>> end. I would willingly jump to something simpler. James or Derek
>>>> might have their own affections. The concern I have, looking back
>>>> over these examples, is that I am not really convinced that this is
>>>> any less obtuse than sdmx. For the moment, as per my 3 quick q's
>>>> above, the examples are incomplete so hard to say. Besides the fact
>>>> that it is FHIR (which I understand brings with it an inherent warm
>>>> glow and probably will attract funding) I still fail to see much
>>>> attraction.
>>>>
>>>> The measure report data sample is certainly far uglier than adx data
>>>> message. So there is no way that I would support replacing the
>>>> existing adx data message, though I am not wedded to the sdmx dsd.
>>>>
>>>> It remains to be seen whether an xsd schema and schematron for an adx
>>>> data message could be derived from a FHIR Measure resource. I suspect
>>>> these examples were taken by running xslt against existing sdmx dsd
>>>> which is grand, but it looks like the underlying codelists/valuesets
>>>> were simply picked from the dsd but otherwise clobbered.
>>>>
>>>> It looks like you would still need a FHIR bundle of some sort which
>>>> brought together the valuesets required for a particular dataset
>>>> (orgunits, dataelements, sex, age_group etc). I had mistakenly
>>>> thought these was somehow defined in the Measure but it looks like
>>>> they are not. (I had raised the possibility of defining such a bundle
>>>> last year in Naples)
>>>>
>>>> So lots of questions. I was kind of hoping yesterday that the FHIR
>>>> stuff could provide a kind of drop-in replacement for the SDMX dsd, in
>>>> which case I was happily prepared to embrace it. But I am not seeing
>>>> that at all. I think quite a few things to resolve. Maybe Derek can
>>>> grant us more time.
>>>>
>>>> Cheers
>>>> Bob
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
>>>> Date: Fri, 3 Aug 2018 at 19:11
>>>> Subject: Re: Introductions
>>>> To: Bob Jolliffe <bobjolliffe@gmail.com>
>>>> Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
>>>> (CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
>>>> <ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>
>>>>
>>>>
>>>> Hi Bob,
>>>>
>>>> We made some good progress today, I met Ismail and James, Pierre, and
>>>> I worked on a mapping that we think will work quite well. The Jembe
>>>> team worked on an ADX->MeasureReport mediator and we made a lot of
>>>> progress on representing the indicator definitions in FHIR and CQL.
>>>>
>>>> I've attached examples, please note these are _rough_, but this is the
>>>> direction we're heading. We're hoping to make more progress tomorrow.
>>>>
>>>> Regards,
>>>> Bryn Rhodes
>>>> bryn@databaseconsultinggroup.com
>>>>
>>>>
>>>> On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>>>>>
>>>>> Hi Carl and all
>>>>>
>>>>> Hope you are enjoying first day. I'd like to make sure you all get
>>>>> to meet Ismael from HISP TZ as you move forward with connectathon.
>>>>> I don't think Ismael has been that involved with ADX work but he is
>>>>> quite familiar with DHIS2 and API and (importantly) he has ssh
>>>>> backend access to the sandbox at openhie.dhis2.org.
>>>>>
>>>>> Ismael, I have explained in separate mail that James has setup
>>>>> metadata for an ADX dataset on the linode in order to give early
>>>>> exposure to the upcoming new ADX HIV profile from IHE.
>>>>>
>>>>> Carl and Bryn have been working on a FHIR "rendition" of ADX and I
>>>>> think will be interested to see how this ADX HIV dataset might look
>>>>> using that form.
>>>>>
>>>>> Enjoy.
>>>>>
>>>>> Bob.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Carl_Leitner2]

Agreed on what you suggest - I think we may just have a different definition of light editing

Cheers,
-carl

···

On Sep 21, 2018, at 12:16 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Carl I think the current proposal needs more than light editing.

I don't think it correctly states the problem as it is but jumps
directly to MeasureReport as the "solution" to a json version of ADX
for a bundle of reasons which I don't think are necessarily valid.
And if it is just to get to a json format we know there is an easier
way.

The problem as I understand it is that we currently only have SDMX to
represent the structural metadata of a data message, and SDMX (unlike
the data message of adx) is complex and does not enjoy much traction
in the world. Consequently, whereas we have seen some uptake of the
ADX data message in the world, there is very little interest in the
exchange of SDMX DSD. And no known instances of it having happened in
the wild.

We would like to explore whether FHIR can provide us with a more
palatable way to achieve the functionality of the DSD. Perhaps this
is using a Measure/MeasureReport or perhaps something more bespoke.
Somewhere between a bundle and a profile. I don't think we have that
answer at this point.

I am not sure if these motivations are really captured in the existing
proposal. But maybe let us at least try to describe the problem as it
is and leave the way open for the committee to pursue a solution.

Cheers
Bob
On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).

If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)
On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:

Hi all,

I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
Profiling - FHIR v5.0.0

This should let us say "use this value set for these disaggreators" etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi Carl and all

Hope you are enjoying first day. I'd like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don't think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR "rendition" of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bobj]

I would retain section 5.3 ... (almost). And also retain the nod to 5.4.

That would make the proposal simpler.

···

On Fri, 21 Sep 2018 at 17:26, Carl Leitner <litlfred@ibiblio.org> wrote:

Agreed on what you suggest - I think we may just have a different definition of light editing

Cheers,
-carl

> On Sep 21, 2018, at 12:16 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Carl I think the current proposal needs more than light editing.
>
> I don't think it correctly states the problem as it is but jumps
> directly to MeasureReport as the "solution" to a json version of ADX
> for a bundle of reasons which I don't think are necessarily valid.
> And if it is just to get to a json format we know there is an easier
> way.
>
> The problem as I understand it is that we currently only have SDMX to
> represent the structural metadata of a data message, and SDMX (unlike
> the data message of adx) is complex and does not enjoy much traction
> in the world. Consequently, whereas we have seen some uptake of the
> ADX data message in the world, there is very little interest in the
> exchange of SDMX DSD. And no known instances of it having happened in
> the wild.
>
> We would like to explore whether FHIR can provide us with a more
> palatable way to achieve the functionality of the DSD. Perhaps this
> is using a Measure/MeasureReport or perhaps something more bespoke.
> Somewhere between a bundle and a profile. I don't think we have that
> answer at this point.
>
> I am not sure if these motivations are really captured in the existing
> proposal. But maybe let us at least try to describe the problem as it
> is and leave the way open for the committee to pursue a solution.
>
> Cheers
> Bob
> On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:
>>
>> Hi,
>> I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.
>>
>> I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).
>>
>> If we go this route, the draft proposal would only need some light edits and I can get this out today.
>>
>> Doe this sound good to everyone?
>>
>> Cheers,
>> -carl
>>
>>
>>> On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>>>
>>> Thanks Carl. Agree. But do you see these as two proposals or one?
>>>
>>> (sorry if I forgot about thread re colons)
>>> On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
>>>> Profiling - FHIR v5.0.0
>>>>
>>>> This should let us say "use this value set for these disaggreators" etc.
>>>>
>>>> My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.
>>>>
>>>> If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)
>>>>
>>>> Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).
>>>>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> -carl
>>>>
>>>> On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:
>>>>>
>>>>> Hi Bob and all,
>>>>>
>>>>> We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
>>>>> I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.
>>>>>
>>>>> Thanks,
>>>>> James
>>>>>
>>>>> -----Original Message-----
>>>>> From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
>>>>> Sent: Friday, September 21, 2018 7:13 AM
>>>>> To: Open HMIS <open-hmis@googlegroups.com>
>>>>> Subject: Re: Introductions
>>>>>
>>>>> Begging the question ....
>>>>>
>>>>> Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?
>>>>>
>>>>> The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
>>>>> On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> I am just forwarding these snippets which were shared after the openHIE meetup.
>>>>>>
>>>>>> I have a couple of questions/observations:
>>>>>> 1. I can't see the period or orgUnit dimensions on the data sample.
>>>>>> I think its important to see how this will work.
>>>>>> 2. I don't see where the dimensions get bound to codelists/valuesets
>>>>>> 3. It seems like the way of handling multi-dimensionality
>>>>>> (stratification?) is to concatenate individual dimensions with a
>>>>>> joining ':'. This looks ugly (requiring a parser within a parser)
>>>>>> and a step backwards towards categorycombooptions.
>>>>>>
>>>>>> Maybe some of those who were involved creating these examples can
>>>>>> comment on above.
>>>>>>
>>>>>> In a general sense I am a little uneasy. As I said yesterday I am
>>>>>> personally not fond of, or wedded to, sdmx. It was a means to an
>>>>>> end. I would willingly jump to something simpler. James or Derek
>>>>>> might have their own affections. The concern I have, looking back
>>>>>> over these examples, is that I am not really convinced that this is
>>>>>> any less obtuse than sdmx. For the moment, as per my 3 quick q's
>>>>>> above, the examples are incomplete so hard to say. Besides the fact
>>>>>> that it is FHIR (which I understand brings with it an inherent warm
>>>>>> glow and probably will attract funding) I still fail to see much
>>>>>> attraction.
>>>>>>
>>>>>> The measure report data sample is certainly far uglier than adx data
>>>>>> message. So there is no way that I would support replacing the
>>>>>> existing adx data message, though I am not wedded to the sdmx dsd.
>>>>>>
>>>>>> It remains to be seen whether an xsd schema and schematron for an adx
>>>>>> data message could be derived from a FHIR Measure resource. I suspect
>>>>>> these examples were taken by running xslt against existing sdmx dsd
>>>>>> which is grand, but it looks like the underlying codelists/valuesets
>>>>>> were simply picked from the dsd but otherwise clobbered.
>>>>>>
>>>>>> It looks like you would still need a FHIR bundle of some sort which
>>>>>> brought together the valuesets required for a particular dataset
>>>>>> (orgunits, dataelements, sex, age_group etc). I had mistakenly
>>>>>> thought these was somehow defined in the Measure but it looks like
>>>>>> they are not. (I had raised the possibility of defining such a bundle
>>>>>> last year in Naples)
>>>>>>
>>>>>> So lots of questions. I was kind of hoping yesterday that the FHIR
>>>>>> stuff could provide a kind of drop-in replacement for the SDMX dsd, in
>>>>>> which case I was happily prepared to embrace it. But I am not seeing
>>>>>> that at all. I think quite a few things to resolve. Maybe Derek can
>>>>>> grant us more time.
>>>>>>
>>>>>> Cheers
>>>>>> Bob
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
>>>>>> Date: Fri, 3 Aug 2018 at 19:11
>>>>>> Subject: Re: Introductions
>>>>>> To: Bob Jolliffe <bobjolliffe@gmail.com>
>>>>>> Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
>>>>>> (CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
>>>>>> <ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>
>>>>>>
>>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>> We made some good progress today, I met Ismail and James, Pierre, and
>>>>>> I worked on a mapping that we think will work quite well. The Jembe
>>>>>> team worked on an ADX->MeasureReport mediator and we made a lot of
>>>>>> progress on representing the indicator definitions in FHIR and CQL.
>>>>>>
>>>>>> I've attached examples, please note these are _rough_, but this is the
>>>>>> direction we're heading. We're hoping to make more progress tomorrow.
>>>>>>
>>>>>> Regards,
>>>>>> Bryn Rhodes
>>>>>> bryn@databaseconsultinggroup.com
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Carl and all
>>>>>>>
>>>>>>> Hope you are enjoying first day. I'd like to make sure you all get
>>>>>>> to meet Ismael from HISP TZ as you move forward with connectathon.
>>>>>>> I don't think Ismael has been that involved with ADX work but he is
>>>>>>> quite familiar with DHIS2 and API and (importantly) he has ssh
>>>>>>> backend access to the sandbox at openhie.dhis2.org.
>>>>>>>
>>>>>>> Ismael, I have explained in separate mail that James has setup
>>>>>>> metadata for an ADX dataset on the linode in order to give early
>>>>>>> exposure to the upcoming new ADX HIV profile from IHE.
>>>>>>>
>>>>>>> Carl and Bryn have been working on a FHIR "rendition" of ADX and I
>>>>>>> think will be interested to see how this ADX HIV dataset might look
>>>>>>> using that form.
>>>>>>>
>>>>>>> Enjoy.
>>>>>>>
>>>>>>> Bob.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Carl_Leitner2]

Hi all,
Here is the edited proposal for your review. I hope that it accurately captures our discussions. I’ll submit it later today so please send me any critical feedback.

https://www.dropbox.com/s/q8h64ozvwx7gekn/ADX_on_FHIR_IHE_Profile_Proposal_Template-Brief.docx?dl=0

In contains a proposal for:

• Replacing the usage of the DSD in ADX with FHIR profile of a Measure resource
• A white paper on usage of CQL and the broader FHIR API for alternate reporting workflows.

Cheers,

-carl

···

On Sep 21, 2018, at 12:38 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

I would retain section 5.3 … (almost). And also retain the nod to 5.4.

That would make the proposal simpler.
On Fri, 21 Sep 2018 at 17:26, Carl Leitner litlfred@ibiblio.org wrote:

Agreed on what you suggest - I think we may just have a different definition of light editing

Cheers,
-carl

On Sep 21, 2018, at 12:16 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Carl I think the current proposal needs more than light editing.

I don’t think it correctly states the problem as it is but jumps
directly to MeasureReport as the “solution” to a json version of ADX
for a bundle of reasons which I don’t think are necessarily valid.
And if it is just to get to a json format we know there is an easier
way.

The problem as I understand it is that we currently only have SDMX to
represent the structural metadata of a data message, and SDMX (unlike
the data message of adx) is complex and does not enjoy much traction
in the world. Consequently, whereas we have seen some uptake of the
ADX data message in the world, there is very little interest in the
exchange of SDMX DSD. And no known instances of it having happened in
the wild.

We would like to explore whether FHIR can provide us with a more
palatable way to achieve the functionality of the DSD. Perhaps this
is using a Measure/MeasureReport or perhaps something more bespoke.
Somewhere between a bundle and a profile. I don’t think we have that
answer at this point.

I am not sure if these motivations are really captured in the existing
proposal. But maybe let us at least try to describe the problem as it
is and leave the way open for the committee to pursue a solution.

Cheers
Bob
On Fri, 21 Sep 2018 at 16:18, Carl Leitner litlfred@ibiblio.org wrote:

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).

If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

On Sep 21, 2018, at 8:45 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)
On Fri, 21 Sep 2018 at 13:24, Carl Leitner litlfred@gmail.com wrote:

Hi all,

I am in meetings for the next few hours so won’t have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
https://www.hl7.org/fhir/profiling.html

This should let us say “use this value set for these disaggreators” etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven’t done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the “ragged right” to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) wmo7@cdc.gov wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com open-hmis@googlegroups.com On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS open-hmis@googlegroups.com
Subject: Re: Introductions

Begging the question …

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:

1. I can’t see the period or orgUnit dimensions on the data sample.
   I think its important to see how this will work.
2. I don’t see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
   (stratification?) is to concatenate individual dimensions with a
   joining ‘:’. This looks ugly (requiring a parser within a parser)
   and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q’s
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes bryn@databaseconsultinggroup.com
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe bobjolliffe@gmail.com
Cc: Carl Leitner litlfred@gmail.com, Kariuki, James M.
(CDC/CGH/DGHA) wmo7@cdc.gov, ismail yusuf
ismailkoleleni@gmail.com, Carl Fourie carl.fourie@jembi.org

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I’ve attached examples, please note these are rough, but this is the
direction we’re heading. We’re hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl and all

Hope you are enjoying first day. I’d like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don’t think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR “rendition” of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bobj]

Hi James

It looks almost fine to me. The only thing I would repeat is that the
"Problem" is not really accurate.

If the problem to be solved was really excessive bandwidth and
management issues of the orgUnit code list, we could address that
easily with a few lines in the existing profile - make that code list
an external reference, or don't use a code list and specify that
orgunit synch should be done between systems through an external
method eg. CSD/mCSD.

The real problem is not that. It is that feedback from implementers
has shown a lack of appetite for SDMX and a preference for a more
modern approach (FHIR) which will likely enjoy greater traction. In
fact currently the exchange of DSD is not Mandatory in the profile for
this reason. So the problem we would like to address is how to
represent the structural metadata for an ADX message in a way which is
more attractive and aligned with other activities and standards in the
domain.

That would be my alternative wording. Mind you the substantive
content will be the same.

Cheers
Bob

···

On Mon, 24 Sep 2018 at 13:34, Carl Leitner <litlfred@ibiblio.org> wrote:

Hi all,
Here is the edited proposal for your review. I hope that it accurately captures our discussions. I’ll submit it later today so please send me any critical feedback.
    Dropbox - ADX_on_FHIR_IHE_Profile_Proposal_Template-Brief.docx - Simplify your life

In contains a proposal for:

Replacing the usage of the DSD in ADX with FHIR profile of a Measure resource
A white paper on usage of CQL and the broader FHIR API for alternate reporting workflows.

Cheers,
-carl

On Sep 21, 2018, at 12:38 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

I would retain section 5.3 ... (almost). And also retain the nod to 5.4.

That would make the proposal simpler.
On Fri, 21 Sep 2018 at 17:26, Carl Leitner <litlfred@ibiblio.org> wrote:

Agreed on what you suggest - I think we may just have a different definition of light editing

Cheers,
-carl

On Sep 21, 2018, at 12:16 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Carl I think the current proposal needs more than light editing.

I don't think it correctly states the problem as it is but jumps
directly to MeasureReport as the "solution" to a json version of ADX
for a bundle of reasons which I don't think are necessarily valid.
And if it is just to get to a json format we know there is an easier
way.

The problem as I understand it is that we currently only have SDMX to
represent the structural metadata of a data message, and SDMX (unlike
the data message of adx) is complex and does not enjoy much traction
in the world. Consequently, whereas we have seen some uptake of the
ADX data message in the world, there is very little interest in the
exchange of SDMX DSD. And no known instances of it having happened in
the wild.

We would like to explore whether FHIR can provide us with a more
palatable way to achieve the functionality of the DSD. Perhaps this
is using a Measure/MeasureReport or perhaps something more bespoke.
Somewhere between a bundle and a profile. I don't think we have that
answer at this point.

I am not sure if these motivations are really captured in the existing
proposal. But maybe let us at least try to describe the problem as it
is and leave the way open for the committee to pursue a solution.

Cheers
Bob
On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).

If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)
On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:

Hi all,

I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
Profiling - FHIR v5.0.0

This should let us say "use this value set for these disaggreators" etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi Carl and all

Hope you are enjoying first day. I'd like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don't think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR "rendition" of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bobj]

Sorry I meant to say "Hi Carl". But Hi James as well

···

On Mon, 24 Sep 2018 at 14:10, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi James

It looks almost fine to me. The only thing I would repeat is that the "Problem" is not really accurate.

If the problem to be solved was really excessive bandwidth and management issues of the orgUnit code list, we could address that easily with a few lines in the existing profile - make that code list an external reference, or don't use a code list and specify that orgunit synch should be done between systems through an external method eg. CSD/mCSD.

The real problem is not that. It is that feedback from implementers has shown a lack of appetite for SDMX and a preference for a more modern approach (FHIR) which will likely enjoy greater traction. In fact currently the exchange of DSD is not Mandatory in the profile for this reason. So the problem we would like to address is how to represent the structural metadata for an ADX message in a way which is more attractive and aligned with other activities and standards in the domain.

That would be my alternative wording. Mind you the substantive content will be the same.

Cheers
Bob
On Mon, 24 Sep 2018 at 13:34, Carl Leitner <litlfred@ibiblio.org> wrote:
>
> Hi all,
> Here is the edited proposal for your review. I hope that it accurately captures our discussions. I’ll submit it later today so please send me any critical feedback.
> Dropbox - ADX_on_FHIR_IHE_Profile_Proposal_Template-Brief.docx - Simplify your life
>
> In contains a proposal for:
>
> Replacing the usage of the DSD in ADX with FHIR profile of a Measure resource
> A white paper on usage of CQL and the broader FHIR API for alternate reporting workflows.
>
>
> Cheers,
> -carl
>
> On Sep 21, 2018, at 12:38 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> I would retain section 5.3 ... (almost). And also retain the nod to 5.4.
>
> That would make the proposal simpler.
> On Fri, 21 Sep 2018 at 17:26, Carl Leitner <litlfred@ibiblio.org> wrote:
>
>
> Agreed on what you suggest - I think we may just have a different definition of light editing
>
> Cheers,
> -carl
>
>
> On Sep 21, 2018, at 12:16 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Carl I think the current proposal needs more than light editing.
>
> I don't think it correctly states the problem as it is but jumps
> directly to MeasureReport as the "solution" to a json version of ADX
> for a bundle of reasons which I don't think are necessarily valid.
> And if it is just to get to a json format we know there is an easier
> way.
>
> The problem as I understand it is that we currently only have SDMX to
> represent the structural metadata of a data message, and SDMX (unlike
> the data message of adx) is complex and does not enjoy much traction
> in the world. Consequently, whereas we have seen some uptake of the
> ADX data message in the world, there is very little interest in the
> exchange of SDMX DSD. And no known instances of it having happened in
> the wild.
>
> We would like to explore whether FHIR can provide us with a more
> palatable way to achieve the functionality of the DSD. Perhaps this
> is using a Measure/MeasureReport or perhaps something more bespoke.
> Somewhere between a bundle and a profile. I don't think we have that
> answer at this point.
>
> I am not sure if these motivations are really captured in the existing
> proposal. But maybe let us at least try to describe the problem as it
> is and leave the way open for the committee to pursue a solution.
>
> Cheers
> Bob
> On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:
>
>
> Hi,
> I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.
>
> I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).
>
> If we go this route, the draft proposal would only need some light edits and I can get this out today.
>
> Doe this sound good to everyone?
>
> Cheers,
> -carl
>
>
> On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
> Thanks Carl. Agree. But do you see these as two proposals or one?
>
> (sorry if I forgot about thread re colons)
> On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:
>
>
> Hi all,
>
> I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
> Profiling - FHIR v5.0.0
>
> This should let us say "use this value set for these disaggreators" etc.
>
> My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.
>
> If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)
>
> Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).
>
>
>
>
> Cheers,
> -carl
>
> On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:
>
>
> Hi Bob and all,
>
> We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
> I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.
>
> Thanks,
> James
>
> -----Original Message-----
> From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
> Sent: Friday, September 21, 2018 7:13 AM
> To: Open HMIS <open-hmis@googlegroups.com>
> Subject: Re: Introductions
>
> Begging the question ....
>
> Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?
>
> The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
> On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
>
> Hi all
>
> I am just forwarding these snippets which were shared after the openHIE meetup.
>
> I have a couple of questions/observations:
> 1. I can't see the period or orgUnit dimensions on the data sample.
> I think its important to see how this will work.
> 2. I don't see where the dimensions get bound to codelists/valuesets
> 3. It seems like the way of handling multi-dimensionality
> (stratification?) is to concatenate individual dimensions with a
> joining ':'. This looks ugly (requiring a parser within a parser)
> and a step backwards towards categorycombooptions.
>
> Maybe some of those who were involved creating these examples can
> comment on above.
>
> In a general sense I am a little uneasy. As I said yesterday I am
> personally not fond of, or wedded to, sdmx. It was a means to an
> end. I would willingly jump to something simpler. James or Derek
> might have their own affections. The concern I have, looking back
> over these examples, is that I am not really convinced that this is
> any less obtuse than sdmx. For the moment, as per my 3 quick q's
> above, the examples are incomplete so hard to say. Besides the fact
> that it is FHIR (which I understand brings with it an inherent warm
> glow and probably will attract funding) I still fail to see much
> attraction.
>
> The measure report data sample is certainly far uglier than adx data
> message. So there is no way that I would support replacing the
> existing adx data message, though I am not wedded to the sdmx dsd.
>
> It remains to be seen whether an xsd schema and schematron for an adx
> data message could be derived from a FHIR Measure resource. I suspect
> these examples were taken by running xslt against existing sdmx dsd
> which is grand, but it looks like the underlying codelists/valuesets
> were simply picked from the dsd but otherwise clobbered.
>
> It looks like you would still need a FHIR bundle of some sort which
> brought together the valuesets required for a particular dataset
> (orgunits, dataelements, sex, age_group etc). I had mistakenly
> thought these was somehow defined in the Measure but it looks like
> they are not. (I had raised the possibility of defining such a bundle
> last year in Naples)
>
> So lots of questions. I was kind of hoping yesterday that the FHIR
> stuff could provide a kind of drop-in replacement for the SDMX dsd, in
> which case I was happily prepared to embrace it. But I am not seeing
> that at all. I think quite a few things to resolve. Maybe Derek can
> grant us more time.
>
> Cheers
> Bob
>
> ---------- Forwarded message ---------
> From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
> Date: Fri, 3 Aug 2018 at 19:11
> Subject: Re: Introductions
> To: Bob Jolliffe <bobjolliffe@gmail.com>
> Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
> (CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
> <ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>
>
>
> Hi Bob,
>
> We made some good progress today, I met Ismail and James, Pierre, and
> I worked on a mapping that we think will work quite well. The Jembe
> team worked on an ADX->MeasureReport mediator and we made a lot of
> progress on representing the indicator definitions in FHIR and CQL.
>
> I've attached examples, please note these are _rough_, but this is the
> direction we're heading. We're hoping to make more progress tomorrow.
>
> Regards,
> Bryn Rhodes
> bryn@databaseconsultinggroup.com
>
>
> On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>
>
> Hi Carl and all
>
> Hope you are enjoying first day. I'd like to make sure you all get
> to meet Ismael from HISP TZ as you move forward with connectathon.
> I don't think Ismael has been that involved with ADX work but he is
> quite familiar with DHIS2 and API and (importantly) he has ssh
> backend access to the sandbox at openhie.dhis2.org.
>
> Ismael, I have explained in separate mail that James has setup
> metadata for an ADX dataset on the linode in order to give early
> exposure to the upcoming new ADX HIV profile from IHE.
>
> Carl and Bryn have been working on a FHIR "rendition" of ADX and I
> think will be interested to see how this ADX HIV dataset might look
> using that form.
>
> Enjoy.
>
> Bob.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Open HMIS" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

[derek.ritz]

Hi all – Carl, I’ve added only a few comments to the doc. We will, in committee, separately split out the proposal into its two constituent pieces so they can be separately discussed and balloted/accepted – but I like that they’re both in one proposal because it clearly shows how they are related to each other.
Thanks for pulling this together.

Warmest regards,

Derek

···

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[bobj]

I wonder if it makes sense to take advantage of the substantial
maintenance cycle to slip in the description of a simple, literal json
adx rendition, as per my example the other day (repeated below):

{
  "dataSet": "MALARIA",
  "period": "2017-10-01/P1M",
  "orgUnit": "TheClinic",
  "dataValues": [
    {
      "dataElement": "MALARIA_CASES",
      "SEX": "Male",
      "AGE_GROUP": "P5Y--P10Y",
      "value": "8"
    },
    {
      "dataElement": "MALARIA_CASES",
      "SEX": "Female",
      "AGE_GROUP": "P5Y--P10Y",
      "value": "12"
    }
  ]
}

···

On Mon, 24 Sep 2018 at 14:18, Derek Ritz <derek.ritz@gmail.com> wrote:

Hi all -- Carl, I've added only a few comments to the doc. We will, in committee, separately split out the proposal into its two constituent pieces so they can be separately discussed and balloted/accepted -- but I like that they're both in one proposal because it clearly shows how they are related to each other.
Thanks for pulling this together.
Warmest regards,
Derek

On Mon, Sep 24, 2018 at 8:34 AM Carl Leitner <litlfred@ibiblio.org> wrote:

Hi all,
Here is the edited proposal for your review. I hope that it accurately captures our discussions. I’ll submit it later today so please send me any critical feedback.
    Dropbox - ADX_on_FHIR_IHE_Profile_Proposal_Template-Brief.docx - Simplify your life

In contains a proposal for:

Replacing the usage of the DSD in ADX with FHIR profile of a Measure resource
A white paper on usage of CQL and the broader FHIR API for alternate reporting workflows.

Cheers,
-carl

On Sep 21, 2018, at 12:38 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

I would retain section 5.3 ... (almost). And also retain the nod to 5.4.

That would make the proposal simpler.
On Fri, 21 Sep 2018 at 17:26, Carl Leitner <litlfred@ibiblio.org> wrote:

Agreed on what you suggest - I think we may just have a different definition of light editing

Cheers,
-carl

On Sep 21, 2018, at 12:16 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Carl I think the current proposal needs more than light editing.

I don't think it correctly states the problem as it is but jumps
directly to MeasureReport as the "solution" to a json version of ADX
for a bundle of reasons which I don't think are necessarily valid.
And if it is just to get to a json format we know there is an easier
way.

The problem as I understand it is that we currently only have SDMX to
represent the structural metadata of a data message, and SDMX (unlike
the data message of adx) is complex and does not enjoy much traction
in the world. Consequently, whereas we have seen some uptake of the
ADX data message in the world, there is very little interest in the
exchange of SDMX DSD. And no known instances of it having happened in
the wild.

We would like to explore whether FHIR can provide us with a more
palatable way to achieve the functionality of the DSD. Perhaps this
is using a Measure/MeasureReport or perhaps something more bespoke.
Somewhere between a bundle and a profile. I don't think we have that
answer at this point.

I am not sure if these motivations are really captured in the existing
proposal. But maybe let us at least try to describe the problem as it
is and leave the way open for the committee to pursue a solution.

Cheers
Bob
On Fri, 21 Sep 2018 at 16:18, Carl Leitner <litlfred@ibiblio.org> wrote:

Hi,
I am not sure. I could see, for example, that the DSD stuff is for example a IHE profile while, at this stage, the ADX to MeasureReport mapping is only a white paper.

I would suggest for coherency that we submit one proposal to QRPH and list this out as an option on how to proceed and leave the ultimate determination up to QRPH (and this also allows us to have more internal discussions).

If we go this route, the draft proposal would only need some light edits and I can get this out today.

Doe this sound good to everyone?

Cheers,
-carl

On Sep 21, 2018, at 8:45 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Thanks Carl. Agree. But do you see these as two proposals or one?

(sorry if I forgot about thread re colons)
On Fri, 21 Sep 2018 at 13:24, Carl Leitner <litlfred@gmail.com> wrote:

Hi all,

I am in meetings for the next few hours so won't have time to dig in until later today, but I believe what we want is to setup the parameters for a FHIR profile to replace the DSD:
Profiling - FHIR v5.0.0

This should let us say "use this value set for these disaggreators" etc.

My understanding from talking with others is that this is very straightforward (and there are even open-source GUIs to do so) but I haven't done one myself.

If these assumptions are correct, I would suggest we sumbit to QRPH a proposal that says we focus on 1) the FHIR replacement for the DSD and 2) a mapping table from a MeasureReport xml representatiin into an ADX message (with example xsl)

Note, to Bob regarding the colons. Agreed. There is already a FHIR issue created to get us away from this. There is an email thread with you and Bryn around the "ragged right" to see if the proposed change would accommodate what we need. (I think so but we need a 30 minute call).

Cheers,
-carl

On Fri, Sep 21, 2018, 07:42 Kariuki, James M. (CDC/CGH/DGHT) <wmo7@cdc.gov> wrote:

Hi Bob and all,

We can submit a white paper that will help us test if FHIR bundle of linked valuesets can effectively replace the DSD.
I support maintaining the message format as it is currently because of the ease of readability and several systems are able to produce and consume it.

Thanks,
James

-----Original Message-----
From: open-hmis@googlegroups.com <open-hmis@googlegroups.com> On Behalf Of Bob Jolliffe
Sent: Friday, September 21, 2018 7:13 AM
To: Open HMIS <open-hmis@googlegroups.com>
Subject: Re: Introductions

Begging the question ....

Can we propose a FHIR bundle of linked valuesets to effectively replace the DSD?

The Measure/MeasureReport is not it (in fact its successful implementation also seems to pre-suppose such a bundle).
On Thu, 20 Sep 2018 at 11:36, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi all

I am just forwarding these snippets which were shared after the openHIE meetup.

I have a couple of questions/observations:
1. I can't see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.
2. I don't see where the dimensions get bound to codelists/valuesets
3. It seems like the way of handling multi-dimensionality
(stratification?) is to concatenate individual dimensions with a
joining ':'. This looks ugly (requiring a parser within a parser)
and a step backwards towards categorycombooptions.

Maybe some of those who were involved creating these examples can
comment on above.

In a general sense I am a little uneasy. As I said yesterday I am
personally not fond of, or wedded to, sdmx. It was a means to an
end. I would willingly jump to something simpler. James or Derek
might have their own affections. The concern I have, looking back
over these examples, is that I am not really convinced that this is
any less obtuse than sdmx. For the moment, as per my 3 quick q's
above, the examples are incomplete so hard to say. Besides the fact
that it is FHIR (which I understand brings with it an inherent warm
glow and probably will attract funding) I still fail to see much
attraction.

The measure report data sample is certainly far uglier than adx data
message. So there is no way that I would support replacing the
existing adx data message, though I am not wedded to the sdmx dsd.

It remains to be seen whether an xsd schema and schematron for an adx
data message could be derived from a FHIR Measure resource. I suspect
these examples were taken by running xslt against existing sdmx dsd
which is grand, but it looks like the underlying codelists/valuesets
were simply picked from the dsd but otherwise clobbered.

It looks like you would still need a FHIR bundle of some sort which
brought together the valuesets required for a particular dataset
(orgunits, dataelements, sex, age_group etc). I had mistakenly
thought these was somehow defined in the Measure but it looks like
they are not. (I had raised the possibility of defining such a bundle
last year in Naples)

So lots of questions. I was kind of hoping yesterday that the FHIR
stuff could provide a kind of drop-in replacement for the SDMX dsd, in
which case I was happily prepared to embrace it. But I am not seeing
that at all. I think quite a few things to resolve. Maybe Derek can
grant us more time.

Cheers
Bob

---------- Forwarded message ---------
From: Bryn Rhodes <bryn@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjolliffe@gmail.com>
Cc: Carl Leitner <litlfred@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wmo7@cdc.gov>, ismail yusuf
<ismailkoleleni@gmail.com>, Carl Fourie <carl.fourie@jembi.org>

Hi Bob,

We made some good progress today, I met Ismail and James, Pierre, and
I worked on a mapping that we think will work quite well. The Jembe
team worked on an ADX->MeasureReport mediator and we made a lot of
progress on representing the indicator definitions in FHIR and CQL.

I've attached examples, please note these are _rough_, but this is the
direction we're heading. We're hoping to make more progress tomorrow.

Regards,
Bryn Rhodes
bryn@databaseconsultinggroup.com

On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi Carl and all

Hope you are enjoying first day. I'd like to make sure you all get
to meet Ismael from HISP TZ as you move forward with connectathon.
I don't think Ismael has been that involved with ADX work but he is
quite familiar with DHIS2 and API and (importantly) he has ssh
backend access to the sandbox at openhie.dhis2.org.

Ismael, I have explained in separate mail that James has setup
metadata for an ADX dataset on the linode in order to give early
exposure to the upcoming new ADX HIV profile from IHE.

Carl and Bryn have been working on a FHIR "rendition" of ADX and I
think will be interested to see how this ADX HIV dataset might look
using that form.

Enjoy.

Bob.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Open HMIS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Derek Ritz
----------------
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[derek.ritz]

Bob – we always contemplated that ADX could/should support multiple message formats. I think we can – and should – define the mapping of normative XML to json as a CP on ADX. What do you think about that idea? It doesn’t require as to make a separate submission.
Sound like a plan?

Derek

···

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.