How open source HSLynk aligns with the San Diego Community Information Exchange's design principles

Since 2014, the HSLynk open source data sharing framework has independently been working on a very similar project to ConnectWell San Diego. Luckily, going through the principles and model overview listed for ConnectWell’s Information Sharing Model document, there is almost complete principle alignment, with a few minor differences.

In a scenario where data needs to be shared between communities using HSLynk and ConnectWell, it should be a relatively straightforward API implementation exercise.  Here is San Diego ConnectWell’s Information Sharing Model document for reference.

The following outlines HSLynk’s implementation of each of San Diego’s project design principles.

image1.png

Figure 1: HSLynk framework

1. Person-centric care

At the heart of HSLynk is the global client ID, generated by the Master Client Index (via embedded openempi.org), which is linked to all the places client data is stored in HSLynk.  Just as with ConnectWell’s functionality where

“A user of the composite view, be it a human or a system, will start with a search and lookup of this index, by entering some information about the client. MDM will then return a set of composite records…”, 

HSLynk Trusted Apps (third-party web apps, the proxy user interface of HSLynk) search for clients via web APIs.  The global search API: hslynk.com/search will perform exactly this functionality, returning a prioritized and list of global client matches, albeit without the match probability ranking.  When a global client record is then retrieved, linkages to all that client’s records within HSLynk are retrieved, including: surveys/assessments, HUD HMIS records, case notes, service transactions, referrals, random Linked Data (graph data), or households.  

We also have implemented a “registry style of MDM, not the hub style” in a construct called the “base schema”.  A registry style construct allows different, even inconsistent, identifiers to exist in funding source specific schema.  But, like in the ConnectWell model, these diverse identifiers are synthesized into a client’s Golden Record within the base schema.

2. Policy based authorization to information

For any Community Information Exchange, the authorization mechanism must hide the layered, underlying rules. From the Information Sharing Model document,

“A flexible access control model, that realizes the agency’s authorization policy, is a necessary enabler … the customer perceives the agency as a single entity, not a composition of departments.”

HSLynk addresses this principle using the industry standard OAuth2 Authorization Code and Client Credentials Grant open source API workflows.  Because each community (perhaps not beholden to US statutes) will need to implement different policies, sharing is configurable at a granular level.  HSLynk’s Attribute Based Access Control (ABAC) uses more generalized semantics: a community is implemented as a “project group”.  “Subgroups” of projects are definable, which could map to an organization, a sub-region, a department, or a multi-organizational initiative.  Subgroups may overlap one another and have roles and users assigned to them.  At the most atomic level is the “project”; the smallest unit to which a user and role may belong.   A project could be a men’s shelter wing, a behavioral healthcare crisis service, or a specific location of a transportation voucher program.

HSLynk Big Data Warehouse access (using any third-party analytics package) follows these same group/subgroup/project role-based access patterns.  Different communities may also share between specific subgroups and projects for simple, but powerful, interoperability.   Going further than the sharing policy, client consent requirements must also be also be satisfied, depending on how they are configured, and the period of consent granted.  HSLynk currently uses a “binary” consent model, since a continuum/scaled consent model has not been requested thus far by implementers.  But, it does seem like an interesting feature for HSLynk to explore.  Despite the layered, overlapping role-based access constraints in play, they are opaque to the user/customer who can either access the shared resources or not, fulfilling the monolithic, single entity appearance, though the reality may be a quite different and complicated scenario.

image2.png

Figure 2: HSLynk authorization components

3. Composite customer view as a foundation to better service

As with ConnectWell’s principle of a 360° client view, the “system of origin” is not queryable metadata as such (yet), in HSLynk.  Retrieving a global client record leads to source independent linkages to all that client’s records: surveys/assessments, HMIS records, case notes, service transactions, referrals, random Linked Data (graph data), or households.  Breaking down silos and system dependent barriers to information sharing is a key feature at the core of HSLynk’s architecture. 

What’s really interesting about the HSLynk development framework is that, as a “Platform As A Service”, HSLynk does not create the customer views; customers and trusted third party developers have the flexibility to create apps which consume the APIs. 

Likewise, the HSLynk framework does not pre-bundle analytics packages for the Big Data reporting access; it allows third parties (like The Community Technology Alliance) to offer analytics support and prebuilt dashboards, and we encourage Data Scientists/Analysts to bring their favorite tools to the table.  However, HSLynk does make precalculated Big Data views that can help remove expensive steps from the analytic process, such as for chronic homelessness determination (which relies on a confluence of factors found in existing data points), or for housing match eligibility active lists, etc..

And having both an operational data set serving APIs, synced to a Big Data Warehouse allows us to avoid this all-too-common quandary expressed in ConnectWell’s Information Sharing Model

“Many agencies establish data warehouses to bring together information from the various systems. While such warehouses provide important analytic insight at an aggregate level, they have limited relevance at the point of service for a specific customer.”

So, with HSLynk, there is no need to choose between the efficiency of Big Data warehousing for massive data sets, and the functional, real-time utility of client level APIs.

References

website: hslynk.com

wiki: github.com/servinglynk/hslynk-open-source-docs/wiki

code: github.com/servinglynk/hslynk-open-source

APIs: api.hslynk.com (select from the drop-down list)

API code site: github.com/hmis-api

app: Community Technology Alliances’ HOME App, implementing HSLynk APIs