Can you share your views on our new guidance for publishing humanitarian financing to IATI?

The IATI Technical Team have produced step-by-step information on how humanitarian actors can report their assistance to the IATI Standard. We’re keen to hear whether our guidance best supports humanitarian actors to:

  • Use the latest version (2.02) of the IATI Standard to access its new humanitarian features

  • Provide daily updates (when necessary) during the onset of emergencies so that up-to-date information is readily available to those on the ground

Our new guidance underpins the Grand Bargain commitment made at the World Humanitarian Summit in May to ‘publish to IATI within two years of the WHS’. By supporting organisations to meet this pledge, we aim to improve the operational effectiveness of global humanitarian action.

Please post your comments below on our new guidance by Friday 16th September.

Comments (29)

Brent Phillips
Brent Phillips

The guidelines are a good start, relative to improving humanitarian reporting, it would be a help to see IATI also generate a set of XML examples corresponding to common types of humanitarian operations.

Wendy Rogers
Wendy Rogers

Thanks Brent Phillips and I very much agree that it would be good to have some examples especially if they were real activities. Therefore now that we have the publishing guidelines we would be very happy to work with any publisher who would like help with humanitarian reporting. Publishers can as usual contact us at support@iatistandard.org if they are interested?

Yohanna  Loucheur
Yohanna Loucheur

Thanks to the DI team for developing this guidance and consulting the IATI community on it.

We have a few comments to share from Canada’s perspective trying to implement the new elements.

  • In Step 2 (“Mark the IATI activity with the humanitarian flag”), are we not selling this element short by only mentioning that it can help fast-track publishing? It’s main purpose would be to enable users to find humanitarian activity.

  • In Step 3 (“Define which emergency the activity is responding to”), there’s a bit of a contradiction between saying that “the humanitarian-scope @type and @vocabulary will always be as follows” (using GLIDE) and at the end of that step providing instructions for when an emergency is not listed on GLIDE. Clearly, the humanitarian-scope type and vocabulary will not always be from GLIDE. The instructions should rather say that GLIDE should be the default option.

  • In Step 4, a link should be provided to the UN humanitarian plans list, just like a link is provided to GLIDE in Step 3. In addition, instructions should be provided on how to code appeals or plans that do not appear on the UN list. Finally, to improve clarity, the last paragraph should be split in 2 as it concerns to very important and different topics - the reference data and @narrative field.

Looking at these instructions and discussing with colleagues made us realize that it would have been useful to be able to indicate a percentage for each emergency or appeal. For instance, the multi-location example provided in Step 3 would be much better if we were able to indicate that eg 25% of the project goes to the first location (Sierra Leone), 45% to the second (Liberia) and 30% to the third (Guinea). In this case the information can probably be derived from the geographic scope of the project, but in other cases it may not be possible.

Finally, the question of how to code projects that have both a humanitarian and a development component may require more discussion. I seem to recall that initial guidance from DI was that the humanitarian flag should be used for all projects that have a humanitarian component, even if it’s not 100% - the thinking being that it was best to cast the net broader than to leave projects out. Speaking for Global Affairs, we would not be able to distinguish the 2 components, even at the transaction level. This is where the DAC sector codes may be useful, as such projects would usually be coded with x% humanitarian aid and y% other (development) codes.

We will be looking into some of this in more depth in coming weeks and will share further thoughts and suggestions here.

Mark Brough
Mark Brough

Belatedly, a couple of quick thoughts from me on this:

On step 2, humanitarian flag, I agree with Yohanna Loucheur that the humanitarian marker could be used as a flag to identify all projects that are related to humanitarian response, even if the projects are only partly related to humanitarian. I can also see arguments for not breaking projects into humanitarian and non-humanitarian components, as seeing the integrated nature of a combined humanitarian+development project might be useful?

On step 6, sectors – I understand the reason for using DAC sector codes in the way suggested in the note, but maybe this makes it hard to understand the nature of a humanitarian intervention. If a project is education or health-related, you may only see something like 72050 - Relief co-ordination; protection and support services rather than any more detail than that.

Is there a better way of publishing that this is (e.g.) a “health project in a humanitarian response”? I know that you can use UN cluster codes, but there are only about ten of them and I wonder if using a parallel vocabulary then creates an unhelpful divide in the data between humanitarian and development projects.

A real world example of a project in IATI data currently:

  • on EC ECHO website, where the project is identified as supporting “Nutrition, therapeutic & supp feeding”
  • in EC ECHO IATI data, where the project is identified as “720” (Emergency Response)
Mark Brough
Mark Brough

Perhaps it would also be useful to list the minimum requirements of FTS or EDRIS (for EU Member States) for automatically importing information from publishers’ IATI data? I don’t know if that belongs in this guidance, but perhaps it could be a helpful way of encouraging / incentivising uptake.

Wendy Rogers
Wendy Rogers

Thanks to Yohanna Loucheur Mark Brough and all those who responded to our call to help develop IATI’s new humanitarian reporting guidance.

We will be updating our draft guidance to reflect the views received so far and will publish a new version for further consultation soon.

In the meantime, you are welcome to continue providing your views on how we best support humanitarian actors by posting here or email to support@iatistandard.org.

CartONG
CartONG

Wendy Rogers these are all very interesting discussions.
I’m allowing myself to step in the discussion to introduce the GeOnG conference we organize in Chambéry (France, 1h from Geneva) on October 17-19 : http://cartong.org/geong/2016
GeOnG is one of the biggest conferences in the world on humanitarian information management, with many experts from the IM, GIS and Monitoring & Evaluation from many major agencies present.
We’re having several discussions this year on the topics of data standards and operability (with a focus on the constraints of field operations, as always), with interventions from the Humanitarian Data Exchange platform among others, so we’ve thought the event could be of interest to IATI’s members and community.
Feel free to ping me if you have any question regarding the conference & potential interventions (please get back to me fast then since we’re finalizing the agenda): geong[at]cartong.org

Best regards.

Martin Noblecourt for the CartONG team

Wendy Rogers
Wendy Rogers

Many thanks CartONG for bringing this to the attention of the IATI community and I’m sure that those interested will contact you directly

Laia
Laia

I realize I am chiming in late, but I’d like to express support for a couple of the comments that have already been made.

On the humanitarian flag, I agree with Yohanna Loucheur and Mark Brough that it would be best for publishers to use this if any aspect of an activity is related to humanitarian response. The suggestion to split projects into two seems impractical, and I’d foresee many challenges for our members at least if this were the recommended guidance. I believe it would also be difficult for organizations to mark individual transactions as humanitarian if an activity has both humanitarian and development components.

On sectors, we have faced the same issue Mark Brough raises with the DAC sector codes: the humanitarian codes alone are not sufficient for understanding the nature of the humanitarian activities taking place. It seems like it would be ideal not to have to use two separate vocabularies to get at this (DAC and clusters), but I admit I’m not sure what the solution here is.

Finally - one general comment: it would be really useful to understand why it is important to provide all of the requested pieces of information. If you could provide publishers with some indication of how each element might be used by FTS or others, or what the rationale was for including those elements in this “humanitarian standard,” that could help organizations justify the investments they might have to make in adapting their systems to publish this data.

Ben Parker
Ben Parker

Correct me if I am wrong, but according to this dashboard page (http://dashboard.iatistandard.org/element/iati-activity_@humanitarian.html), there are almost no donors using the 2.02 humanitarian flag introduced over a year ago, even those signed up to the “Grand Bargain”.

I see ECHO but apart from them, which other donor has adopted this marker?

Thanks

Ben

Grand Bargain signatories:

Australia
Belgium
Bulgaria
Canada
Czech Rep
Denmark
ECHO
Germany
Italy
Japan
Luxembourg
Netherlands
Norway
Poland
Sweden
Switzerland
UK
US

Wendy Rogers
Wendy Rogers

Also Ben Parker it has been quite some months since your post relating to which organisations (notably Grand Bargain signatories) were using the humanitarian marker and it is good to now see from the IATI dashboard that there is now a much greater number of organisations stating to use the new humanitarian marker.

Yohanna  Loucheur
Yohanna Loucheur

Wendy, thank you for posting the revised draft guidelines for humanitarian data.

I went over the revised version and would suggest the following minor changes to increase their clarity and usefulness:

  • Step 1 ends by saying that activities should be encoded as per steps 2 to 7. Strictly speaking, step 7 is not about encoding and should be treated separately.

  • Step 2, under Exceptions, minor changes were made to soften slightly the notion that humanitarian and development activities should be split. Yet, you had received unanimous feedback that this would be impossible if not unadvisable. I would recommend to drop this part entirely. At the very least, the last sentence should be revised: saying that the flag should be added to the transaction rather than the activity contradicts all the feedback received above.

  • Increase clarity by adding a new step 3: Determine whether the activity responds to an emergency and/or an appeal. This will signal to readers that not all activities relate to an emergency or an appeal. Otherwise the current step 3 looks like a mandatory step (“Define which emergency the activity is responding to” does not leave room for the possibility that it may not relate to one).

  • In the current step 5 (which would now be 6), make readers’ life easier by providing the link to the UN cluster codelist.

  • Current step 7 is not about the elements or coding, so would suggest to create a new section (maybe called Publishing?)

We look forward to revised guidance on humanitarian data, and the results of the upcoming pilot.

Wendy Rogers
Wendy Rogers

Thank you Yohanna Loucheur and rather than create another version of the existing guidance here I shall flag these comments to our colleagues at FTS to integrate into the revised guidelines currently being worked on. Nick Imboden

Yohanna  Loucheur
Yohanna Loucheur

Thank you Wendy.

I’m a bit concerned about waiting for UNOCHA-FTS to correct the existing guidance.

You said in post 1132: “However, as part of the work for the Grand Bargain Transparency Workstream (and also for the IASC HFTT) FTS are going to be running a pilot during the first half of 2018 to start processing published IATI data and they are planning to further develop the existing guidelines as a result of that process.”

This means it would take several months to get new guidance. In the meantime, people looking for guidance may arrive here and use the note provided in Joni’s initial message.

I think it really would be better to correct the note before the pilot starts, especially with regard to the second bullet in my previous message.

Wendy Rogers
Wendy Rogers

Thanks Yohanna Loucheur and just to confirm that under current plans FTS are planning to revise the existing guidelines by the end of Dec 2017 (and so can pick up the amendments here) and then further revise them in light of any finding from the pilot (currently due to run to Jun 2018). Hope that helps

Yohanna  Loucheur
Yohanna Loucheur
Image removed. Wendy:

just to confirm that under current plans FTS are planning to revise the existing guidelines by the end of Dec 2017

Does anyone know where these guidelines are at? The version that Wendy shared last November (above) appears unchanged, but perhaps there’s an updated version available somewhere else? Nick Imboden , would you know?

Pelle Aardema
Pelle Aardema

Dear all,

Reviving an old discussion!
In the meantime, based on Wendy Rogers ’s initial draft, in collaboration with a.o. David Megginson Steven Flower Roderick Besseling Herman van Loon , the Netherlands ministry has developed DRAFT Humanitarian guidelines. Through this process we aim to achieve a common understanding and use of these data elements, serving multiple use cases - e.g. informing UN OCHA’s Financial Tracking Service (FTS).

We consider these guidelines as an addendum to the general NL IATI publication guidelines - in order to maintain the benefits of having linked and traceable IATI data.

Through these group discussions we’ve hopefully tackled most the points of discussion around the use of the humanitarian elements.

Looking forward to your thoughts and input! Either in the Google Doc, or in this thread.

We’re also planning a round of consultations with (a number of) our direct partners in humanitarian aid, to further inform the discussion.

Pelle

SJohns
SJohns

Thanks for sharing Pelle Aardema - I’ve added the combined comments from UK partners of the MFA who are receiving humanitarian funding. Would you be able to confirm your expectations about when MFA would expect to see organisations start to use these guidelines?

matmaxgeds
matmaxgeds

Hi all,

One of the difficulties we are having using IATI humanitarian data in Somalia (great that we can even have this issue though!) is that because the GLIDE sector-vocab=10 is not embedded into IATI, it is much harder to show our users what something that appears in IATI as

<sector vocabulary="10" code="7" percentage="35.00"/>
<sector vocabulary="10" code="9" percentage="35.00"/>
<sector vocabulary="10" code="11" percentage="30.00"/>

Really refers to. In order to decode this, we have to seperately maintain mirrors of the non-included codelists and most of the fragile states I work in have difficulty with this.

My preferred option would be for the GLIDE codelist to be brought inside IATI (where it could be maintained once, and benefit all) - it also seems fair that it should be given equal standing to the DAC codelist if IATI is serious about the Grand Bargain.

However, that seems a medium term aim? In the short term, it would be incredibly useful if humanitarian publishers using a non-DAC5 vocab could be encouraged to use the sector @narrative element therefore also give the human readable text. This means that if a codelist changes, our system/users are not left in the dark until we have time to update our local copies.

PS - If the the @narrative element could be mandatory for all non-included IATI code-lists this would be incredibly useful!

Yohanna  Loucheur
Yohanna Loucheur
Image removed. matmaxgeds:

PS - If the the @narrative element could be mandatory for all non-included IATI code-lists this would be incredibly useful!

Sorry, but no. Making the @narrative attribute mandatory would defeat the purpose of having moved from words to codes in the codelist. If a publisher’s codelist narrative is in eg German, or Chinese, or French, having @narrative won’t help most users. The solution cannot be to provide @narrative in every possible language - we’re already getting into trouble because IATI files are too big.

Isn’t it the/one job of APIs to fetch the narrative that corresponds to a given code?

matmaxgeds
matmaxgeds

Image removed. YohannaLoucheur:

Isn’t it the/one job of APIs to fetch the narrative that corresponds to a given code?

Yes, except the humanitarian code-list is not included - hence why we are in this pickle - see http://reference.iatistandard.org/203/codelists-guides/codelist-management/ it is classified as ‘Non-Embedded Codelists - External’ and so not available through the code-list API.

I have requested that it would really help if it was included but no luck so far - hence my latest suggestion of using @narrative elements to help out.

I would definitely take a French, German, or Chinese narrative as it is much better than just a number! The @narrative element is already used in this way by publishers using e.g. 98/99 sector vocabs and it really helps us.

Bill Anderson
Bill Anderson

Image removed. matmaxgeds:

My preferred option would be for the GLIDE codelist to be brought inside IATI (where it could be maintained once, and benefit all)

matmaxgeds I assume you mean IASC Cluster codes. Can you not use this? http://vocabulary.unocha.org/json/beta-v1/global_coordination_groups.json

And for GLIDE numbers there is this post - New GLIDE number source available

Image removed. matmaxgeds:

it also seems fair that it should be given equal standing to the DAC codelist if IATI is serious about the Grand Bargain.

Personally, I think this is definitely worthy of consideration. Amy Silcock Petya Kangalova what do you think? (Not for GLIDE numbers, however, as the list changes too often)

matmaxgeds
matmaxgeds

Hi Bill Anderson - good spot, thanks - I am mixing up the IASC codes with the GLIDE numbers. I mean the IASC Cluster codes.

I can definitely use the links you post, but writing a separate scraper/parser in country-systems for each of the non-core external codelists is prone to failure / not very sustainable (someone has to be constantly monitoring in case they break etc, and who fixes them when they do…) - hence we often don’t manage it and the users get stuck with codes not names.

It would be great if IASC could get included, and for the others, I am starting to think that as a group of users, we should think about maintaining a joint resource mirroring the IATI codelist repo that fills this gap - Andy Lulham pointed to something similar on a past post - at least then we would all be consistent between users, and benefit from each-others efforts rather than each re-inventing the wheel.

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

I am starting to think that as a group of users, we should think about maintaining a joint resource mirroring the IATI codelist repo that fills this gap

This is well and good but I think this touches on the tensions that are again creeping into some of our discussions (and yes, as an ex-member of the Tech Team, I can get defensive at times).

The community can, and does, produce a range of great tools and services. Voluntary contributions, however, are, by definition, not necessarily sustainable: people move on and leave legacy tools behind. With the best intentions in the world the open data / open source community is not, at the end of the day, accountable to the kind of demands expected of a professional team employed to maintain a global standard.

What the IATI Technical Team is attempting to do is consolidate core products, tools and services that are both reliable and sustainable.
This involves two things:

  • For a number of historical reasons (discussed elsewhere) they have a mountain of technical debt to deal with as part of this consolidation.
  • Establishing a robust architecture that enables the entire IATI core digital estate to be sustainably interoperable, whether developed and maintained in-house or outsourced.

Some in the community may indeed from time to time be frustrated by their efforts. I think the team understands the impatience of the community. They can handle that. But they get frustrated when their integrity is questioned…

Bill Anderson
Bill Anderson
Image removed. matmaxgeds:

I am starting to think that as a group of users, we should think about maintaining a joint resource mirroring the IATI codelist repo that fills this gap

This is well and good but I think this touches on the tensions that are again creeping into some of our discussions (and yes, as an ex-member of the Tech Team, I can get defensive at times).

The community can, and does, produce a range of great tools and services. Voluntary contributions, however, are, by definition, not necessarily sustainable: people move on and leave legacy tools behind. With the best intentions in the world the open data / open source community is not, at the end of the day, accountable to the kind of demands expected of a professional team employed to maintain a global standard.

What the IATI Technical Team is attempting to do is consolidate core products, tools and services that are both reliable and sustainable.
This involves two things:

  • For a number of historical reasons (discussed elsewhere) they have a mountain of technical debt to deal with as part of this consolidation.
  • Establishing a robust architecture that enables the entire IATI core digital estate to be sustainably interoperable, whether developed in-house or outsourced.

Some in the community may indeed from time to time be frustrated by their efforts. I think the team understands the impatience of the community. They can handle that. But they get frustrated when their integrity is questioned…

matmaxgeds
matmaxgeds

hi Bill Anderson - will email to try and not derail the thread. Summary - agreed that discuss is far too combative these days - lets make plans to improve it in Copenhagen - understood that IATI Technical Team cannot take this on at the moment - so thought that suggesting the community stepped in was being supportive - keen to hear if there would be friendlier ways to do that.


Please log in or sign up to comment.