Use Cases

[Eric Jahn]

I know that requesting use cases can be used as a way to stall progress on things, but I think we're at a point again where we need them to drive the discussion forward.

As Dan and I have discussed, the current hmis-api is really focused on exporting/moving data between systems: a big step forward from the slow start we've had in HMIS interop, but definitely not a resting point (okay, pun intended).  Many including myself feel that we need to make things easier for other apps to work with an HMIS warehouse, and that we need to facilitate common tasks, such as making client referrals, searching for organizations and services, working with client releases of information, manipulating bed/housing inventories and checking someone into a unit, managing users, getting reports, and controlling authorizations to resources.  

But, for each of these tasks (unlike the simple CRUD stuff we have), we should have a somewhat defined workflow in mind, to make sure we have all the pieces in place to perform a useful transaction.   I know we have many use cases worked up already, but I think we should consolidate them in the hmis-api wiki, or at least reference them from there if the references avoid proprietary or trademarked artifacts. 

I just started a page for this purpose, 

https://github.com/hmis-api/api/wiki/Use-Cases, and I'm hoping that we can have a detailed discussion of these use cases and even their API implementation in preparation for the October NHSDC API meetup.  That way, our time spent there can be more productive.  

What do you think?  I'm going to start adding some headers and flesh them out over the coming weeks.  

I realize we may not be able to reach general (definitely never absolute) consensus on many of these workflows or even methods.  In those situations, we are always all free to use our own approaches.  But, in the interest of better serving the homeless, I hope we can explore and approach the reasonable limits of collaboration. 

-Eric

[Matthew Simmonds]

Eric, I believe in the value of use cases as it helps ensure that whatever approach we come up with is not biased towards the practices used by a particular piece of software.  To that end, we wrote the "Technical Challenges to Overcome when Aligning with Opening Doors" paper which has use cases on pages 3 and 4 related to a referral API.  This is an overview document, and not intended to be overly technical, but should at least give us some food for thought.  

We didn't flush out the use cases for our other recommendations but we did hit on the need for pushing out information to the consumers and mechanisms to allow for calls to a 3rd party data warehouse that can handle the reporting tasks on behalf of a HMIS vendor.  This same work can be used for pushing reports (without identifiers of course) out to public facing sites and dashboards.  

Any thoughts and feedback are always welcome.  Hopefully I can swing the trip to Miami and we can talk things through in person. 

- Matt

Matthew D. Simmonds
President
Simtech Solutions, Inc



575 Washington Street
Canton, MA 02021
(617)395-6669 x21

Propelling Innovative Ideas and Technologies Forward to Create a Better Future for All

---

From: Eric Jahn [mailto:er...@alexandriaconsulting.com]
To: HMIS API [mailto:hmis...@googlegroups.com]
Sent: Sun, 16 Aug 2015 14:16:57 -0500
Subject: [hmis-api] Use Cases

--
You received this message because you are subscribed to the Google Groups "hmis-api" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hmis-api+u...@googlegroups.com.
To post to this group, send email to hmis...@googlegroups.com.
Visit this group at http://groups.google.com/group/hmis-api.
To view this discussion on the web visit https://groups.google.com/d/msgid/hmis-api/CANHzzoPjbedUpQKyhFKrXd2fB3-YbOfUL85zaMKbL5mYCEbWag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Conners]

Matt,

Thank you for sharing. This is very interesting work. Our struggle to-date has been on of coordinated intake and assessment, while the referral has waited. During intake and assessment, we see significant barrier resolving consent to facilitate deduplication (or more accurately, not duplicating to begin with) at entry. What are your thoughts on the importance of cross-system look-ups at entry-time?

I hope you'll be able to find your way to Miami for an in-person discussion.

Thanks!

Steve

Steve Conners - Director, Systems
Pathways Community Network Institute     "...with you every step"

PO Box 450147
Atlanta, GA 31145-0147
[Office] 404.639.9933 x321   [Toll Free] 866.818.1032 x321   [Cell] 678.718.7264

www.pcni.org

 

 

Steve Conners - Director, Systems
Pathways Community Network Institute     "...with you every step"

PO Box 450147
Atlanta, GA 31145-0147
[Office] 404.639.9933 x321   [Toll Free] 866.818.1032 x321   [Cell] 678.718.7264

www.pcni.org

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/hmis-api/20150817195027.ed593d4e%40mail.simtechsolutions.com.

[Eric Jahn]

Steve, by "cross-system lookup", do you mean across customer HMIS instances, including across vendors?  If so, why does this have to be done?  Isn't it acceptable for different systems to have different sets of IDs and duplicate clientele?  I could see this as a great workflow we could establish for future interoperability, but I'm unclear as to why it's a show stopper for you?  I think when we discuss any integration, the context requires client consent and appropriate interagency agreements. But discovery across systems is beyond what we're usually considering.  Now if you used a Master Patent Index to match ids, you could know if it's the same person across systems...

[Steve Conners]

Eric,

The usage we are looking at now is identifying that a client has already undergone intake elsewhere. This saves time at data entry and may save time resolving information that has already been verified. It reduces friction (time) for individuals seeking services. Finally, it reduces administrative burden downstream when there is a need to deduplicate and resolve data discrepancies.

I am less concerned with interacting with neighboring HMIS's (though this may be a valid usage) and more interested in making space for "connected apps". Tools that rely on the HMIS for core data and ultimately submit HUD required information for final reporting, but provide additional functionality require the ability to query the existing HMIS repository.

Steve

[Matthew Simmonds]

Well I believe this would go back to the original request for use cases.  There may be times perhaps that a workflow might require that a person remain distinct across systems but normally any false duplicates can be addressed when it comes time to report.  The issue with that is if there are data conflicts between systems but normally that would be reserved for the identifying info as each system normally is the "system of record" for anything else.   

Steve, what we would normally envision would be a system to system referral whereby the common identifying info (such as name, DOB, and gender) is passed from A to B.  System B would need a "referral inbox" whereby the referrals can be accepted or rejected.  If accepted then ideally there is a lookup done to ensure the client doesn't already exist in the target system.  If not, he or she gets added.**  If it does then there is a new enrollment using the ID that is already within the system.  Either way, a message is sent back to the sender notifying that them that the referral was successful.  If the client is rejected then a rejection reason code would be sent back to the sender.    

** If this was a mistake and the client already existed in the target system then that would be up to the target system and/or the regional data warehouse to address.  The master patient index concept could certainly apply for this as well.  Both systems would need to subscribe to it though and the MPI would be passed from A to B instead of, or perhaps along with, the client ID # used by the source system.  

Of course this is all moot without at least two systems willing to play ball.  Hopefully some will come around soon enough.

- Matt

Matthew D. Simmonds
President
Simtech Solutions, Inc



575 Washington Street
Canton, MA 02021
(617)395-6669 x21

Propelling Innovative Ideas and Technologies Forward to Create a Better Future for All

---

From: Eric Jahn [mailto:er...@alexandriaconsulting.com]

To: Steve Conners [mailto:steve....@pcni.org], ma...@simtechsolutions.com
Cc: HMIS API [mailto:hmis...@googlegroups.com]
Sent: Tue, 18 Aug 2015 21:56:40 -0500
Subject: Re: [hmis-api] Use Cases

[Matthew Simmonds]

It sounds like in this case you just need to work out the connection to whatever data source to see if they are willing to allow for connected apps to search their database for clients.  If you can't search then you are likely going to be reliant on creating a common key and hoping that what you submit (simply a post) will jive with what is already in the database.  Unfortunately, as you are probably already seeing, this hit or miss approach can cause duplicates if the information being posted doesn't match perfectly.  Wish there wasn't so much reluctance to use biometrics as that will get you the best hit rate with the least amount of admin burden and wouldn't require the other system to open itself up for get requests.   

Matthew D. Simmonds
President
Simtech Solutions, Inc



575 Washington Street
Canton, MA 02021
(617)395-6669 x21

Propelling Innovative Ideas and Technologies Forward to Create a Better Future for All

---

From: Steve Conners [mailto:steve....@pcni.org]
To: Eric Jahn [mailto:er...@alexandriaconsulting.com]
Cc: ma...@simtechsolutions.com, HMIS API [mailto:hmis...@googlegroups.com]
Sent: Tue, 18 Aug 2015 22:22:58 -0500

Subject: Re: [hmis-api] Use Cases

To view this discussion on the web visit https://groups.google.com/d/msgid/hmis-api/CAJaH7nWJEPB0U4YOZb4vsrFsv76XhwnxvdPPN-GY4hiPQBCjzQ%40mail.gmail.com.