Interstellar : The Gravity Project

In the movie Interstellar, the planet Earth is plagued by crop blight, and humans are doomed to perish unless they find another habitable planet. There are two plans laid out by NASA, Plan A, which was to figure out a way to help the people of Earth get to a new habitable planet, and Plan B, to abandon the humans of Earth and start a new human colony on the first suitable planet. Many may argue that Plan A would be very difficult, if not impossible, given the logistics of moving an entire planet of people. It would seem to suggest that Plan B, an abandonment of humanity would be the easier option.

Now, while I do realize this is a Science Fiction movie, albeit a very well-informed Science Fiction movie with physicist advisors, I can’t help but notice the similarities in how we think about social data standards, most notably The Gravity Project--an attempt to build top-down social data standards for social and clinical organizations to use.

But is this approach practical?

After all, if we accept that social determinants of health (SDOH) are 80% of the wellness of an individual and clinical is the other 20%--that could be a lot of codes. In fact, there are over 70,000 LOINC medical and laboratory codes, does this mean SDOH codes are destined for more than 200,000 codes? Social situations and other confounding factors can have more branching and components than a clinical diagnosis or lab result. Someone diagnosed with a disease may be unaware they have it, whereas, most are aware of the social factors affecting their lives. Coding these social conditions has become more of a pursuit of documentation akin to that of how EHRs capture clinical encounters.

But is the medicalization of social factors into codes a step in the right direction?

In many ways the project has chosen Plan B in Interstellar, abandoning the ongoing challenges and attempting to start over (See Figure 1). Additionally, when I look at the organizations that comprise the membership of Gravity Project, it tends to heavily skew towards medical insurance companies and for-profit companies. Now the point here is not to deter the involvement of such stakeholders, but to highlight a systemic problem in health technology adoption. If you do not heavily involve end users in the design of a product, you should not expect any significant level of adoption or even awareness.

Figure 1. Data Standards Joke

         So will the project work?

To me, in its current state, I believe its end state will remain illusory and unattainable, a bit of a social data standard mirage. It is hard for me to imagine a scenario where every community organization codes their social data uniformly and uses the same assessments, in many ways just as fanciful of a pursuit as the longitudinal healthcare record that has every event from birth to death.

Some reasons I believe this:

• The utility of SDOH codes is unclear/unknown to many community organizations and staff, so the incentive to adopt such standards is nonexistent.
• Generally, most of the data captured in these social data standards will need to come from community organizations, so even if adopted by major health networks, these data elements will likely remain empty without their involvement.

• Many community organizations can have braided funding models that require specific types of data collection for funder reimbursement, so a standardized assessment/form is not practical.

• Many non-medical care coordination systems lack the ability to bind service documentation data elements to system code values with corresponding modifiers.

• In California, early efforts for CalAIM have resulted in a patchwork of connected systems from documentation to service coding to claims submissions, resulting in different organizations fulfilling these functions.

• Many organizations lack the requisite staff that can properly architect such solutions that require defining and implementing data models, terminology, and technical frameworks. Realistically, most organizations outside of technology firms would not necessarily have fully staffed software product teams to support this either.

• Version control of codes has to be maintained by connecting directly to terminology servers like NLM (Nation Library of Medicine) UMLS (Unified Medical Language System).

But while I remain fervently critical of high-level collaboratives and strategic think tanks, I will always attempt to add recommendations for improvement.

 

 Recommendations:

• Social codes should first and foremost directly help end users that are conducting the data entry, without this utility, organic adoption will never happen without policy intervention. In the current model, it is unclear how codes can directly help an organization's staff, but more so assumed it is for billing purposes or to stratify clients into different risk groups. While standardized billing does help make organizations more efficient, it doesn’t help staff with service coordination or eligibility.
• A Social “Domain Name Server” should be operationalized at a county or regional level, generally corresponding geographically to how social services are allocated. Nerd Alert: A Domain Name Server (DNS) translates names into internet protocol (IP) addresses, so you don’t have to remember a bunch of complex numbers...sound familiar? For example, www.google.com is really 142.250.72.68 . (Go ahead and type just the numbers in your browser bar) .
• System Code sets (LOINC/SNOMED..etc) should be binded to local resources when available.

Example: Rescue Mission 123 Main St, Santa Cruz, CA | SNOMED | Referral to emergency housing fund program | 2.16.840.1.113883.6.96

• Data queries are masked from organization attribution with proxy requests, mitigating concerns of sensitive category searches (reproductive health, immigration...etc)
• Social DNS servers can serve as caches for common queries and communicate with other Social DNS servers to build more comprehensive and consistent hash key tables. (Similar to routing tables sharing for network discovery)

• HDUs (Health Data Ultilies) can provide the service that bridges resource directories with terminology service requests in order to provide the CBO with the most current code sets and available resources.

Figure 2. Distributed System Social Terminology Model

Workflow

1. CBO completes an assessment or goal which is then parsed for social data classes.

2. Either a CBO vendor or HDU calls the Social DNS with a packaged set of social data elements that need to be matched to code values.

3. The Social DNS checks the cache for any codes that conform to the request and are still fresh, if this condition is met, a set of codes is returned to the HDU or vendor.

4. If the data is stale or not found, the Social DNS repackages the query to a subset of possible system code values, and either sends it as a batch or transaction to the NLM UMLS server.

Optional: If using a national network, the Social DNS could check other servers if the route time is quicker.

5. The NLM UMLS returns the matching values along with any new versions.

Optional: The values could be pushed to other Social DNS servers to help optimize and standardize queries.

6. The code values are routed from the Social DNS server to be cached and then sent to the HDU.

7. The HDU queries the codes against the local resource directory.

8. The resource directory returns matching organizations to the HDU.

9. The HDU sends the CBO all available resources based on the assessment or goal in a pre-established format.

Optional: Webhook for a referral workflow.

With a model that pushes information to the end user, adoption of the terminology and standards would increase, along with community care coordination, and geographical identification of broad social issues (food insecurity, homelessness, digital literacy...etc). However, I doubt one LinkedIn article will move the needle, despite how loquacious I may be on the subject. But, portions of this model, should be considered by HDUs and CIEs as a potential service they could offer CBOs rather than just ADTs or a web-based viewer. We shouldn't abandon bespoke collection methods done throughout communities, Plan A can still work. In fact, this could be the thread that weaves together all levels of organizations: CBOs, clinics, social referral vendors, HDUs, and QHINs--the singularity we couldn't see right beyond the event horizon is now possible.

Technical Note: The secret sauce algorithm 🤌 in the Social DNS to fetch a subset of codes from UMLS based on a JSON payload from the HDU/vendor will be explained at a later date. If you are familiar with binary tree searches and multilinear relationships between tokens it will be a fun read.