Preston Lee's Blog

Blog

  • Stakeout v4: Service Monitoring and Screenshot Service Now Open Source

    I’m pleased to announce the public release of Stakeout v4 as fully open source software under the Apache 2.0 license. Stakeout is a simple, self-hosted application for HTTP(S) availability monitoring and automatic web screenshots. If you’re looking for Nagios, use Nagios — Stakeout is deliberately minimal and answers “Is everything up!?” in a concise and visually useful layout.

    And you can even set up multiple dashboards with direct deep permalinks for users.

    Here are a few screenshots of an example deployment in browser dark mode. Color coded traffic signals are used when screenshots aren’t enabled for a service.

    And the WYSIWYG controls when in edit mode:

    What’s in Stakeout v4

    • Stakeout Server – Has had a substantial internal upgrade to Ruby 4, Rails 8, Postgres 18, and a move from Good Job to Solid Queue for background job processing. Screenshots are now handled directly by the Browserless Chrome image for reliable web page screenshot captures, and the stack is wired for production with a single `docker compose` file that brings up the UI, API server, worker, headless Chrome container, and PostgreSQL. GitHub Docker Hub
    • Stakeout UI – Now with system dark/light/automatic theme support, refresh enabled by default, and a simplified feature set. The frontend talks to the server API and provides the clean web dashboard. (Note: ICMP checks have been completely removed from Stakeout v4, and never really worked well in the first place when deployed via containers, a.k.a. the Right Way.) GitHub Docker Hub
    • Both projects are now also built and released for multiple CPU architectures (amd64 and arm64) and published to Docker Hub, also as free software under the Apache 2 license.

    What’s Happening Now, Not 6 Months Ago

    Stakeout does not track historical availability results, nor any form of rolling availability statistics. It’s not only out of scope, but architecturally not optimal for Stakeout’s goals.

    In fact, Stakeout doesn’t even check service statuses unless someone is actively observing a dashboard. If no one is visiting the dashboard — or, more accurately, polling the server API for the dashboard data — the server doesn’t waste the compute resources to schedule and run the checks. It would be a tree falling in the words with no one to hear it.

    This is especially important since the vast majority of Stakeout’s CPU load is consumed by the server-level opt-in screenshotting, which uses a headless instance Chrome. If you’re visiting an idle dashboard that hasn’t been updated in a while, there is a “Request Refresh” button that immediate enqueues a job to check if data needs to be updated.

    There’s also a “5 Second Refresh” option when the user enables Developer Mode, though I don’t recommend it for normal use since the constant screenshot downloads use 12x the bandwidth the 1-minute refreshes. Plus, services are never checked more frequently than 1 minute. So you can mash “Request Request” as much as you want, but them data will still take a minute even if the UI nags the server every 5 seconds.

    Deploy It

    A complete Docker Compose example is available for your customization at: https://github.com/preston/stakeout-server/blob/master/docker-compose.yml

    docker compose -f docker-compose.yml up --pull always --remove-orphans

    Stakeout is provided under the **Apache 2.0** license. Feedback, issues, and contributions are welcome on GitHub.

  • CQL Studio: Filling the Gap in CQL Development Tools

    CQL is becoming the standard language for expressing clinical logic across multiple healthcare domains:

    Despite CQL’s growing importance, developers have been forced to use basic text editors and command-line tools. My aim for CQL Studio is to become the de facto open source development suite for all CQL-based artifact development. 😃

    Vision for a Comprehensive Integrated Development Environment

    Directionally, CQL Studio will provide an IDE-like environment addressing this gap by providing:

    • Intelligent Code Editor: Syntax highlighting, autocomplete, formatting, and real-time validation for CQL development
    • AI-Powered Assistant: Context-aware help for writing and debugging CQL expressions
    • Integrated Testing: Built-in test execution and result visualization
    • FHIR Integration: Seamless connection to FHIR servers for data access
    • Terminology Awareness: This is architecturally complicated and I’m honestly still playing with ideas, but at the very least will include UI tools similar to CDS Connect Authoring Tool and integration with the CQL editors and execution engine.. somehow.

    Vision for the Future

    In terms of product market fit, CQL Studio is targetting a number of different stakeholder groups, such as:

    Quality Measurement Organizations

    • NCQA: Streamlined development of HEDIS measures transitioning to CQL and FHIR
    • DQIC: Enhanced quality measure authoring workflows for the Digital Quality Implementers Community
    • CMS: Simplified measure development and testing for federal quality programs
    • Federal Agencies: Common libraries of nationally-relevant concepts needing computable, shared, interoperable definitions.

    Clinical Decision Support

    Clinical Practice Guidelines

    • CPG on FHIR: Guideline implementation and testing
    • Evidence-Based Medicine: Structured clinical recommendations
    • Care Pathways: Standardized care protocols

    Reflecting on the rallying collaborator support and the meta-issue of how to communicate the impact and success of the suite itself, a few key metrics I have in mind are:

    • Lower Barriers to Entry: Accessible tools for new CQL developers
    • Reduced Development Time: Faster CQL library creation and testing
    • Improved Quality: Better validation and testing capabilities
    • Enhanced Collaboration: Shared development environments and workflows

    That seems directionally correct, at least. Much more to come!

  • CQL Tests UI Getting Live Test Execution

    Since announcing CQL Tests UI, the application has continued to receive enhancements that add the ability to execute new test runs yourself using the official CQFramework-family of CQL tests.

    What’s New: The Runner Integration

    The upcoming release introduces a complete CQL Test Runner integration that will allow users to execute CQL compliance tests directly from the web interface. No more switching between tools or managing configuration files manually.

    Key Features Added

    Live Test Execution: The new runner component will let you configure and execute the separately-running CQL test runner service against any CQL-capable FHIR server with a few clicks. Tests will run asynchronously in the background via the test runner, and results will be reported via the UI where they can be seamlessly loaded into the existing viewer.

    Flexible Configuration: The interface provides a user-friendly way to configure FHIR server endpoints, build settings, and test parameters. For power users, there will be a full JSON editor with syntax highlighting.

    Separate Deployment: The CQL Test Runner itself will operate as a separate service that needs to be deployed independently. It will be released as a Docker container.

    Results Integration: Once tests complete, you’ll be able to immediately view results in the existing results viewer or download them as JSON. The integration will be seamless – test results will flow directly into the visualization tools you’re already familiar with.

    Looking Forward

    As the project continues to evolve, I’d personally like to see CQL Tests UI grow into an even more full-featured CQL authoring environment. There is exciting potential to combine or align with efforts from the CDS Connect Authoring Tool Community Edition, bringing together the best of test execution and authoring capabilities in a single, user-friendly interface.

    Please share your thoughts with me via the GitHub repository, the FHIR Zulip community, or during the HL7 CQI and HL7 CDS working group calls.

  • Announcing CQL Tests UI: A Web Interface for Clinical Quality Language Engine Compliance Testing

    I’m pleased to announce the release of CQL Tests UI, a web application for viewing and analyzing Clinical Quality Language (CQL) engine test results generated by the CQL Tests Runner. I’ve contributed CQL Tests UI to the cqframework family of tools under the Apache 2.0 license following debut at the September, 2025 HL7 Connectathon.

    What is CQL Tests UI?

    CQL Tests UI is an intuitive web application that provides an interface for visualizing the results of CQL engine compliance tests. Whether you’re working on clinical decision support rules, quality measures, or other CQL-based artifacts, this tool helps you quickly identify engine issues and compare results across different CQL execution implementation environments.

    Key Features

    Cross-Engine Comparison Dashboard

    The dashboard provides a high-level dashboard summarizing test results across engines, allowing for broad-stroke summarization of correct CQL engine functionality across systems.

    CQL Tests UI Dashboard

    Detailed Result Viewer

    The results detail viewer zooms in on a specific test run. This feature allows you to examine expected and actual output of individual test cases and understand failures.

    CQL Tests UI Viewer

    Flexible Data Loading

    The application supports multiple ways to load your test data, making it easy to integrate into existing workflows.

    CQL Tests UI Loader

    Documentation and Deep-Linking

    Built-in documentation and deep-linking support make it easy to share specific test results and collaborate with team members.

    CQL Tests UI Documentation

    References

  • Substance Abuse Data Exchanges with FHIR: the ASU SHARES Program

    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 .

  • GovCIO Quotes

    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!

  • KNARTwork 2022 Rerelease

    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.

  • space_elevator ActionCable Client for Ruby

    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!

  • BitTorious Trials

    New in BitTorious v4!

    BitTorious v4 has been released, and has received a comprehensive internal upgrade to Rails 5 and PostgreSQL 9.5. Also, all official releases from v4 forward will be built as portable Docker containers and distributed via Docker Hub.

    Due to attempted abuses of the evaluation environment, we’ve unfortunately had to discontinue the publicly-accessible BitTorious trial portal, but would be happy to give you a live demo of the current system if you’ve read one of the papers and are interested in deployment. There are several private instances of the portal in active use, though for security reasons not publicly published.

    Get it yourself!

    Builds via Docker Hub

    GitHub Source Code, Screenshots and Setup Instructions

     

  • Ruby Supercomputing: Using The GPU For Massive Performance Speedup

    Confreaks just released a Ruby/JRuby GPU presentation of mine from Mountain West Ruby Conference 2011 in Salt Lake City, Utah. Slightly stale, but all still very relevant to HPC today!

    http://confreaks.tv/videos/mwrc2011-ruby-supercomputing-using-the-gpu-for-massive-performance-speedup