HSLynk Survey Service Open items - servinglynk/hslynk-open-source-docs GitHub Wiki

Gap between HOME APP's requriements for bulding a survey and current HMIS capabilities to facilitate survey creation.

  1. Questions and Picklists**

Currently, HMIS API maintains picklists seperately and provide APIs to associate the picklist with the questions. However, HOME APP for serveral reasons would like to have the picklist values maintained or contained with in a question itself, essentially having the question independent and to have its own merit.

When asked about the redundancy in maintaining the same set of picklist values for different questions - HOME APP mentioned that, its highly unlikely that two questions will have the picklist values. Also, HOME APP Team mentioned, maintaining picklist values is always at the expense of messing up the surveys as changing the picklist values accidently can potentially jeopordize all the questions where this picklist is used.

from Eric: Speaking with Surya, it's not about the independence of picklists and questions (that is good to avoid redundancy, which other customers may want), but about the embedding of a snapshot of a picklist at a point in time of creation with the question. Providing #2 in this list should resolve this, per Surya.

  1. Ability to store survey definition**

Secondly, HSLynk currently do not provide the ability to build an entire survey - more specifically , score calculation due to the complex nature of these surveys. Given the type of surveys and possibility to create the custom surveys, there is no standard model that HSLynk can provide to be able to define the rules for score calcualtions or any other rules to efficiently administer a survey.

from Eric: We do currently provide the ability to store surveys. We do not store complex score computation beyond summation of sections. We agreed with the Vi-SPDAT process that HOME app would calculate and override scores. We could store the rules with an additional feature, but in the meantime, the partner app can store the survey scoring rules. We would not validate the rules at first. We would just store it at first, and publish the syntax for rule definition.

However, for HOME APP to be able to use HSLynk , there should be a way to store or maintain the survey definition (which includes not only the sections, questions and answers but also the rules and score determining logic associated with the survey). One of the proposals that was discussed is to maintain the survey definition as a JSON document in HSLynk so , the survey can be stored in HSLynk and can be retrevied by HOME App's survey builder.

Sample survey definition (the output from the survey builder looks like this)

  1. Ability to store complex responses**

Few of the surveys can have questions that could have multiple answers - Like enter the first name, last name and DOB of the children in the household. The response to this question is probably in the form of a Table/ Grid (assume that there are 5 children in the household). However, maintaining this responses as a json in HSLynk , might not work from a HIVE reporting standpoint. HOME APP would like to know if there is any efficient way to maintain the repsonses for these kind of questions, without compromising on the reporting side from HIVE views.

Eric comment: We can do this, however, household should be stored using our HUD and global household APIs, so this particular example is not a best practice. Sandeep has indicated we can program into Hive JSON parsing, without issue.

  1. Ability to migrate a client from one schema to another schema**

HOME APP mentioned that there could be client who belong to 2014 taking the 2017 survey . In this scenario there is no way they can post the responses as the client cann't be found in 2017 schema and possibly update client's information from the survey responses. HOME APP would like HSLynk to be able to identify these clients based on the dedup ID and migrate the client to the schema year to which the survey belongs to. Essentially, we need to deal with the client's dedup ID as opposed to client id, so we can migrate the client / create the client in the new version specific schema.

Eric response: migrating between HUD schema versions is fraught with logical model hurdles. We will have this API functionality within 1-2 years, but not 1-2 months. Input: source schema year & global client id & target schema Output: new target schema client id

HOME APP's sample survey tool (Need to login to home.ctagroup.org to view this)