Web Services API

[litlfred]

Hi All,
I am brining in here a conversation that some of us have been having
concerning a standardized web services API for retrieving SDMX-HD
data. In particular so that accessing the data from openMRS, DHIS,
iHRIS, etc should all nbe t I've included below the thread and put a
possible draft as a publicly editable google doc:
https://docs.google.com/document/d/1qdeQcUWNgGIt_ncU0Gw1F91b63vDMld9VnCIIYSz1Os/edit?hl=en&authkey=CIPo1LwM

The one complaint we had about SDMX-HD at the Ghana unconference last
year was that things should happen automatically without having to
save files to the desktop and upload them some place else. I think
this is the first step to achieve this.

There are enough folks doing java programming that it may make sense
to have a separate java library that would provide the sdmx-hd web
services client functionality. We (the iHRIS folks) are programming in
PHP, anyone else?


Bob,
We should expect, even for the HR data, that the DSD should change
over time -- a new facility is opened, a new cadre of health workers
is developed. I think it is a reasonable expectation to be able to go
through and get all the historical variants of the DSD.

Cheers.
-carl




==========================Thread ==========================
On 04/04/2011 05:12 PM, Bob Jolliffe wrote:
> On 4 April 2011 17:23, Carl Leitner <clei...@capacityplus.org> wrote:
>> > What you want should be covered more or less by what I suggest below. Are
>> > we ever going to have more than one DSD floating around? By this I don't
>> > mean separate versions of more less the same file, but a system that needs
>> > to be aware of more than one DSD?
> Carl, I think this will be a matter of stability which will emerge
> over time. But having said that I do believe that in the particular
> case of HR dataelements and indicators we could stabilize that quite
> quickly. We have the basic cadre list as dataelement and the facility
> list which will of course vary from country to country. (Whereas
> doctors, nurses dentists etc are fairly universal, there seems to be
> large variation in the types and cadre names of different types of
> community health workers in different countries.)
>
> But beyond those two variables I suspect one could reach consensus on
> an HR oriented DSD pretty quickly.
>
>> >
>> > As later on we may want to get fancier/make changes one the systems are in
>> > place, the other suggestion that I would add would be to know what "version"
>> > of the web service is running. Something that could be gotten from
>> > <<BASE_URL>>/sdmx/version which would return 1.0 at this point.
>> >
>> > Does anyone object to moving this to the google group?
> No google group is good for me.
>
> BTW I do agree on the need for a DHIS "web service" to access the DSD
> and codelists. Bad time for me this week as I am still on intensive
> course till Friday :-(
>
> Regards
> Bob
>
>> >
>> > Cheers.
>> > -carl
>> >
>> >
>> >
>> > On 04/04/2011 04:36 AM, Ryan wrote:
>> >
>> > Hi all,
>> >
>> > I think it would be great to add some web services functionality between the
>> > systems. I've just got back from Rwanda and have a lot on my plate at the
>> > moment but if the functionality is kept simple I could maybe implements some
>> > WS calls from OpenMRS. I'l find out if I can spare some cycles.
>> >
>> > The most important call from OpenMRS would be to submit data to DHIS.
>> > Perhaps one to pull down the latest DSD would be a good one to have as well.
>> >
>> > Ryan
>> >
>> > On Fri, Apr 1, 2011 at 4:05 PM, Carl Leitner <clei...@capacityplus.org>
>> > wrote:
>>> >>
>>> >> So what have we decided to do to have this discussion in a public place.
>>> >> Should we just use the google group for the time being until the host issues
>>> >> get sorted out. It would be nice to get this conversation really going and
>>> >> include the openMRS [looping in Ryan], etc folks.
>>> >>
>>> >> What I would love to see is a very minimal sdmx-hd web services API that
>>> >> everyone agrees to implement. In particular, DHIS2 should not have to care
>>> >> if it is pulling data from iHRIS or openMRS. The only possible exception
>>> >> may be how the login / user authentication is handled and the base URL
>>> >> used.
>>> >>
>>> >> I really want to avoid feature creep. The simpler we can keep the
>>> >> requirements, the more likely everyone will agree to implement it. If do
>>> >> things in this manner, we also have the possiblity of someone writing a java
>>> >> based sdmx-hd web services client that the DHIS2, openMRS folks etc can
>>> >> simply plug in.
>>> >>
>>> >> Here are some more expanded suggestions for requirements. I am looking
>>> >> for the DHIS2 folks, with their experience in consuming SDMX-HD data, to
>>> >> really inform on the requirements. I also don't like the language...
>>> >>
>>> >> provides only GET operations (or POST that don't change the state of the
>>> >> database)
>>> >> Ouput can be requested in one of a few formats using the request variable:
>>> >> format
>>> >>
>>> >> Required formats are json or xml.
>>> >>
>>> >> query for a list of the types of reports/export are available for export
>>> >> via SDMX-HD
>>> >>
>>> >> URL: <<BASE URL>>/sdmx/export_types
>>> >> Query Variables:
>>> >>
>>> >> start. Defaults to 0. Where we should start listing the reports. The
>>> >> order is not normed.
>>> >>
>>> >> Returns: a nest array / list of at most 50 reports. Each report/export
>>> >> type should have the following data:
>>> >>
>>> >> start: where we started listing
>>> >> end: where we ended listing
>>> >> export_types: an associative array whose values are the following
>>> >>
>>> >> key: the key (or name) used to reference this type of report (eg.
>>> >> something like phuf6 in the iHRIS Sierra Leone example)
>>> >> location: the location (including the base url) of where more information
>>> >> about that particular export/report type can be accessed
>>> >> (this would be something like <<BASE URL>>/sdmx/export/<<TYPE>>)
>>> >>
>>> >> for a given type of report (e.g. # health workers by cadre/district) a
>>> >> list of different variants of that report type. for example in our case it
>>> >> would be when the report was generated.
>>> >>
>>> >> URL: <<BASE URL>>/sdmx/export/<<TYPE>>/documents
>>> >> Query Variables:
>>> >>
>>> >> start. Defaults to 0. Where we should start listing the
>>> >> exports/documents. The order is not normed.
>>> >>
>>> >> Returns: a nest array / list of at most 50 documents. Each document
>>> >> should have the following data:
>>> >>
>>> >> start: where we started listing
>>> >> end: where we ended listing
>>> >> exports: an associative array whose values are the following
>>> >>
>>> >> key: some key used to reference this specific version of the
>>> >> document/export
>>> >> time: the time this report/document was last modified/generated
>>> >> location: the location (including the base url) of where that particular
>>> >> report/export can be accessed
>>> >> (this would be something like <<BASE
>>> >> URL>>/sdmx/export/<<TYPE>>/document/<<KEY>> )
>>> >>
>>> >> for a given report/export ability to query some meta data about the
>>> >> report. this should have the basic info need to know what is is you are
>>> >> going to import without
>>> >> actually getting the full
>>> >>
>>> >> URL: <<BASE URL>>/sdmx/export/<<TYPE>>/document/<<KEY>>/meta
>>> >>
>>> >> Query Variables:
>>> >>
>>> >> Returns:
>>> >>
>>> >> format: CrossSectionDataSet, CompactDataSet. Perhaps this should be tag
>>> >> name of the root node which in the case of DSD is Structure?
>>> >> time: the last modification time
>>> >> attributes: an associative array containing all the attributes of the root
>>> >> node
>>> >> header: the location (including base url) to access the header info for
>>> >> this document
>>> >> (this would be something like <<BASE URL>>/sdmx/export/<<NAME>>/document
>>> >>
>>> >> you should be able to query anything from the header of a document so you
>>> >> can check out whatever you need before you download
>>> >>
>>> >> the easiest way to handle this is probably to allow a client to send a
>>> >> xpath query that will be applied to the header node.
>>> >> to make sure no one "cheats" and tries to get things out of the header,
>>> >> implementor of the web service may want to
>>> >> URL: <<BASE URL>>/sdmx/export/<<TYPE>>/document/<<KEY>>/header
>>> >> Query Variables:
>>> >>
>>> >> query: the xpath query to run on the header node.
>>> >>
>>> >> Returns:
>>> >>
>>> >> an array (corresponding to the dom node list return by the query) which
>>> >> contains the text content of each node returned by the query
>>> >>
>>> >> finally you should be able to actually just get the document
>>> >>
>>> >> URL: <<BASE URL>>/sdmx/export/<<TYPE>>/document/<<KEY>>/retrieve
>>> >> returns: the xml document.
>>> >> note, this is the only exception to requiring also a JSON format for the
>>> >> document
>>> >>
>>> >> Thoughts?
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >> On 03/29/2011 04:50 PM, Bob Jolliffe wrote:
>>> >>
>>> >> Hi Patrick
>>> >>
>>> >> Dreamhost looks fine to me. It seems to offer more than what we need.
>>> >> If you know who has the admin details to the dreamhost site and don't
>>> >> mind sharing with me I can take a quick look to see what the email
>>> >> problem might be.
>>> >>
>>> >> Regards
>>> >> Bob
>>> >>
>>> >> 2011/3/29 Carl Leitner <clei...@capacityplus.org>:
>>> >>
>>> >> If you want to put it on a wiki, we could use ours:
>>> >> http://open.intrahealth.org
>>> >> and add a forum extension such as:
>>> >> http://www.mediawiki.org/wiki/Extension:MediaWiki_Bulletin_Board
>>> >>
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >> On 03/29/2011 03:39 AM, Whitaker, John Patrick wrote:
>>> >>
>>> >> Hi Bob,
>>> >>
>>> >> Anyone that expresses interest in the SDMX-HD group is added as a member.
>>> >> The site is hosted externally at Dreamhost. I would like to move it
>>> >> somewhere else with more support. b-i has provided limited support for the
>>> >> site in the past.
>>> >>
>>> >> The WHO Collaborating Center at the University of Sherbrooke has offered
>>> >> to support it along with our ISO TC 215 work it but has no connection to
>>> >> SDMX-HD. Would any of your organizations be willing to host it and provide
>>> >> support for email among the other duties?
>>> >>
>>> >> Patrick
>>> >>
>>> >> Patrick Whitaker
>>> >> eHealth and Informatics Unit
>>> >> Health Statistics and Informatics Department World Health Organization
>>> >> Geneva, Switzerland
>>> >>
>>> >> Tel. direct: +41 22 791 1372
>>> >> Mobile: +41 79 633 7763
>>> >> E-mail: whit...@who.int
>>> >>
>>> >> Health Informatics Wiki
>>> >> http://www.hiwiki.org
>>> >> SDMX-HD Standard
>>> >> http://www.sdmx-hd.org
>>> >> WHO Indicator and Measurement Registry
>>> >> http://apps.who.int/gho/indicatorregistry
>>> >>
>>> >> -----Original Message-----
>>> >> From: Bob Jolliffe [mailto:bobjo...@gmail.com]
>>> >> Sent: 28 March 2011 20:53
>>> >> To: Carl Leitner
>>> >> Cc: Knut Staring; alvin....@gmail.com; Éric Pareja; Whitaker, John
>>> >> Patrick; Wayne Manuel; Randy Fernandez; Dykki Settle; Carol Bales; Xavier
>>> >> Bocken; Luke Duncan; Lars Helge Øverland; Ola Hodne Titlestad
>>> >> Subject: Re: DHIS2 in Philippine Connectathon April 12
>>> >>
>>> >> On 28 March 2011 18:09, Carl Leitner<clei...@capacityplus.org> wrote:
>>> >>
>>> >> Is there a forum that we can move this discussion to?
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >> I would suggest that we should be having these discussions on the
>>> >> sdmx-hd mailing list which hasn't seen much traffic for a while. I
>>> >> know the intent was to set up mail on the redmine server running
>>> >> http://sdmx-hd.org but I don't think this was ever done. Xavier would
>>> >> have a better idea of what it might take to get that going. Meanwhile
>>> >> I am happy enough to use the google group but in the interest of
>>> >> transparency it would be good to know how and by who new members are
>>> >> approved. Is there anybody here who wants to be and is not already on
>>> >> that mailing list?
>>> >>
>>> >> Xavier who is managing the sdmx-hd site? If somebody registers on
>>> >> that site what is the workflow from there regarding joining? What
>>> >> would it take to get mail working there? Sorry if you don't know the
>>> >> answer to any of these :-)
>>> >>
>>> >> Bob
>>> >>
>>> >>
>>> >> On 03/28/2011 11:24 AM, Knut Staring wrote:
>>> >>
>>> >> Copying to Lars and Ola (and perhaps some of the people copied would
>>> >> like not to be as the discussion moves to technicalities).
>>> >>
>>> >> Knut
>>> >>
>>> >> 2011/3/28 Carl Leitner<clei...@capacityplus.org>:
>>> >>
>>> >> Hi All,
>>> >> The overhead of managing interoperability between iHRIS and DHIS2 (and
>>> >> others) could get pretty cumbersome pretty gast.
>>> >>
>>> >> It seems like we are getting to the point where we really need to
>>> >> expose
>>> >> the
>>> >> available data we have for export from iHRIS as a web-service. I
>>> >> personally
>>> >> would prefer something RESTful so that the available exports are
>>> >> "discoverable". Here are some vague ideas of what the functionality
>>> >> should
>>> >> contain:
>>> >>
>>> >> query for a list of the types of reports/export are available for
>>> >> export
>>> >> via
>>> >> SDMX-HD
>>> >> for a given type of report (e.g. # health workers by cadre/district) a
>>> >> list
>>> >> of reports available by TIME_PERIOD
>>> >> for a given report/export ability to query some meta data about the
>>> >> report.
>>> >> this is basically whatever you need to import it into DHIS2 without
>>> >> actually
>>> >> getting the full export. I am thinking stuff like:
>>> >>
>>> >> "reporting format" (e.g. CrossSectionalData)
>>> >> for each of the reporting formats, what is needed to know what the
>>> >> report
>>> >> contains. for example if it is CDS:
>>> >>
>>> >> anything from the<header>
>>> >> the key family,
>>> >> the reporting frequency,
>>> >> the time period
>>> >>
>>> >> query to get the actual export data
>>> >>
>>> >> If something along these lines seems reasonable, we can perhaps set up
>>> >> a
>>> >> wiki page/discussion forum to sketch out what is needed from a "SDMX-HD
>>> >> web
>>> >> service" that would meet the various interoperability requirements.
>>> >>
>>> >> Preferably this could be done without too much overhead in
>>> >> defining/documenting the webservice capabilities. We could go the WADL
>>> >> route, but this makes some interesting reading:
>>> >> http://bitworking.org/news/193/Do-we-need-WADL
>>> >>
>>> >> Thoughts?
>>> >>
>>> >>
>>> >>
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 03/27/2011 05:56 PM, Bob Jolliffe wrote:
>>> >>
>>> >> Ok. solved that. Seems I had the apc problem described here:
>>> >>
>>> >>
>>> >>
>>> >> http://open.intrahealth.org/mediawiki/Installing_iHRIS_on_Ubuntu_10.4_%28Lucid%29
>>> >>
>>> >> Regrds
>>> >> Bob
>>> >>
>>> >> 2011/3/27 Bob Jolliffe<bobjo...@gmail.com>:
>>> >>
>>> >> Hi Carl
>>> >>
>>> >> I have the SL Demo data running on a virtual box but there is
>>> >> something I have wrong with my iHRIS setup I don't understand. When I
>>> >> click on the SDMX-HD staff reports I am getting the untransformed
>>> >> XML.. ie that which starts with:
>>> >>
>>> >> <ihrisReport id="phu6">
>>> >> <reportDetails>
>>> >> <name>PHU6 Report</name>
>>> >> <description>PHU6 Report</description>
>>> >>
>>> >> Any idea why the xslt is not kicking in? I have an exact replica of
>>> >> the mysql database and I copied the /var/lib/iHRIS stuff from the
>>> >> livecd. Everything seems to work except for this. I know I probably
>>> >> should have done a proper install but it seemed safer to do it like
>>> >> this from an existing known good deployment.
>>> >>
>>> >> Regards
>>> >> Bob
>>> >>
>>> >> 2011/3/23 Bob Jolliffe<bobjo...@gmail.com>:
>>> >>
>>> >> carl I think i am going to try and install the live cd onto a virtual
>>> >> box hard drive and do further customization on the vm. or maybe just
>>> >> make a simple ubuntu server image and forklift the apps over on to it.
>>> >>
>>> >> If i can reverse engineer that back to a livecd then all is good. If
>>> >> I can't its still ok. Though i do like the livecd.
>>> >>
>>> >> Cheers
>>> >> Bob
>>> >>
>>> >> On 23 March 2011 15:10, Carl Leitner<clei...@capacityplus.org>
>>> >> wrote:
>>> >>
>>> >> playground has been reinstalled as it was compromised.
>>> >>
>>> >> I do want to get the sierra leone ihris sample built as .debs (for
>>> >> which
>>> >> I
>>> >> have to fix a bug) and install it in a more standard way.
>>> >>
>>> >> If you want to do things quickly, I _think_ you can just download the
>>> >> .iso,
>>> >> mount it as a virtual machine (or install on a USB and reboot), make
>>> >> whatever changes you want and then try to rebuild the iso from that
>>> >> with
>>> >> a
>>> >> bit of magic. I can send you some pointers.
>>> >>
>>> >>
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >> On 03/23/2011 06:39 AM, Bob Jolliffe wrote:
>>> >>
>>> >> Hi Carl
>>> >>
>>> >> Is the playground still alive and well? I am thinking of trying to
>>> >> update some things and also to work with Knut on making some more
>>> >> extensive sample data.
>>> >>
>>> >> Regards
>>> >> Bob
>>> >>
>>> >> On 22 March 2011 00:03, Carl Leitner<clei...@capacityplus.org>
>>> >> wrote:
>>> >>
>>> >> Please try this link if you did not get it from the earlier one as it
>>> >> now
>>> >> seems to be closed....
>>> >> http://playground.intrahealth.org/uploads/sdmxhd_live.iso
>>> >>
>>> >> Here is the md5sum:
>>> >>
>>> >> litlfred@cumin:~/Desktop/iso/SDMX-HD SierraLeone Live Image$ md5sum
>>> >> sdmxhd.iso
>>> >> c0d3bffc8e66b7eabda07627bc7203a6
>>> >>
>>> >> Would be happy to try to answer any questions on the install. FYI...
>>> >> It
>>> >> is
>>> >> simply an Ubuntu ?Lucid? Live CD with openMRS, DHIS and iHRIS
>>> >> pre-installed.
>>> >>
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >>
>>> >> On 03/21/2011 12:18 PM, alvin....@gmail.com wrote:
>>> >>
>>> >> Carl,
>>> >>
>>> >> We're on standby..
>>> >>
>>> >> If I open up an amazon image for this, could you help us with the
>>> >> install?
>>> >>
>>> >> Pls advise..
>>> >>
>>> >>
>>> >> Sent from my BlackBerryŽ wireless handheld
>>> >>
>>> >> -----Original Message-----
>>> >> From: Carl Leitner<clei...@capacityplus.org>
>>> >> Date: Mon, 21 Mar 2011 11:52:58
>>> >> To: Bob Jolliffe<bobjo...@gmail.com>
>>> >> Cc: Knut Staring<knu...@gmail.com>;<alvin....@gmail.com>; Whitaker,
>>> >> John Patrick<whit...@who.int>;<bocken...@b-i.com>; Wayne
>>> >> Manuel<wdma...@gmail.com>; Randy Fernandez<rgfer...@gmail.com>;
>>> >> Dykki
>>> >> Settle<dse...@capacityplus.org>; Carol Bales<cba...@capacityplus.org>
>>> >> Subject: Re: DHIS2 in Philippine Connectathon April 12
>>> >>
>>> >> Dear Alvin,
>>> >> I am trying to upload the .iso image (1.5G) now and when it succeeds
>>> >> I'll
>>> >> pass on the link.
>>> >>
>>> >> In the meantime, you can read just a bit more about the
>>> >> interoperability
>>> >> here:
>>> >> http://www.capacityplus.org/open-source-unconference
>>> >> which was the focus on the SDMX-HD connectathon. There aren't many
>>> >> technical details here, so let me know if you need more.
>>> >>
>>> >> Cheers.
>>> >> -carl
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 03/21/2011 07:53 AM, Bob Jolliffe wrote:
>>> >>
>>> >> Hi Alvin
>>> >>
>>> >> Will there be any possibility to participate remotely, perhaps using
>>> >> skype, at least for part of the sessions?
>>> >>
>>> >> Carl of capacityplus went to some effort a few months back to put
>>> >> together a live cd which can run in a virtual machine on which
>>> >> openmrs, dhis2 and ihris are pre-configured to exchange data with a
>>> >> minimum amount of extra hassle. I'll dig that up.
>>> >>
>>> >> Regards
>>> >> Bob
>>> >>
>>> >> On 21 March 2011 11:37, Knut Staring<knu...@gmail.com> wrote:
>>> >>
>>> >> Dear Alvin,
>>> >>
>>> >> Thank you for keeping me updated - it looks to be an interesting and
>>> >> important event. Yes, quite a bit of work has taken place on the
>>> >> OpenMRS - DHIS2 integration using SDMX-HD. Allow me to copy Bob
>>> >> Jolliffe who has been working with Jembi on this.
>>> >>
>>> >> Unfortunately, I have been travelling a lot lately, and also have some
>>> >> commitments in Oslo in April, so I will probably not be able to
>>> >> attend, and I don't think Bob will be able to either. However, we are
>>> >> both eager to help out from afar to the extent possible. I will look
>>> >> into the organizational hierarchy this week.
>>> >>
>>> >> Best,
>>> >> Knut
>>> >>
>>> >> On Mon, Mar 21, 2011 at 5:54 AM, Alvin Marcelo<alvin....@gmail.com>
>>> >> wrote:
>>> >>
>>> >> Dear Knut,
>>> >>
>>> >> FYI...we will be hosting a Connectathon in Manila on April 11-13th
>>> >> (demo
>>> >> on
>>> >> April 12).
>>> >>
>>> >> One of the connections we wish to show the Secretary/ministry is
>>> >> OpenMRS
>>> >> to
>>> >> DHIS2 which I believe is already possible.
>>> >>
>>> >> I have added Patrick Whitaker and Xavier Bocken to our instance at
>>> >> http://109.74.202.200:8080/ph/dhis-web-maintenance-user/alluser.action
>>> >> to
>>> >> help us prepare for the connectathon...
>>> >>
>>> >> FYI..
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Alvin B. Marcelo, MD, FPCS
>>> >> www.alvinmarcelo.com
>>> >> Voicemail: +1-301-534-0795)
>>> >> GPG 0x99CBC54C
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Cheers,
>>> >> Knut Staring
>>> >>
>>> >>
>>> >>
>> >
>> >
>> >
>> > --
>> > Ryan Crichton
>> > Software Developer
>> > ry...@jembi.org
>> > http://www.jembi.org
>> >

[Bob Jolliffe]

On 5 April 2011 18:13, litlfred <litl...@gmail.com> wrote:
> Hi All,
> I am brining in here a conversation that some of us have been having
> concerning a standardized web services API for retrieving SDMX-HD
> data.  In particular so that accessing the data from openMRS, DHIS,
> iHRIS, etc should all nbe t  I've included below the thread and put a
> possible draft as a publicly editable google doc:
>  https://docs.google.com/document/d/1qdeQcUWNgGIt_ncU0Gw1F91b63vDMld9VnCIIYSz1Os/edit?hl=en&authkey=CIPo1LwM
>
> The one complaint we had about SDMX-HD at the Ghana unconference last
> year was that things should happen automatically without having to
> save files to the desktop and upload them some place else.  I think
> this is the first step to achieve this.

I am not as bothered about this as most. But I agree it is the right
way to go and we are moving in that direction regarding dhis
functionality not specific to sdmx. Has anyone had the opportunity to
study the SDMX web service part of the standard? I've not looked in
much detail and certainly not in some time, but it might be that we
end up implementing some simplified variant of this.

>
> There are enough folks doing java programming that it may make sense
> to have a separate java library that would provide the sdmx-hd web
> services client functionality. We (the iHRIS folks) are programming in
> PHP, anyone else?
>
>
> Bob,
>  We should expect, even for the HR data, that the DSD should change
> over time -- a new facility is opened, a new cadre of health workers
> is developed.  I think it is a reasonable expectation to be able to go
> through and get all the historical variants of the DSD.

Yes. I suppose what I was really getting at is that the key family
should be stable (I know people use these terms interchangeably). The
codelists referred to in the keyfamily - particularly cadres and
facility lists - will vary.

Bob

> --
> You received this message because you are subscribed to the Google Groups "SDMX-HD (Health Domain)" group.
> To post to this group, send email to sdm...@googlegroups.com.
> To unsubscribe from this group, send email to sdmx_hd+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sdmx_hd?hl=en.
>
>

[Xavier Bocken]

Of interest concerning availability of SDMX-HD messages via web services, one should note that WHO's IMR already offers a public web service enabling the download of indicator definitions in simple XML and SDMX-HD formats.

http://apps.who.int/gho/indicatorregistryservice/publicapiservice.asmx
http://apps.who.int/gho/indicatorregistryservice/publicapiservice.asmx?op=IndicatorGetAsSdmx
Sample parameters:
profileCode=who
applicationCode=system
languageAlpha2=en
indicatorId=1
sdmxVersion=1.0

The response is a base64-encoded ZIP stream conforming to the SDMX-HD specification.

Sample code on how to download SDMX-HD definitions from .Net code:
http://svn.sdmx-hd.org/sdmxhd/library/blue-infinity/trunk/Samples/Sample4.html

IMR being concerned only with indicator definitions, this web service is of use only to disseminate standard indicator definitions. It is of limited value when it comes to data exchange scenarios.

Best regards,

xavier bocken
managing consultant

direct + 41 58 307 7068
xavier...@b-i.com
www.b-i.com | visit our blog

blue-infinity headquarters
t +41 58 307 7000
f +41 58 307 7001
INTERNATIONAL
t +800 307 70 000
f +800 307 70 001

branding.technology.integration.
The information in this e-mail, and those ensuing, is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please destroy this message and notify us immediately.

Please think of the environment before printing this email

[Carl Leitner]

Thanks, I wasn't aware of this. There does seem to a RESTful version in 2.1 the draft, section 3
http://sdmx.org/wp-content/uploads/2010/12/DRAFT_SDMX_2-1-1_SECTION_07_WebServices2.pdf
Is this what you were referring to?

If so, at a cursory glance, I am happy enough with this...

Cheers.
-carl

[Bob Jolliffe]

On 6 April 2011 17:02, Carl Leitner <clei...@capacityplus.org> wrote:
> Thanks, I wasn't aware of this. There does seem to a RESTful version in 2.1
> the draft,  section 3
>  http://sdmx.org/wp-content/uploads/2010/12/DRAFT_SDMX_2-1-1_SECTION_07_WebServices2.pdf
> Is this what you were referring to?
>
> If so, at a cursory glance, I am happy enough with this...

Yes that is what i was referring to. If you are going to implement a
restful API and it is similar to that then maybe just implementing
that is a reasonable option. (Jo - not sure if you have looked at or
if it bears any resemblance to what you have in mind?)

Bob

[Carl Leitner]

Since this RESTful API is a part of the 2.1 draft specification, does anyone know if it will be backwards compatible with existing systems using the 2.0 specification. I did see this on the sdmx website in reference to the draft:
Backward compatibility with the SDMX technical specifications 2.0 is to be assured.
But I don't know if this applies to the RESTful interface...

Assuming that this is a non-issue, I in favor of using the draft specification.

Cheers,
-carl

[Jo Størset]

Den 6. apr. 2011 kl. 18.14 skrev Bob Jolliffe:

> On 6 April 2011 17:02, Carl Leitner <clei...@capacityplus.org> wrote:
>> Thanks, I wasn't aware of this. There does seem to a RESTful version in 2.1
>> the draft, section 3
>> http://sdmx.org/wp-content/uploads/2010/12/DRAFT_SDMX_2-1-1_SECTION_07_WebServices2.pdf
>> Is this what you were referring to?
>>
>> If so, at a cursory glance, I am happy enough with this...
>
> Yes that is what i was referring to. If you are going to implement a
> restful API and it is similar to that then maybe just implementing
> that is a reasonable option. (Jo - not sure if you have looked at or
> if it bears any resemblance to what you have in mind?)

Sorry, didn't see this before now. I've taken a quick look, as you know I never really understand the use of the term restful for api's that aren't hypertext-driven, but as a "url template" api it seems fine.

I think maybe you would be in a better position to say if it fits the need for interoperability between DHIS and other systems. But it seems to be limited to pull-based data transfer between systems, though ("data retrieval only"), which is the other way from what you've done in the cases you've tried out? I guess that would put more of the burden of api implementation in the hands of the systems delivering data, which might be a problem for adoption. I think we would like the implementation burden to be on the recieving end for most use cases?

Jo

[Bob Jolliffe]

yes, jo, I suspect you have the sense of it. My guess is that this
evolved in tandem with the sdmx repository software produced by
Metadata Technologies. So I imagine there is significant emphasis on
pulling and slicing and dicing data from the repository for reporting.
Naturally I agree it makes no sense for all producers of data to set
themselves up to look like sdmx repositories. Mind you, from a dhis
perspective, there is requirement that (i) data producers should be
able to extract a data structure definition (structural metadata)
message including codelists (ideally fine grained access to the
codelists) from dhis. And (ii) that they can post sdmx datasets to
dhis. It might well be that it is easier to roll our own api for
this or piggy back somehow on the evolving dhis web api. This seems
to be the pattern of requirements for exchange with dhis, whether
through sdmx, mobile xforms or dhis-to-dhis.

Anyone from the IMR team? What approach have you taken in terms of a
web service/rest/"uri template" api? I gather you decided early not
to follow the sdmx webservces spec. What seems to have worked well
and what not?

Regards
Bob

> Jo

[r.friedman]

Actually, from the SDMX point of view, it does make sense for everybody to
set themselves up as SDMX repositories. That seems to be the idea of SDMX,
that you find one repository, look at its metadata, decide if it's got
anything that you want, pull that in which you are interested, then find out
about other SDMX repositories from that one. The -HD idea of using push was
because so many of our sites are disconnected that pulling doesn't work.

-----Original Message-----
From: sdm...@googlegroups.com [mailto:sdm...@googlegroups.com] On Behalf
Of Bob Jolliffe
Sent: Thursday, April 14, 2011 4:51 PM
To: sdm...@googlegroups.com
Cc: Jo Størset
Subject: Re: Web Services API