IHRIS Collect Design Overview: Difference between revisions

From IHRIS Wiki
(Created page with 'iHRIS Collect is intended as a one-time data collection survey tool built on the I2CE Framework. ==Motivation== *Moving from a paper based system directly to iHRIS Qualify or iHR...')
 
Line 28: Line 28:
*create a PDF version of the survey for paper-based collection
*create a PDF version of the survey for paper-based collection
*exporting survey to something be imported to make PDA/hand-held survey tools.  also provide need to provide a means to sync the data from the hand-held
*exporting survey to something be imported to make PDA/hand-held survey tools.  also provide need to provide a means to sync the data from the hand-held
**[http://www.episurveyor.org/user/index|epi surveyor]
**[http://www.episurveyor.org/user/index epi surveyor]
**[http://www.episurveyor.org/user/index| open data kit]
**[http://www.episurveyor.org/user/index open data kit]
**[http://www.openxdata.org/| openxdata]  
**[http://www.openxdata.org/ openxdata]  
**[http://www.epihandy.com/index.php/Main_Page | epihandy] and and [http://code.zegeba.org/EpiHandy/wiki/OmevacDevelopers|omevac]
**[http://www.epihandy.com/index.php/Main_Page   epihandy] and and [http://code.zegeba.org/EpiHandy/wiki/OmevacDevelopers omevac]
 
 
 


==Other Documents==
==Other Documents==

Revision as of 10:05, 3 September 2009

iHRIS Collect is intended as a one-time data collection survey tool built on the I2CE Framework.

Motivation

  • Moving from a paper based system directly to iHRIS Qualify or iHRIS Manage often involves difficulty as the data is not cleaned. So this is really a three step process:
    • collect the data
    • put the data into electronic format
    • clean up the data
  • Introduces administrators/developers to the I2CE framework so that they have familiar systems as the move from the data collection process to the routine data entry
  • If data entry clerks are maintained between the one-time data collection process and the routine data collection, they will have a similar system which reduces training

Staged Implementation

There are several possibilities for a staged implementation. The stages do not necessarily need to be completed in order. They more reflect a break down into functional units that will ultimately benefit iHRIS Manage, Qualify and Plan.

Stage 1:Branding/Single Form

In this stage, we develop the branding and provided a basic implementation for iHRIS Collect:

  • Settle on the name (iHRIS Collect)
  • Choose color scheme and update CSS. I vote for beige.
  • Build off of iHRIS Common -- may need to break up iHRIS Common into some sub-modules.
  • Assume each page to edit only contains one form. Assume the developer can manually define a form in magic data
  • The html template files are build by hand by the developer for each form.
  • A survey page: is a form and its associated template file. Each such page should be packaged as a module and assigned a task to view/edit the data.
  • To enable custom reporting, for each form one needs to define the relationship which contains just the form as a primary form.
  • perhaps we can write a script to automate this once the fields (and their types) for a survey are defined.

Stage 2:Custom Pages

Implements Custom Pages to allow the system administrator to easily create pages based on existing forms in the system.

Stage 3:Custom Forms

Implements Custom Forms to allow the system administrator to easily create custom forms. This can then be used to build custom pages.

Stage 4:Custom Page Displays

As the custom pages will general follow a similar architecture to the custom reporting tools, we can extend the functionality of the custom pages by adding in custom displays. Here are some possible displays:

  • create a PDF version of the survey for paper-based collection
  • exporting survey to something be imported to make PDA/hand-held survey tools. also provide need to provide a means to sync the data from the hand-held

Other Documents

Stage 4:PDA