-
-
Notifications
You must be signed in to change notification settings - Fork 2
HMIS Data Elements and the Survey APIs
Eric Jahn edited this page Jul 17, 2017
·
5 revisions
The Survey Tool allows administrative users to create custom surveys (unscored) and assessments (scored). These surveys can take any form, but the questions and answers have no enforced relationships. For example, the HOME App has implemented the custom VI-SPDAT assessment. The VI-SPDAT has sections, with picklists, but there is not a complex logical model underlyng the questions. There are just sections in the VI-SPDAT. But, how do we address a scenario where a customer wants to implement a survey consisting of very controlled questions and answers, where there are also complex relationships and cardinalities between sets of questions (i.e. a complex logical model)? How do we enforce the relational integrity of the response data values of this controlled survey?
- Many of our customers wish to use the HOME App to create custom surveys partially or wholly consisting of HUD HMIS data elements, from a specific schema version year, like 2016 or soon 2017. These custom surveys could also contain some customer specific data elements that are not from the HUD HMIS data standard, interspersed along with the HUD ones
- Customer would be able to create/POST new survey questions mappable to a specific data element questions from a HUD HMIS version-specific schema. [Also, dynamically retrieving a list of data elements short names from the version specific HUD HMIS APIs would be useful for the HOME Survey design tool finctionality]. Customer could dynamically pin the allowable response values to our controlled schema’s (e.g. HUD HMIS version specific schema, say 2017) allowable picklist values. If we change an allowable picklist value in our version specific schema, then the customer’s custom survey picklists change dynamically, with no customer changes needed.
- HUD HMIS data element responses are correctly stored in the original version specific schema, not in the survey schema. So, the survey responses would simply be POSTed to the HUD HMIS version specific schema APIs. All that is stored in the survey response is the ID of the specific HUD HMIS data element value, or the url of the value accessible via a GET request to the HUD HMIS version specific API being used. This way, the HUD HMIS version specific schema elements are correctly stored with its relational integrity controls, and not in the survey responses schema.
- HSLynk implements an API (within each of the Version Specific Schemas) to retrieve all of an HUD HMIS version specific schema’s data elements via HTTP GET. It would be really great if this retrieved list were dynamically generated from HMIS version-specific Postgres schema metadata or Java POJO Entity Model info, but that might not be readily attainable. The Survey API is also modified with a backwards compatible version 1.1 to store new questions linked to these data types.
- The HOME App programmers could implement the back-end POSTing of responses to the HUD HMIS version specific schema on their own.
- The HOME App Survey Tool would be revised to be able to add any of a HUD HMIS version specific schema’s data elements. The questions and responses would be locked by the HOME App, so that survey administrators could not attempt to modify the questions and responses, since they are dynamically provided by HSLynk’s APIs.
- In the future, we could add more linkages from new schema, not just HMIS, to the Survey builder. Other schema like HL-7, or maybe CMS schemas, to name a couple.
- The HOME App Administrators would use this revised Survey Tool to create a survey containing HUD HMIS 2017 data elements, or even a survey with a mixture of community-specific data elements and HUD HMIS version specific data elements.
- When this survey is created and saved by a HOME App administrator, users could start completing the new surveys. Behind the scenes, as the users fill out responses to HUD HMIS version specific schema data element questions, the HOME App just makes regular POST calls to the HUD HMIS version specific schema APIs to store the survey question responses. Instead of storing the actual question response in the HSLynk Survey Tool schema, simply a link to the data element response is stored in the HSLynk Survey schema, retrievable via a regular already existing GET call to the HUD HMIS version specific schema API. Now, HUD reports can be run off this data using our existing Big Data warehouse views. If the survey responses need to be viewed as a submission set (maybe by a HOME App user), the survey submission records contain links to all the response values retrievable via the HMIS API url links stored in the HSLynk Survey Tool schema.
- A given schema can be made “Survey Tool Accessible”, not just HUD HMIS version specific schemas. This means that all its data element names and allowable picklist values can be retrieved via a GET call. Then, HSLynk users (via apps like HOME) can create surveys, and add locked dynamically retrievable questions with dynamically retrievable allowable picklist values for those questions.
- Survey Tool APIs can be used to create a survey containing HSLynk schema data elements from HSLynk schemas that have been made “Survey Tool Accessible”. Or a survey could be created that contains a mixture of both community-specific data elements and HSLynk shema data elements.
- When this survey is created and saved using HSLynk APIs, users could start completing the new surveys via the HSLynk Survey Tool APIs. Regular existing HSLynk schema APIs are POSTed to, to store the survey question responses. Instead of storing the actual question response in the HSLynk Survey Tool schema, simply a link to the data element response is stored in the HSLynk Survey schema, retrievable via a regular already existing GET call to the specific HSLynk schema API.
- Reports can be run off this data using our existing Big Data warehouse views. If the survey responses need to be viewed as a submission set, the survey submission records can retrieve all the response values via the HSLynk schema API url links stored in the HSLynk Survey Tool schema survey response values table.