HIFIS 4

Stop bundling the two types of consent together. Right now, Explicit consent (and only Explicit) consent governs whether the data is shared in HIFIS. CA consent governs whether the data shows up in the CA module. And CA consent can only be provided if Explicit consent is also present. So clients must have two different consent records, both with different start and end dates and attachments and so on. One problem with this is when you open up a client file, you cannot tell if a client (see attached) has just Explicit consent, or whether they have Explicit + CA consent. So a lot of clients have only Explicit consent because nobody notices the error, ever. How about this: the client only has one type of consent at a time. If someone provides CA consent, then we record a record that says "Coordinated Access" consent was provided. And a client's data is shared if either CA consent or Explicit consent is provided. So instead of a typical client having two different consent records, they only have one - either Explicit, or Coordinated Access.

Alright, community. Tell me what you think about this one! My idea is alternate client types . And I don't mean client states (active / inactive / archived / deceased) or even hidden / visible. This would be an entirely new thing. Regular Clients The type of client file that currently exists we are going to call "Regular." This works great for a normal adult recipient of services. So no changes for the vast majority of clients. Dependents So for the second client type, " Dependent " or you could call it Child or Minor, it doesn't really matter. When you have a child in a homeless family, you are not going to be offering services to them directly, and a lot of the information about the dependent should be inherited from the family head. I'm proposing that when you create a Client file that is a Dependent, the file itself behaves differently from a Regular file. You would eliminate a lot of the options in the Client Information and Client Management menus, and instead display inherited information. For example, the Dependent's housing history should probably, by default, be the Family Head's housing history. Dependents wouldn't have any income, so if you wanted to look up the Dependent's income, you'd look at their parents. Dependents wouldn’t be included in Coordinated Access. The purpose for this would be for easier use for users who deal with families often. If dependents behave less like individual clients, and more like characteristics of a family, it'll be easier to understand things like when we're serving families as opposed to singles. Anonymous Clients Then you would have a third client type, " Anonymous. " We have the Declined - Anonymous consent type and sometimes this leads to a bit of confusion. You can have a client declared to be anonymous but still record their birth certificate, do SPDATs and VATs, and Case Management, none of which makes any sense if the client is really Anonymous. So if you have an Anonymous client type, you really shouldn't be able to add anything identifying to it, which means those sections of the client file should be hidden or non-existent. In other words, most of the options in Client Information and Client Management should be gone. The purpose for this would be to help protect privacy and confidentiality for clients who are uncomfortable with data sharing, and remind staff of the importance of obtaining informed consent. Finally, you should have the ability to convert a client from Dependent to Regular or Anonymous to Regular.

Consider revision to way Programs/Services work Why? In most communities, clients enroll in a Program and they receive Services as part of the Program. A Program therefore is an umbrella that contains Services.  In HIFIS, clients receive Services, and Programs are attached to the Service. A Service therefore is an umbrella that contains Program. Fields attached to Services make more sense attached to program (i.e. reason for service, referred from), and would save time if client receives lots of services under the same program. Also, on program exit we want to know things like reason for exit and destination. How? Create a new screen to enroll a client in a Program. This screen would ask for some generic service fields (like Reason for Service), along with Program Enrollment Date. On add service screens (i.e. Shelter Book-in, add Goods & Services), take out a number of fields that are going to be consistent for the client across multiple services: Reason for Service shouldn't change much from one day to the next for a specific client, nor would Referred from, and so on. When a user adds a service, the Programs drop-down menu is populated by programs the client is currently enrolled in. If enrolled in none, have a button next to Program field that says “Enroll in program.” This would create a popup with fields as above (enrolling a client in a Program). When a service ends, give popup notification “Would you like to exit [client] from [program]?” If they say yes, go to a screen to exit the program, which asks for things like Reason for Exit and Destination at Exit. Future add-ons This concept (enroll in a Program) is VERY similar to the process to Add Goods & Services Transaction. Almost everything on the initial screen is basically covered under this concept of enrolling in a Program. If we added the ability to enroll clients in Programs, it would allow the Goods & Services module to be streamlined significantly!

When a client has a Case open, or a Housing Placement open or a Housing Loss Prevention open, there's a designated Caseworker. Can we automatically add that Caseworker, who is a user and who already exists in the system, as a Contact in the Contacts module ? Lots of communities would like to manually enter this but they find staff are forgetting to do it so it's never a reliable source of information. Yes, users could look up the Case Management Client List, but they'd also have to look up the Housing Placement list, and also the Housing Loss Prevention list, and that's a lot of extra clicks, and they may not even have access to all that information.