dhis2-users team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Carl,

I guess the real issue here is what is a facility? DHIS2 has no intrinsic
notion of what a facility actually is. In fact, there is no need to have
facilities at all. We could organize the hierarchy based on water points,
or villages, or implementing partners or even golf courses in some extreme
implementations. As you have noted in your mail, you may have facilities
spread out all over the hierarchy at different levels. So, the only way I
can think to do this would be to use an organisation unit group to
distinguish facilities from those orgunits which are not facilities which
would have some meaning to the external system.

Bob Jolliffe (on vacation at the moment) and I were discussing a similar
situation about syncing the orgunits. I am not sure what he finally decided
to do, but my feeling was that pulling a complete list of orgunits
(api/organisationUnits.xml) and then processing the "lastUpdated" and
"created" attributes would be the best way, as opposed to some sort of
partial sync.  All those units which have been added since the last sync
would need to be added, while all those updated since the last sync would
need to be updated. I guess this is going to depend a lot on the system you
are syncing with, but that API end point should provide this information.

The api/organisationUnits.xml will give you a listing or all orgunits. Use
the ?paging=false parameter to turn off the paging, and get the full list,
alternatively, using the ?page= paramater to go through each page
identified in the <pageCount> property.  Once you have this list, and
determined which orgunits you need  by 1. Filter facilities based on
membership in an orgunit group called "Facilities", 2) Filter this list to
get the orgunits you need to sync , you then access the API end point of
the particular orgunit
(example<http://apps.dhis2.org/demo/api/organisationUnits/ueuQlqb8ccl.xml>)
to get all the information about this orgunit. This URL is available from
the "href" attribute in the api/organisationUnits.xml endpoint.

The problem at the moment with the FRED API spec is that it only deals with
facilities. But there is usually much more in a DHIS2
hierarchy...districts, provinces, community health workers, etc. At the
moment, this is the scope of FRED, but there is usually more to what is
stored in the hierarchy in a DHIS2 instance, so what you get in the FRED
API is a lot more than just facilities. I think if implementers needed the
FRED API, then an orgunit group could be used to filter what gets exposed
in the FRED API and what doesn't. I do not see the need for a system level
flag to do this, but having the ability to filter what is in FRED and what
isn't might be a good thing.

Best regards,
Jason






On Fri, Aug 16, 2013 at 2:44 PM, Carl Leitner <cleitner@xxxxxxxxxxxxxxxx>wrote:

>  Hi All,
>
> Thanks for your feedback.  The one case of immediate interest is for
> Bihar, India.  As I understand, there are something like 13-14,000
> facilities spread across levels 4, 5 and 6 and looking at the metadata
> export.xml I couldn't see anything to distinguish facilities from blocks,
> districts, etc.
>
>  One thing we want to support in particular, is to be able to poll DHIS2
> for new facilities and automatically add them to iHRIS.  I know from the
> Meta-Data export.xml, I can look at the timestamps of the
> organizationalUnit and if I combine this with a
>
>  Lacking a good way to flag facilities, I am not sure how exactly the
> view would work.   I am also guessing that it would require more developer
> involvement at each implementation.
>
>  It sounds like the organizationalUnitGroup may be the best option, at
> least for the short-term.  The only drawback I would see is that if you all
> do decide to distinguish facilities in FRED, we may need or want to re-do
> the work to align with what you have done for FRED.   So if I know what
> direction you are heading with that, I can try and stay in alignment.
>
>  ------------------
>
>  Just to give you an idea of where we are on the iHRIS side of things, we
> already have the ability to load in organizational units and data elements
> from the Meta-Data export.xml.  We are using this to link existing
> facilities in iHRIS to the corresponding organizational unit in DHIS in
> order that we can report out data to DHIS in .dxf.
>
> http://www.ihris.org/wiki/Linking_iHRIS_Facilities_and_DHIS_Organizational_Units
> We are planning on adding the same linking for the
> administrative/geographic hierarchy soon as it is pretty trivial to do.
>
>  It would also be pretty trivial to swap from using the full meta-data
> export to the .xml exposed in
>   http://apps.dhis2.org/demo/api/organisationUnits.xml
> if it weren't paged.     There does seem to be a difference here though in
> what is exposed... you seem to have only the UID and not the ID.
>
>
>  Cheers,
> -carl
>
>
>
>  On Aug 16, 2013, at 5:15 AM, Jason Pickering <jason.p.pickering@xxxxxxxxx
> >
>  wrote:
>
>  Just wanted to add a clarification and another approach.
>
>  I stated incorrectly that the FRED API only returns the lowest level. In
> fact, it returns all orgunits, irrespective of their placement in the
> hierarchy. This obviously makes it challenging to distinguish facilities
> from districts. After chatting with Morten about this, something like
> "paramater.level=4" may be added soon, to be able to distinguish between
> different orgunit levels, but this would only work in you case, if all
> facilities are at the same level, which is often not the case.
>
>  The last approach, which may be simpler from an integration point of
> view perhaps, is the creation of an SQL view, which you can then call from
> the WebAPI documented here<http://www.dhis2.org/doc/snapshot/en/user/html/ch25s18.html> and
> here <http://www.dhis2.org/doc/snapshot/en/user/html/apcs07.html>.
>
>  Regards,
> Jason
>
>
>
> On Fri, Aug 16, 2013 at 11:00 AM, Lars Helge Øverland <larshelge@xxxxxxxxx
> > wrote:
>
>> To add to what Jason is saying.. Like suggested above there are at least
>> two approaches:
>>
>>  - Use the org unit level. One caveat is that all org units at a level
>> may not necessarily be facilities. To fetch all org units at the level you
>> can GET at
>>
>>  http://apps.dhis2.org/dev/api/organisationUnits.xml?level=2    (use
>> .json if necessary)
>>
>>  - Use a group. This is more flexible but requires that all facilities
>> obviously are put in that group. To get all units in a group you can GET at:
>>
>>  http://apps.dhis2.org/dev/api/organisationUnitGroups/w1Atoz18PCL.xml
>>
>>  where w1.. is the uid of the group and use whatever approach is most
>> feasible for each DHIS deployment. Some ideas for your use-case:
>>
>>  1. Make fetching of DHIS facilities configurable as an URL on the iHRIS
>> side.
>>
>>  2. DHIS could expose a special "/facilities" resource and we could do
>> the mapping on the DHIS side. But then we are maybe starting to step FRED
>> on its toes.
>>
>>  cheers
>>
>>  Lars
>>
>>
>>
>>
>>
>> On Thu, Aug 15, 2013 at 11:32 AM, Jason Pickering <
>> jason.p.pickering@xxxxxxxxx> wrote:
>>
>>>  Hi Carl,
>>>
>>>  This is of course going to depend on each implementation and what a
>>> "facility" actually means.
>>>
>>> As an example provides us this...
>>>
>>> http://apps.dhis2.org/demo/api/organisationUnitLevels.xml
>>>
>>> <organisationUnitLevel name="PHU" created="2011-12-24T11:24:22.935+0000"
>>> lastUpdated="2011-12-24T11:24:22.935+0000" level="4"href="
>>> http://apps.dhis2.org/demo/api/organisationUnitLevels/m9lBJogzE95";
>>> id="m9lBJogzE95"/>
>>>
>>> which defines the organisation unit levels, and we see "PHU" which I
>>> guess is the equivalent to the facility level.
>>>
>>> As an example.
>>>
>>> http://apps.dhis2.org/demo/api/organisationUnits/ueuQlqb8ccl.xml shows
>>> this has the attribute level="4".
>>>
>>> So, it is just a matter filtering out the orgunits which have a
>>> particular level means "facility" to you
>>>
>>>  The FRED API of course is the other alternative, but this will only
>>> work currently, if your lowest organisation unit is the facility level. In
>>> our case, the facility level is 4, but our lowest organisation unit is
>>> level 6, so FRED does not work for us. I do think it would be good however
>>> to indicate which level is the facility level, and this would be the level
>>> which is used by FRED. Of course, if you have facilities at different
>>> levels, (health posts for instance, which may be children of health
>>> centers), which could be problematic.But, an orgunit group "Facility" which
>>> would be part of an "Organisationunit group set" such as "Type" would also
>>> do the job, again filtering out the orgunits which are part of the
>>> "Facility" organisation unit group.
>>>
>>>  Regards,
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 15, 2013 at 11:09 AM, Knut Staring <knutst@xxxxxxxxx> wrote:
>>> >
>>> > Hi Carl,
>>> >
>>> > Just forwarding your question to this list, where it is likely to be
>>> seen by more people:
>>> > https://answers.launchpad.net/dhis2/+question/234034
>>> >
>>> >
>>> > We have run across the task of needed to get a list of the facilities
>>> in DHIS2 to export to other systems. My particular use case is with iHRIS,
>>> though I have need to do this for setting up provider registries which need
>>> to reference facility data that DHIS2 is the authoritative source for.
>>> >
>>> > Among several DHIS installations, It does not seem that there is a
>>> consistent way to easily determine which of the organizational units are
>>> facilities. I have been looking in particular at the metadata Export.xml to
>>> try to extract this data and although there are some heuristics that will
>>> get us 90% of what we want, I would like to have something we can
>>> consistently rely on.
>>> >
>>> > A few options come to mind:
>>> >
>>> > 1) request that DHIS2 implementations create an organisationUnitGroup
>>> called "Facility" and add each of the facilities to this group? Presumably
>>> we would request that they would also create additional
>>> organisationUnitGroups for each of the levels of the organizationGroup
>>> hierarchy (e.g. Block, District, State) and put all of this under a
>>> organisationUnitGroupSet called something like "Administrative Hierarchy."
>>> This would require no additional programming to the existing DHIS2 codebase
>>> as I understand.
>>> >
>>> > 2) Ask the DHIS2 developers to add a boolean flag, "Facility," to the
>>> main organisationalUnit record. Presumably this would be relatively quick
>>> to do.
>>> >
>>> > 3) Wait until this issue in FRED:
>>> >    https://github.com/facilityregistry/fred-api/issues/62
>>> > gets resolved and implemented in DHIS? This seems like it would
>>> require a fair amount of developer time and specification that is not yet
>>> done.
>>> >
>>> > I don't care to much which of the above options gets implemented (or
>>> even if there is another alternative that works better), but I would like
>>> to have a "best practice" to point to when trying to extract facility
>>> information from DHIS as XML.
>>> >
>>> > Thanks so much!
>>> >
>>> > Cheers.
>>> > -carl
>>> >
>>> >
>>>  > _______________________________________________
>>> > Mailing list: https://launchpad.net/~dhis2-users
>>> > Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~dhis2-users
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-users
>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>  _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-users
> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-users
> More help   : https://help.launchpad.net/ListHelp
>
>
>