hifisfeedback.acreconsulting.ca Open in urlscan Pro
46.51.204.179  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Feedback Changelog Coming Soon
Person Circle


HIFIS FEEDBACK

Here we can discuss new ideas, suggestions, and solve issues to improve HIFIS
together.


CHANGELOG

Here we can discuss new ideas, suggestions, and solve issues to improve HIFIS
together.


FEEDBACK

Here we can discuss new ideas, suggestions, and solve issues to improve HIFIS
together.
Search
Create a Post
We're sorry but this app doesn't work properly without JavaScript enabled.
Please enable it to continue.
HIFIS Feedback
Here we can discuss new ideas, suggestions, and solve issues to improve HIFIS
together.
Changelog
Coming Soon


HIFIS FEEDBACK


HERE WE CAN DISCUSS NEW IDEAS, SUGGESTIONS, AND SOLVE ISSUES TO IMPROVE HIFIS
TOGETHER.


Create a Post
Sort by
Trend
Top
Newest
Filter results
CategoryAll
StatusAll (not closed)
Tags

Refresh Results
5
Book-Out leads to Add Housing History
When a client does a book-out, the Reason for Discharge field is mandatory. If
the user selects one of the housed options, like "Housed - Independent" for
example, HIFIS should automatically be adding a Housing History record. Here's
what I'd like to see: 1. A user does a book-out and on the Book Out screen,
selects a housed option in reason for discharge 2. The user clicks save 3. HIFIS
detects that one of the "housed" options has been selected, and redirects the
client to the Add Housing History screen 4. The Add Housing History screen
should automatically enter the start date = the date of the book-out 5. The Add
Housing History screen should automatically select the Housing Type (looked up
from the Reason for Discharge) 6. The user can then add the rest of the details
and hit save. This would go a long way to ensuring that housing status and
housing transitions are being calculated correctly, and make the CHR have better
data, and result in less work for shelter staff.
Feature Request
5
Make consent uploads mandatory
Currently, can't make the attachments field in Consent module mandatory or
disabled.
Considering Feature Request
4
Encampments mixes up two concepts
What is an encampment? It's a group of tents together in an area that I can see
when I walk down the street (or through the woods, or wherever). But an
important aspect of encampments is that they change over time. Today, there
might be 10 tents, next week there might be 15, and in the spring, there might
be only 5 remaining. The point is that there are kind of two key data points
here: where the encampment is and when. Now the Encampments module does contain
both of these elements, but here's the problem: it's not possible for someone to
pull the data in such a way that allows them to track a single encampment over
time. Let's dive into this a little deeper: There's an encampment in Kingston
called Belle Park. It's in the news, everybody knows about it. So I'm an
outreach worker. I go to Belle Park and then load up HIFIS. I can create a new
Encampment in HIFIS, name it Belle Park, and say there are 10 people there. And
today is November 13. That's fine. But what happens next week? I come back
again, and now there are 12 people. So I have two choices: I can edit the
existing Encampment record, and replace the count of there being 10 people last
week with a record that there are now 12 people. The single "Encampment" record
can only store one population count. Or, I can create a new Encampment. I choose
the latter. So now I've created a second Encampment record, it's also called
Belle Park, and it has 12 people. But now what am I supposed to do about the
dates? For the first Encampment record, am I supposed to add an End Date?
Because there are still people in the Encampment. What am I supposed to do for
the Start and End Date for the second Encampment? It's really not clear what
you'd use the dates for, so I can foresee that you'd have like 20 copies of
"Belle Park" that are all "Active" and have random dates associated with them
that don't make sense. And the important thing is I can't roll them up, I can't
categorize them so that I can track trends over time, because the Encampment
field is a free text instead of a drop-down. So if I spell Belle Park with lower
case versus upper case those count as different things, and maybe there might be
other terms people might use like "Belle Park Encampment" or "Belle Island" or
"Belle Tent Park" that once again are not the same. So the Encampments module is
conflating two important but related concepts: - The first is a physical
location. The physical location of the Encampment. I would call this record in
HIFIS an Encampment. Belle Park is the encampment, not Belle Park on November
13. - The second is a population count on a date-stamp. This is somewhat like a
PIT count. On Nov 13, we found 23 people. On Nov 15, we found 25 people. So you
need a bunch of sub-records of counts, connected to the parent record. The
parent record being the Encampment. I would call the sub-records Encampment
Counts or just Counts or Enumerations.  You could conceptualize it like a Case
file that has multiple Sessions within it; a Housing Placement has multiple
follow-ups; etc.
Planned/In Progress Feature Request
4
Duplicate Clients in CA module (Consent)
The Coordinated Access module shows duplicated clients when clients have
multiple open Coordinated Access consents. (Which could occur when you merge two
client files.) **Workaround:** close one of the open Coordinated Access consent
records.
Bug
4
Ability to disable explicit consent option
We are currently running build 4.0.59.5. I have an consent related enhancement
request to submit for a future HIFIS patch. We would like to be able to disable
the “Explicit” consent type option in the consent drop down when creating a
client or a consent record. When we upgraded our HIFIS instance from 58 to the
59 version, we selected the option to convert all our Explicit consent records
into Coordinated Access + Explicit consent, since our consent form already
included consent for entry into the Coordinated Access system. We are running
into a process issue where we can not stop users from selecting the “Explicit”
option when creating new consent records, when really they should be selecting
Explicit + Coordinated Access consent. This results in clients being created
with only the Explicit record (just like they used to be prior to v59) and thus
are missing from the CA list, even if they meet all the other criteria. We have
tried to train workers not to use the “Explicit” option, but unfortunately we
have a lot of users who are not understanding this requirement to get their
clients into the CA system, even after multiple reminders. The only way we can
fix this currently is our HIFIS coordinator reviewing a custom report and adding
the missing CA consent. If we had some other way to prevent “Explicit Only”
clients from being created, it would increase our data quality for the ESDC
export as well as save our coordinator a lot of time manually reviewing the
files that have explicit consent but are missing CA consent. This would affect
the add client screen (with enforce consent) where we would like the ability to
remove “Explicit” as an option. This would also affect the Client Management ->
Consent screen As well as the Enforce Consent popup when that setting is
enabled.
Considering Feature Request
3
Manually archive reports
Reports can get archived when the version of the report itself gets updated, but
can I put in a request for a way to manually archive/delete reports our
community doesn't use anymore? For example, the Unique Identifier List is also
irrelevant now that 59 exists, and multiple of the new reports have 59 and 60
versions.
Feature Request
3
Display Service Provider Right
When a user has only the "Display Service Provider" right, it doesn't actually
allow them to Display the Service Provider (i.e. go to Administration > Service
Provider or access /Organization/OrganizationDetails/123456). Instead, they get
the "you don't have sufficient rights" error message. **Workaround:** grant the
"Edit Service Providers" right to access the "Display Service Provider" page.
Planned/In Progress Bug
3
Ending Services with Expired Consent
Here’s a big pain point: when you have a client with expired consent, but
they’re in the middle of receiving services. Like, they’re booked into a
shelter, or they have an open case file. I get that with no consent, the
principle of you can’t modify the client’s information is good and valid, but
there’s a problem I think where HIFIS is conflating modifying information and
ending a service. So for example to close a case file, you need permission to
Edit the case file, and you have to click the Edit button, which also lets you,
say, change the caseworker or otherwise modify information. I think globally it
would be helpful to have a separate right and button to simply close services.
Like there’s a separate right and button to close bulletins. In Admissions,
Book-Out is already a separate right. But there should probably be a separate
right for CM and other modules like storage, subsidies, HPs, and any other
ongoing service. Not saying that you couldn’t close a case file by editing it
(in this proposed future), but to have a separate button that JUST closes it.
Like with bulletins. Obviously, since this describes lots of different modules
and cases, I’m putting it as a longer-term fix. Anyways, we need the ability to
close services for clients with expired consent. Right now people tell me they
are doing workarounds like: disabling Enforce Consent for an hour and then
turning it back on, or editing the Consent Expiry Date to tomorrow then changing
it back, just so they can close these services. - Option 1: grant the Admin a
permanent exemption to the Enforce Consent rule. The Admin can do whatever they
like to client files, regardless of whether the consent is valid or not.
Forever. - Option 2: create a Database Maintenance option that’s something like
“bulk expire all services for clients with expired consent” - Option 3: just add
these close buttons throughout the software - Option 4: create an automatic
process of when consent expires, also automatically close all services (this
could be problematic if, say, a client's consent expires for a few days before
getting reactivated, thought) - Option 5: have a button or something on a client
file, that says, bulk expire all services for *this* client. Maybe this can be
like the Client Service Delete option.
Considering Missing Functionality
3
Hidden (not just disabled) fields
Fields can be disabled but this just greys them out and doesn't hide them. It
would be great if we could hide fields we don't want shown, or ones we don't
want shown all the time. Then, it would be ideal for communities to be able to
customize which fields are hidden by default and which ones are not.
Theoretically, I would have 4 tiers: - Visible by default and mandatory -
Visible by default and optional - Hidden by default and optional (with an option
to show field) - Hidden and disabled (with no option to display, so like always
hidden, completely removed)
Feature Request
3
Stays always count as being Homeless
I have noticed that while the housing history determines a client's housing
status based on the housing type, there is no such determination made when the
client has a stay. In particular, some shelters might be transitional, which
should have the client's housing status be listed as transitional, not homeless.
When the client's most recent record is a stay, it should look up the service
provider type to determine what the housing status should be. Some of the
service provider types are things like "supportive housing" and so if they were
using the admissions module for their housing, for some reason, the client
should be listed as housed, not homeless or transitional.
Feature Request

log in
we run on Sleekplan


Sort by Trend Top Newest
Status All All (not closed) OpenConsideringPlanned/In ProgressComing
Soon!Completed? (Needs Verification)CompletedClosed
Tags - ConsentClientsDiversionConflictsReportsTurnawaysCoordinated AccessCustom
TablesGoods & ServicesCalls & Visits LogHousing SubsidiesLanguagesHousing
HistoryAudit LogEncampmentsService RestrictionsHousing Loss PreventionCase
ManagementStorageGroup ActivitiesUsersAdmissionsHousing
PlacementsSystemPrograms4.0.60ContactsVeteranService ProvidersWaiting ListFamily

All Categories

Feature Request

Bug

Missing Functionality

Faulty Behaviour

Display Issue

Performance Issue
ACRE Consulting Home • HIFIS Release Notes • HIFIS Download Links
Sleekplan Logo
we run on Sleekplan