If you’re storing FHIR data as JSON blobs in MongoDB, you’re missing the point. Aidbox lets you query it directly with SQL, and here’s why it matters.
Nikolai Ryzhikov, CTO of Health Samurai and passionate advocate for the modern, modular EHR, began his career in radiopharmacy. With a PhD from the Karolinska Institute, he worked at the Institute of Human Brain in St. Petersburg to develop Flumazenil, a novel radio tracer for epilepsy. Soon, he pivoted to programming, and an invitation from Pavel Smirnov to develop a cloud-native Electronic Health Record (EHR) led to the creation of Health Samurai.
This is the story of how that mission evolved, as told to Medblocks founder, Dr. Sidharth Ramesh in the latest episode of the Digital Health Hackers podcast. In this conversation they discuss Health Samurai’s work and Nikolai’s vision for the modular EHR systems of the future.
The Path to FHIR Adoption Involved Rewriting an EHR Three Times#
Nikolai and his small team began developing a cloud EHR using Ruby on Rails. “We were probably the first EHR who started hosting in AWS,” he says. This early platform laid the groundwork for the Aidbox FHIR server, Health Samurai’s flagship FHIR-first platform and server that drastically reduces the time and effort taken to develop interoperable health applications.
He describes his early work on the cloud-native EHR as being “quite successful, to be honest”. They were a team of 10 developers serving four hospitals in and around Los Angeles. “The physicians and nurses loved our product because we built it together,” he says, and the close collaboration meant that the interfaces and workflows they designed met real clinical needs.
Then the Office of the National Coordinator for Health Information Technology (ONC) came out with a certification that set technological capability, functionality, and security requirements for Health IT. This prompted Nikolai and his team to take a look at their internally developed data models from a new perspective only to discover inconsistencies in naming and structure. They looked for existing domain standards to learn from, starting with HL7 v3 and the Continuity of Care Document or CCD.
The experience of trying to implement CCD was discouraging. “It was really a nightmare”, is how Nikolai puts it. The standard was academically sound, but it took about half a year for them to understand it. From an engineering point of view it was extremely hard to implement. Next they explored openEHR, where the clinical model was much richer, and had strong modelling capabilities. But from Nikolai’s perspective, it specified too much and forced them to take technical design decisions that felt restrictive.
Then came FHIR, in the form of an early draft of Grahame Grieve’s FHIR specification. While it was still evolving, the simplicity and alignment in thought process was evident. Even more importantly, FHIR had an established community. “I was spoiled by the Ruby community,” Nikolai says, “so I know what the value of community is. It was early days, but it was a very passionate community. I didn’t get the same experience from openEHR at that moment.”
Nikolai and his team began using FHIR to inspire their internal EHR model, rewriting their EHR for the third and final time. Eventually, Health Samurai became a FHIR company, releasing the first commercial FHIR server with Aidbox. Aidbox was built through this journey, designed from the ground up to store, serve and query FHIR resources as a FHIR-native data layer.
A Bet on FHIR-Native Storage is a Bet on the Future#
Then the question emerged - Can FHIR serve as the backend of large scale healthcare data storage systems?
There are skeptics to this idea. Grahame Grieve expressed his reservations to Nikolai when they first discussed it. But Health Samurai have done it, and it has helped them scale. When most systems use FHIR to translate between external applications and Legacy EHRs serving as internal models, Aidbox uses FHIR as their internal model itself. This effectively simplifies the architecture removing the need to have translation or reconciliation layers.
What about building your own EHR Schema on modern NoSQL databases? It can be an empowering exercise, if you have the time and money to spend on it. The process can however mirror the experiences Health Samurai went through, “Rewriting is always painful,” says Nikolai, “when you build your first naive tables and then you’re trying to introduce more generality.” These rewrites break APIs, and in an environment where systems communicate with each other constantly and carry critical patient data, API breakage introduces serious risk and velocity loss.
This brings us to the first benefit of using FHIR - its robust domain information model has been discussed and designed over multiple iterations. And while FHIR can feel “too generic” when starting out, your system will grow into it as it scales. Reusing the wisdom of experts can save time and money.
“I’m not forcing you to use FHIR, I’m recommending people to at least be inspired by FHIR” is how Nikolai puts it, and we tend to agree. Nikolai’s work with Aidbox has proven for about a decade that you can build the whole system with FHIR - starting with FHIR gives you a database, APIs, samples and can save you years of development time. More importantly, it can scale with you as your system grows.
FHIR isn’t perfect - but the community makes it better#
Healthcare is a complex domain, and you’ll find that there’s often no ‘one right way’ to represent something. FHIR accounts for this by following the 80/20 rule - focus on 20% requirements that satisfy 80% interoperability needs. To this end, resources are designed to meet the most general or common data requirements of many use cases. Profiling and custom resources can help support more specialized use cases. Nikolai recommends using custom resources that behave like FHIR, but live inside your system and aren’t used for data exchange.
A FHIR profile is a StructureDefinition FHIR resource that is tailored to a specific use case. Profiles are an essential step in FHIR implementation, it defines rules, extensions and constraints for a resource. They are commonly used in implementation guides to create interoperable APIs within a defined context. E.g. US Core, IPS or Argonaut
A custom resource is defined by individual organizations or projects to meet specific needs that aren’t covered by the FHIR specification.
The flexibility in modelling is both a strength and a challenge, and the solution isn’t always obvious. That’s where the FHIR community plays an essential role. For Nikolai, participating in the broader FHIR ecosystem is just as important as using the standard. To anyone new to implementing FHIR, Nikolai’s first piece of advice is to look it up on Zulip chat, search for your question and have a discussion with other FHIR practitioners.
Beyond receiving guidance, there are also ways to shape the future of the standard. Joining FHIR working groups, especially in the case of young domains in FHIR that are still under development, such as oncology or genetics can be a great way to give back. Get involved with the group and the community, and influence resource creation decisions. In the end, the community is one of FHIR’s greatest strengths.
Unlocking healthcare analytics with SQL on FHIR#
While the ease and flexibility of modelling is appreciated in FHIR-native development, the real test for any healthcare platform is whether data can be queried, analyzed and visualized at scale. Aidbox supports SQL analytics with SQL on FHIR, making it a powerful tool for healthcare analytics.
The SQL on FHIR working group was set up about 5 years ago with involvement from Google, Cerner etc., intended to standardize how to work with FHIR on modern databases. The first version of SQL on FHIR was built based on Ryan Brush’s work on Spark SQL. After a few years they reconvened to discuss challenges, and a common issue was that the users wanted flat tables - most analytics tooling, and SQL, expected flat tables.
Then came the idea of View Definitions, a use case specific transformation of FHIR resources which was released as SQL on FHIR v2. This is now used in about 8 implementations to flatten FHIR resources and work with flat tables. Another type of implementation at Aidbox transpiles the view definition into SQL queries, giving it a lot of flexibility to use visualization tools like PowerBI, LLMs and so on.
A recording of the conference Analytics of FHIR is available on Youtube where you can find more information on SQL on FHIR and Aidbox’s approach to enabling analytics in healthcare.
Aidbox isn’t alone in this direction, Google Cloud Healthcare API uses BigQuery, and AWS HealthLake uses Athena to power flattened FHIR analytics. Aidbox’s advantage however, is in the tight integration between the core storage engine and SQL. Real-time SQL on top of live FHIR data? Aidbox makes it happen.
Are we ready for the EHR of the future?#
Monolithic EHR systems have dominated the healthcare IT landscape for decades. It often makes economic sense for hospitals to work with them - one vendor that can serve all needs is quite the dream - especially with the consolidation of hospitals. Nikolai calls them ‘dinosaurs’, they have stopped evolving and meeting actual hospital needs.
Nikolai’s vision of the real modular EHR#
“My dream is to build the real modular EHR on FHIR, [...] we’re proving that it’s possible with our customers,” said Nikolai. And it’s true, Health Samurai has built dozens of specialized EHRs, EMRs and health portals on FHIR, including
- FireNote: a hospice EHR designed for care coordination across different locations
- Metro Dermatology: a dermatology platform with custom billing, designed for high-volume, low-cost visits
- Patients Know Best: a patient portal that aggregate data from multiple sources and provide longitudinal views
- Prenosis: the first FDA certified sepsis prediction software as a device that aggregates data from different sources and provides data driven insights For more details check out the podcast, where Nikolai and Sidharth discuss Health Samurai’s success stories in detail.
The true modular EHR of the future would have FHIR in the background and multiple such applications on top of it, you could plug and play the scheduling or patient chart solution per your requirements, or even build your own. With more hospitals wanting to modernize their legacy systems and make it FHIR-compliant or even FHIR-native, the stage is being set for the future.
So what stands between us and the future? Building strong and consistent Implementation Guides would be necessary for such a modular future.
An Implementation Guide constrains FHIR to a particular use case, defining profiles, extensions, terminology bindings and workflows.
The challenge isn’t just to write more IGs, but also to harmonize them, ensure they don’t conflict and develop tooling that can apply and validate them across platforms.
When data moves, consent must move too#
Another challenge to consider with modular systems that share data is security and data privacy. Currently Health Samurai is exploring security label based access control, a strategy that decouples labelling and enforcement. Nikolai describes it as such, “We split the problem into two pieces, one is a labelling service - when a resource is created, it is labelled with specific sensitivity labels, and the other is a security layer which enforces and filters out information based on specific labels.”
Health Samurai now uses a custom access policy resource, which they plan to migrate to FHIR’s evolving Permission resource and Consent resource to be more FHIR-oriented. They’re also closely collaborating with the working group, and Nikolai encourages people to reach out and collaborate if it is of interest.
And what about terminology?#
Terminology is also an important aspect of semantic interoperability, but the challenges that exist here are beyond just FHIR. Licensing terminologies is a key challenge here, with SNOMED CT requiring a license except in member countries, CPT is commercially licensed by the American Medical Association, and while LOINC is free to use, it has certain guidelines for redistribution and integration.
The idea of terminology-as-a-service is another one of Nikolai’s projects, “the idea is that people should, for some reasonable amount of money [...] get all the up-to-date terminologies working.” He’s inspired by the OHDSI and OMOP implementations in building this project, and it’s planned to be shared with the community. They’re also considering update mechanisms with hybrid storage - some terminology managed locally and the rest externally. While it’s in an early draft stage at the moment, it is nevertheless an exciting prospect.
Future tooling with SDK generation and AI#
Another interesting project that Grahame and Health Samurai are working on is generators for SDKs to account for FHIR’s dynamic nature. This would be an essential step towards building a FHIR-integrated health IT ecosystem - making it easier and safer to develop applications against FHIR specifications.
With automated SDK generation, the goal is to generate SDKs directly from FHIR profiles and logical models instead of maintaining handwritten libraries for each language and resource type. This would enable a smoother developer experience with type safety for custom resources and profiles, direct integration into frontends, microservices and test suits, as well as autocomplete and validation in modern IDEs.
Another area to look out for is the integration of LLMs and analytical systems. Flattened and semantically labelled data can make it easier for AI tools to access them allowing for a wide variety of potential applications such as highly interactive clinical decision support tools and health data analytics tools.
Through these initiatives and more, Health Samurai and Nikolai continue to work towards building a future where health tech is modular, developer-friendly, community driven and interoperable.
Conclusion#
Nikolai’s journey with Health Samurai, from building a small cloud EHR to launching Aidbox is a story of passion, experimentation and community. By using FHIR as a foundation for data storage and modelling, they change the conventional health information paradigm, and end up with a generic and extensible data architecture.
The innovation in Nikolai’s vision extends beyond the novel FHIR-first data model and philosophy of Aidbox. SQL-on-FHIR capabilities make healthcare data truly accessible for real-time analytics tools. Extending into the future, this vision for innovation includes a modular and composable “Atomic EHR” with healthcare applications that support plug-and-play functionalities. This depends on developing robust Implementation Guides, scalable security models, and shared terminology services. Future tooling is also something to look towards, with automated SDK generation and AI friendly data transformation.
The role of the FHIR community in this journey is tangible, with Nikolai making multiple references during the conversation with Sidharth. We strongly believe in the power of community too, and encourage you to get involved where it interests you.