General Human Services Requirements
Eric Jahn edited this page Oct 16, 2016
·
9 revisions
- Create a general “customer” that is separate from an HMIS project group. A customer is exactly only that: a paying customer linked to a billing method. A customer may possess many project groups which could each be Continuums of Care or statewide roll-ups, etc.. We already have project groups, but a project is an HMIS specific concept. However, with generalized human services, we could simply have a customer using non-HMIS features, and therefore wouldn’t contain any project groups.
- A customer could manage all the organizations set up within it.
- A customer would contain one or more users with the customer admin role. This customer admin role could create new organizations and set up users with a new organizational admin role.
- The customer entity should be included in a new “Normative Human Services” schema, and not within the base schema, which just contains cross-schema mappings (shared IDs).
- APIs should exist for the customer entity (at least basic CRUD APIs), and using them, the super admin can create and manage customers.
- Support a grouping of services. This could map to a community defined region, a funding source.
- Service groups can overlap.
- Could be the unit to which client consent is granted, for flexibly defined regions.
- APIs should exist for the service group entity (at least basic CRUD APIs), and using them, the customer admin can create and manage service groups.
- Support a generalized "organization" to be placed within a “customer”. This generalized organization is different than the more narrowly defined HMIS organization found in the HMIS Data Standard schemas (i.e. 2014, 2015, 2016). The general organization may or may not be associated with an HMIS Continuum of Care (if they were associated, that mapping would be declared within the base schema). The general organization could be used by the customer to represent real 501c3s, or other official designations, for-profits, government agencies, international or otherwise, or whatever the customer wants to define as an organization. It could also represent an arbitrary unofficial grouping a customer desires to set up.
- A customer can have zero or many generalized organizations within it. Instead of generalized organizations, a customer could just have HMIS organizations, or both types of organizations together. But a customer must have a least one of either type of organization, or else it would contain no data.
- The generalized organization could map to a specific HMIS organization within the 2014-16 schemas. That mapping could exist within the base schema.
- The generalized organization should have a new role "organizational admin" that can manage users just within the organization, which would include all the organizational subdivisions.
- The generalized organization should be included in a new “Normative Human Services” schema, and not within the base schema, which just contains cross schema mappings (shared IDs).
- APIs should exist for the general organizational entity (at least basic CRUD APIs), and using them, the customer admin can create and manage organizations.
- Add a new “subdivision” entity within the generalized organization described above. An organization is really the top-most subdivision.
- Subdivisions can contain one or more other subdivisions, so they can be leveled. All would roll up into the parent organization.
- Subdivisions would have a new role for managing the users within that subdivision and its children: the subdivision admin.
- An HMIS project is a type of organizational subdivision, and there can be 1:1 mappings between HMIS projects and subdivisions within the base schema. An HMIS project, itself though, probably should not be allowed to have subdivisions, as this could create complexity and is outside the HMIS Logical Model and HMIS Data Standard.
- The organizational subdivision should be included in a new “Normative Human Services” schema, and not within the base schema, which just contains cross schema mappings (shared IDs).
- APIs should exist for the subdivision entity (at least basic CRUD APIs), and using them, the organization admin can create and manage subdivisions.
- Allow for the data sharing between any two subdivisions, even across customers. A precondition for this sharing to actually be allowed is client consent, on either a blanket or record level.
- A GUI to manage this.
- Allow for the upload of client release documentation (images) to be stored within the data warehouse.
- Releases of information are able to be constrained by time and by organizational subdivision.
global households - functionality completed - see https://anypoint.mulesoft.com/apiplatform/apis/#/portals/organizations/1d2d1eb1-46af-4ee8-aa04-bd79ed2764a3/apis/66146/versions/68740
- Non-HMIS, regular global households are already implemented in HMISLynk. These allow for the arbitrary groupings of families, and have nothing to do with HMIS enrollments.
- Entities would allow communities to track data on things that are not clients. The entity could be configured as:
- homeless encampments,
- other defineable groups and categories
see: https://github.com/servinglynk/hmis-lynk-open-source-docs/wiki/Information-and-Referral
*with goals needs, notes, need fulfilment