We all know that better information – shared among the multiple sectors that possess it – leads to improved patient-centered care. The tough part, of course, is pulling all the necessary data together in ways that are secure and respect the privacy/confidentiality of those involved. A new paper, published at this week’s national Community Information Exchange summit in San Diego, proposes a model for achieving those challenging objectives. The model or variants of it already have been implemented in San Diego, Los Angeles and Sonoma counties in California, and by the Ministry of Social Development in New Zealand. A workshop at the CIE summit tomorrow will focus on the technical aspects of implementing this model, as well as other designed to achieve the same purpose. The paper was written by Carrie Hoff, Deputy Director of San Diego County’s Health and Human Services Agency, and Subhankar Sarkar, an IBM Associate Partner and Chief Architect of ConnectWellSanDiego. We look forward to discussing the approach and outcomes of the paper with the broader NIC community.
Full paper: ConnectWell San Diego Data Sharing and Access Control Model.pdf
Replies
Dan, thank you for sharing this! Carrie and Subhankar, congratulations on implementing ConnectWell in your community!
Documentation on ConnectWell’s Information Sharing Model is a breath of fresh air in the traditionally proprietary and often technically opaque field of human services data interoperability.
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.
The following discussion outlines HSLynk’s implementation of each of San Diego’s project principles.
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
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,
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.
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:
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