Bob and Derek,
Including JSON format will be a great addition to ADX. We can propose a CP in the next meeting.
Thanks
James
···
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
On Mon, Sep 24, 2018 at 9:22 AM Bob Jolliffe bobjolliffe@gmail.com wrote:
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,
DerekOn 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.
https://www.dropbox.com/s/q8h64ozvwx7gekn/ADX_on_FHIR_IHE_Profile_Proposal_Template-Brief.docx?dl=0In 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,
-carlOn 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,
-carlOn 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,
-carlOn 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.htmlThis 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,
-carlOn 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: IntroductionsBegging 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:
- I can’t see the period or orgUnit dimensions on the data sample.
I think its important to see how this will work.- I don’t see where the dimensions get bound to codelists/valuesets
- 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.orgHi 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.comOn 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 RitzThis email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.