As part of my work at Arizona State University, I’ve been developing the technology stack for the Substance Use Health Records Sharing (SHARES) program. This initiative aims to transform how sensitive health data for substance use disorders (SUD) are managed and shared across healthcare systems. At a personal technical level, my goal is to provide a set of flexible developer libraries, pre-canned API services, and exemplar web UI applications for all U.S. entities to comply with 42 CFR part 2 using FHIR.

While management of patient consent directives has its own set of challenges, such as those being addressed by the FAST Consent Management Implementation Guide, I’m more interested in the runtime enforcement of patient data sharing elections between organizations. Consent enforcement is an incredibly challenging area of healthcare interoperability wrought with legal and clinicotechnical quandaries.

SHARES has been on a publishing spree, and I’m proud to.. share.. that FHIR Granular Sensitive Data Segmentation has been published in Applied Clinical Informatics (ACI). The referenced data labeling approach to information sensitivity classification is done in compliance with the FHIR DS4P implementation guide and heavily influenced by the ONC LEAP Computable Consent program. While we didn’t reuse LEAP’s Java and JavaScript code as we wanted SHARES to be entirely done in native TypeScript, we still retain some compatibility with LEAP’s CDS Hooks-based FHIR data labeling service using a modified version of their schema. SHARES has since moved on, however, to supporting numerous other means of integration for security label-based data segmentation.

Since this manuscript was drafted, we’ve been hard at working rearchitecting the technology platform for scale, plugability of classification engines, and integration methodology. We also recently released v1 of a visual Consent Simulator that will be a focal point of upcoming technical iterations.

I’m particularly excited for the next few technical phases that will use the new pluggable architecture to provide alternative means of data segmentation. More on that in future publications. 🙂

For more information on the SHARES program, visit https://www.asushares.com .

I was pleasantly surprised to hear that GovCIO quoted one of my recent presentations in a short article on H7 FHIR Foundry: https://govciomedia.com/hl7s-fhir-foundry-speeds-up-health-data-standards-adoption/

With the Centers for Medicare and Medicaid Services (CMS) pushing for the adoption of FHIR APIs to streamline healthcare data exchange and support value-based care, HL7 and the FHIR Foundry initiative are the best positioned vehicles for providing the tools, resources, and community support to simplify implementations in practice. I’m grateful to be able to contribute!

The HL7 Knowledge Artifact specification has been an experiment in portable clinical decision support (CDS). While unlikely to see production adoption due to equivalent concepts now in FHIR, it is nevertheless useful to see a standards-based representation of clinical knowledge in a working UI. I am updating the 2017 release of the KNARTwork Community Knowledge Artifact editor — part of the Clinical Quality Framework — to 2022 standards. The live copy is now available at:

https://knartwork.prestonlee.com

KNARTwork runs entirely in browser as a single-page app (SPA): there is no server side persistence. All XML document loading, manipulation, validation, and export is done entirely in browser. It implements Clinical Decision Support Knowledge Artifact Specification, Release 1.3, of which I was also heavily involved in. There are some remaining bugs due to being upgraded from Angular 5 to Angular 14. 🙂

KNARTwork’s code is open source and free to copy, remix, and reuse at the KNARTwork GitHub repository.

I have an interactive command-line daemon (in Ruby) that I needed to receive push events via WebSockets from an ActionCable-enabled Rails application. I eventually succeeded, but doing so required diving into the weeds of ActionCable’s wire protocol since I didn’t want to rewrite my application in JavaScript solely to leverage the official client code.

Because I’m such a nice guy, I’ve extracted the code and released an easy-to-use client as the space_elevator gem. When combined with gems like thor, it makes writing bi-directional command line API clients a breeze. You can publish/subscribe to multiple channels simultaneously, and all in an event-driven manner. Check out the channel-y goodness and don’t forget to file any issues!