Fwd: Introductions

[Bob Jolliffe]

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 <br...@databaseconsultinggroup.com>
Date: Fri, 3 Aug 2018 at 19:11
Subject: Re: Introductions
To: Bob Jolliffe <bobjo...@gmail.com>
Cc: Carl Leitner <litl...@gmail.com>, Kariuki, James M.
(CDC/CGH/DGHA) <wm...@cdc.gov>, ismail yusuf
<ismailk...@gmail.com>, Carl Fourie <carl....@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
br...@databaseconsultinggroup.com


On Tue, Jul 31, 2018 at 10:06 AM, Bob Jolliffe <bobjo...@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.

[Bob Jolliffe]

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).

[Kariuki, James M. (CDC/CGH/DGHT)]

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

--
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+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl Leitner]

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

[Bob Jolliffe]

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

(sorry if I forgot about thread re colons)

[Bob Jolliffe]

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

[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/CGH/DGHT)]

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

 

From: open...@googlegroups.com <open...@googlegroups.com> On Behalf Of Derek Ritz
Sent: Friday, September 21, 2018 9:24 AM
To: Frederick Leitner <litl...@ibiblio.org>
Cc: Kariuki, James M. (CDC/CGH/DGHT) <wm...@cdc.gov>; Bob Jolliffe <bobjo...@gmail.com>; Open HMIS <open...@googlegroups.com>
Subject: Re: Introductions

 

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.

 

[Carl Leitner]

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

[Carl Leitner]

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]

james -- i'm sure we could convert from white paper to profile... it'd be at the pleasure of the committee to do so. :-)

[Bob Jolliffe]

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

[Carl Leitner]

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

Cheers,
-carl

[Bob Jolliffe]

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

That would make the proposal simpler.

[Carl Leitner]

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 

[Bob Jolliffe]

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

[Bob Jolliffe]

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

[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

[Bob Jolliffe]

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"
}
]

[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

[Kariuki, James M. (CDC/CGH/DGHT)]

Bob and Derek,

 

Including JSON format will be a great addition to ADX. We can propose a CP in the next meeting.

 

Thanks

James

[Carl Leitner]

Hi, 

I have made edits per Bob’s ad Derek’s comments.  I’ll go ahead and submit around noon my time (giving a bit more time for James, Pierre and others to weigh in).

Cheers,

-carl