Field Worker ID

[Peter WONTUO]

Dear OpenHDS Members,

 

Once again, greetings from Navrongo.  Before I pack off for the Xmas break, let me drop one more clarification on the Field Worker ID

I am not very sure if this happens at other sites but in Navrongo all employed staffs are provided with a staff number and a code.  This is purely an administrative requirement and hence assigned from administration.  Field workers then use these codes in completing any field documents that requires that a field worker code be filled.  To validate these codes, the application designer will need to know the field workers codes of that project to build in a check to prevent non-existing codes.

 

What I am seeing with the OpenHDS is an automatic assignment of Field Worker ID.  That is fine but I am not sure if this is the same as Field Worker Code, in the case of Navrongo and possibly other sites or OpenHDS is now generating its own Field Worker IDs different from what ever any institution has put in place?

 

Seasonal greetings

 

======================================================

Peter Wontuo (PW)

Health Research Officer (IT)

Navrongo Health Research Centre (NHRC) - GHS

P. O. Box 114 > > Navrongo KNED/UER - Ghana W/A

Tel:  +233-3821-22380(Director)/22310(Admin)/22716(Server Room)

Fax: +233-3821-22320 - Cell:  +233 24 4010034 / 20 7389978

Alt email: pwo...@hotmail.com; Peter....@gmail.com

Website: www.navrongo.org  NOTE the change in my email address to pwo...@navrongo.mimcom.ORG

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

·Adding manpower to a late software project makes it later.  Luke 6:41-42

 

 

[Dave R]

Hi Peter, I hope your holiday break was well. I believe that field
worker id and field worker code are the same, just different
terminology. So you are saying that the field worker codes are created
by the administrators rather than the system? Is there any validation
to verify the administrator cannot duplicate codes when they are
creating them? Do the administrators follow a pattern when creating
the id's? Is there an advantage to having administrators create the
id's rather than the system?

Currently, as you stated, OpenHDS is generating field worker codes
based on an id scheme that each site can customize. I'm sure we could
make further changes to allow sites to specify they would like to
manually enter in field worker codes if this is a requirement for
sites.

On Dec 22 2010, 5:09 am, "Peter WONTUO" <PWon...@navrongo.mimcom.org>
wrote:

> Dear OpenHDS Members,
>
> Once again, greetings from Navrongo.  Before I pack off for the Xmas
> break, let me drop one more clarification on the Field Worker ID
>
> I am not very sure if this happens at other sites but in Navrongo all
> employed staffs are provided with a staff number and a code.  This is
> purely an administrative requirement and hence assigned from
> administration.  Field workers then use these codes in completing any
> field documents that requires that a field worker code be filled.  To
> validate these codes, the application designer will need to know the
> field workers codes of that project to build in a check to prevent
> non-existing codes.
>
> What I am seeing with the OpenHDS is an automatic assignment of Field
> Worker ID.  That is fine but I am not sure if this is the same as Field
> Worker Code, in the case of Navrongo and possibly other sites or OpenHDS
> is now generating its own Field Worker IDs different from what ever any
> institution has put in place?
>
> Seasonal greetings
>
> ======================================================
>
> Peter Wontuo (PW)
>
> Health Research Officer (IT)
>
> Navrongo Health Research Centre (NHRC) - GHS
>
> P. O. Box 114 > > Navrongo KNED/UER - Ghana W/A
>
> Tel:  +233-3821-22380(Director)/22310(Admin)/22716(Server Room)
>
> Fax: +233-3821-22320 - Cell:  +233 24 4010034 / 20 7389978
>

> Alt email: pwon...@hotmail.com; Peter.Won...@gmail.com
>
> Website:www.navrongo.org<http://www.navrongo.org>   NOTE the change in
> my email address to pwon...@navrongo.mimcom.ORG
>
>
>
> *Adding manpower to a late software project makes it later.  Luke
> 6:41-42

[Peter WONTUO]

Hi Dave,
Nice to hear from you. Happy New Year. You have correctly raised a point that has to do with administration issuing codes. I completely agree with you with the duplications, re-use etc because there is no any efficient system to check that. If a site is running only HDSS ( which I think is not the case), then that will be okay but here is the case where other staff employed worked on other project, etc that has nothing to do with the HDSS activities.

Regards
Peter

--
You received this message because you are subscribed to the Google Groups "openhds-users" group.
To post to this group, send email to openhd...@googlegroups.com.
To unsubscribe from this group, send email to openhds-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openhds-users?hl=en.

[Dave R]

Hi Peter, thanks for the response. I now understand why field worker
codes would be input by administrators. I will raise an issue for this
in our issue tracker. Thanks again for the feedback.

Dave

On Jan 6, 10:09 am, "Peter WONTUO" <PWon...@navrongo.mimcom.org>

[Brian]

Hi Peter,

I think that I have addressed the issue you brought up with the Field
Worker Ids. I have allowed configuration for either manually entering
Field Worker Ids or having the system generate them. By default, Field
Worker Ids are now set to be manually entered. If a site wishes to
change this, then it can be customized. The system will adjust
properly in order for the Id to be generated or entered manually,
which ever is specified. The issue can be found here:
http://svn.rcg.usm.maine.edu/redmine/issues/show/434.

Thanks for your suggestions,
Brian

[Peter WONTUO]

Hi Brian,

That is great.
Thanks

Peter

-----Original Message-----
From: openhd...@googlegroups.com
[mailto:openhd...@googlegroups.com] On Behalf Of Brian
Sent: Tuesday, January 18, 2011 6:47 PM
To: openhds-users
Subject: [OpenHDS Users] Re: Field Worker ID

Hi Peter,

--

[Md. Abdur Razzak Ali Sorker]

Hello:
Is OpenHDS is ready to use now? Can we start piloting the system? If so is
there any easy way to upgrade the system with future release like other open
source software has?

Thanks
Razzak

[Peter WONTUO]

Hi Razzak,
Greetings from Navrongo. I think your questions are worth asking.
After the Nairobi workshop, I have not heard much about
"work-in-progress" and a showcase of the next product.

Regards

Peter

Thanks
Razzak

[Somnath Sambhudas (INDEPTH)]

Dear All,

I am also fully agree with Razzak and Peter. It will be great if someone let
us know the status of OpenHDS software. Tentative date of piloting /
lunching etc.

Warm Regards,
Somnath

Somnath S. Sambhudas
IT Manager,
INDEPTH Fellow
Cell - +91 9763715781
E-mail - somnath....@indepth-network.org 
Website - www.kemhospitalvadu.org
Website - www.indepth-network.org

[Brian]

Hello all,

My apologies for briefing you all sooner. We have been working on the
project but ever since January, we have been working with the Cross
River team located in Nigeria. We are obligated to customize the
OpenHDS for their site. They will be given their own implementation
which we are currently developing. That is primarily where our focus
has been. The changes that we have made to that implementation will be
applied back to the core OpenHDS in the coming months. We are hoping
to build a generic core system in which can be customized with minimal
effort so that other sites can tailor it to their needs. The Cross
River team is already pilot testing their implementation and we are
continuing to get helpful feedback from them.

As for the core OpenHDS, that has gone through periods of pilot
testing already so I believe it's in decent shape for that. However,
keep in mind that there is still more work that can/will be done. We
will update you all when updates are performed.

To answer Razzaks question: The best way to update the code is
probably to get the latest version from our repository with a
subversion client. That way, whenever we commit changes to the system
you will have the latest version as long as you remember to update.

I hope that helps to answer some questions,
Brian

[Md. Abdur Razzak Ali Sorker]

Hi Brian,
So many thanks for your email and letting us know the status. We had our
meeting with our site team and they are asking how long it will take as I
told them after back from Nairobi meeting that February 2011 is the
tentative deadline.

Regarding upgrade mechanism issue, I wanted to say that is there any easy
procedure to upgrade with next version after final installation and piloting
without losing existing data like other open source software. As last couple
of months we were testing the system and we had to download the new version
and perform fresh installation, though I assume there will have a good
upgrade procedure after stable version release.

One of the example is www.dspace.org they have very good procedure to
upgrade version without losing any configuration and data of the existing
system and I think this is necessary for OpenHDS as well.

2ndly is there any mechanism to define logic of ID generation through admin
panel like Fieldworker ID prefix will be XX- then 2 digit auto number etc
etc.

Thanks and Regards
Razzak

Md. Abdur Razzak Ali Sorker

Senior Manager
Application Development, Integration and Maintanace
Information Technology
ICDDR,B
Ext.# 3524

-----Original Message-----
From: openhd...@googlegroups.com [mailto:openhd...@googlegroups.com]

On Behalf Of Brian
Sent: Wednesday, April 13, 2011 7:38 PM
To: openhds-users

Hello all,

--

[Dave R]

Hi Razzak, thanks so much for the interest and we will do as much as
we can to help you get OpenHDS running. I'm not sure entirely what you
mean by upgrading? Do you mean like upgrading from version 1 to
version 2? Or do you mean upgrading as in keeping up with the latest
code changes?

On Apr 14, 1:02 am, "Md. Abdur Razzak Ali Sorker" <sor...@icddrb.org>
wrote:

> Hi Brian,
> So many thanks for your email and letting us know the status. We had our
> meeting with our site team and they are asking how long it will take as I
> told them after back from Nairobi meeting that February 2011 is the
> tentative deadline.
>
> Regarding upgrade mechanism issue, I wanted to say that is there any easy
> procedure to upgrade with next version after final installation and piloting
> without losing existing data like other open source software. As last couple
> of months we were testing the system and we had to download the new version
> and perform fresh installation, though I assume there will have a good
> upgrade procedure after stable version release.
>

> One of the example iswww.dspace.orgthey have very good procedure to

[Md. Abdur Razzak Ali Sorker]

HI Dave,
At this moment I am thinking about the version upgrading from 1 to 2 say
with keeping old data and that has to be an easy way. If we decided to start
work with current one and provide you feedback to incorporate something etc.

Hope this make sense.

And if we start work on this current version, what's your stand? If we can
start then can we upgrade that with new changes in future without losing
existing data and config?

Regards
Razzak

[David Roberge]

Hi Razzak, I hope all is well. As far as versions are concerned, we haven't really released a full blown, polished version of OpenHDS to the public yet. We have had 1 release (0.7.0), but it is really meant for piloting, testing and getting feedback. I imagine we would do everything possible to make the upgrade process as smooth as possible (without losing data) for users.

I would recommend you start with the current version (0.7.0). Though this version will allow for data entry, it lacks many critical features (e.g. reporting). So I don't believe this would be a good choice if you were looking for a production data collection system to use immediately. We still have much work we need to complete before we reach that status.

As Brian has said, we are in the middle of deploying and piloting OpenHDS with a team in Nigeria. This has been a very good learning experience for us. We've found we had to make several significant changes to OpenHDS to work with Cross River. Most notably, they had their own custom forms for data collection. 

This presents an interesting problem because as you can imagine, each site may have different forms they will use for data collection. It would be difficult for us to design an interface that would match each of these varying forms. One option would be to tell sites they must implement their own user interface to match the forms they use for data collection. This doesn't seem like a good solution.

An alternative would be for OpenHDS to provide a set of general forms that sites can use. In this case, the user interface would not need to change because it would be built from the forms provided by OpenHDS. But, this may restrict sites because they may not necessarily prefer the general forms (they may want more questions, not like the layout, etc.) Then again, all health demographic systems should contain a very core set of data to be collected, which is what OpenHDS is trying to achieve.

I think a first step in making OpenHDS production ready is defining the data collection forms OpenHDS would provide to health sites. We have the forms used by the Cross River team, and I think maybe altering them slightly could be a good first draft. I would hope we may get contributions from other sites to create the best possible data collection forms.

Or maybe this is not the right direction? Any comments or suggestions welcome.

Thanks

[Md. Abdur Razzak Ali Sorker]

Hi Dave,

So many thanks for your very good and comprehensive email. This cover all of my concerns and I was thinking in same way that will this system have a general forms which can use as generic for data collection interface and easy customizable. I was working in open source digital library software and there already have so many standard meta data format like Dublin Core Meta Data format, in that area it has been solved. openHDS needs something like that.

 

 I think to study all sites data collection forms and make a standard meta data format will be a big challenge but somehow it has to be there in openHDS.

 

However as you already thinking all of these concern. So let’s see.

 

 

Thanks once again and I appreciate your hard work and help……

 

 

Very best regards
Razzak

[Brian Hartsock]

Hi Razzak,

We actually do have a standard meta data format that OpenHDS is using, called DDI (Data Documentation Initiative, version 2). It can be accessed from OpenHDS under Utilities -> Study Document. DDI is much more verbose than Dublin Core, but it can be easily mapped to it. This meta data component of the OpenHDS was developed at the end of the summer of last year and we haven't had much feedback. If you could try it out and add suggestions, that would be great.

The reference to DDI can be found here: http://www.ddialliance.org/

Thanks,
Brian