Introduction

This article aims to explore how the FHIR-PEX system operates and was developed, leveraging the capabilities of InterSystems IRIS.

Streamlining the identification and processing of medical examinations in clinical diagnostic centers, our system aims to enhance the efficiency and accuracy of healthcare workflows. By integrating FHIR standards with InterSystems IRIS database Java-PEX, the system help healthcare professionals with validation and routing capabilities, ultimately contributing to improved decision-making and patient care.

We return with our example of using the FHIR Adapter, in this article we are going to review how we can configure it in our IRIS instances and what the result of the installation is.

The steps taken to configure the project are the same as indicated in the official documentation, you can review them directly here. Well, let's get to work!

Motivation

The motivation behind the InterLang project is rooted in the innovative integration of LangChain chatbot agents with the Fast Healthcare Interoperability Resources (FHIR) framework to revolutionize conversational social prescriptions in healthcare. This project aims to leverage the rich and standardized data available through FHIR, an emerging standard in healthcare data exchange, to inform and empower these advanced chatbot agents.

In this article, we'd like to describe Med.me's incubation experience and takeaways, the cross-organizational booking problem, and our approach to solving it.

This exciting story started during one of the regular medtech meetups, where I met @Evgeny Shvarov, senior InterSystems chief of the Developer Community. Following the good old startup rule “pitch wherever you can”, I briefly explained to Evgeny Med.me concept – EHR exchange and appointment scheduling platform to automate and simplify communication between clinics, pharma on one hand and insurance companies, doctors, and patients on the other.

Evgeny listened carefully and replied that InterSystems provides plenty of products to solve the interoperability problems amongst the vast variety of EMRs and kindly advised me to hurry up to apply to the FHIR incubator Caelestinus powered by InterSystems.

That led to a start of an amazing 9-months long road where we were able to ramp up our understanding of interoperability, participate at the InterSystems Global Summit, find new customers and partners, and where the new concept of Resource Availability Exchange was born.

According Wikipedia a mind map is a diagram used to visually organize information into a hierarchy, showing relationships among pieces of the whole. It is often created around a single concept, drawn as an image in the center of a blank page, to which associated representations of ideas such as images, words and parts of words are added. Major ideas are connected directly to the central concept, and other ideas branch out from those major ideas.

I participated in InterSystems Women’s Health FHIR contest, because I loved the challenge to learn a new-to-me technology. I wanted to develop an app that receives data from a mobile device like my Fitbit or a Smart Watch. I did not get access to such data except when I downloaded a spreadsheet (CSV file) showing my daily steps and sleep data. I saw in iris-fhir-template it imported some patient data to a FHIR server.

Background

In 2021, I participated as an InterSystems mentor in a hackathon, where a newcomer to FHIR asked me if there was a tool to transform generic JSON data containing basic patient information into FHIR format. I informed her that I didn't know anything like that, unfortunately.

But that idea stays in my mind...

Several months later, in 2022, I came up with an idea to experiment: to train a named entity recognition (NER) to identify FHIR elements into generic texts. The training involved synthetic FHIR data generated by Synthea and the spaCy Python library.

All FHIR resources have a Meta element containing metadata about the resource. Some attributes are updated by the server, others are populated by the app constructing the resource.

Google has one intersting tool named Data Studio. This tool allows creating some interactive dashboards, based on your data, available from the internet. It already offers hundreds of connectors to any sort of data developed by the community. As well as some amount of community developed visualizing. And most importantly, Google offers a way to develop your own connector to your data.

FHIRaaS provides a REST API, and it's available from the internet. So I've decided to try to create some basic report on data stored there. And in the end, I got this.

Overview

In our previous post, we discussed the motivation for developing a chatbot agent with access to FHIR resources. In this post, we will dive into the high-level design aspects of integrating a Streamlit-based chat interface with a Java SpringBoot backend, and enabling a LangChain agent with access to FHIR (Fast Healthcare Interoperability Resources) via APIs.

Wanted to have a FHIR Story in the back pocket to share with the participants on a dead simple series of calls against the FHIR Server for anybody in the mindset of emitting metrics from a device to FHIR.

Hello again everyone.

In our previous article we saw how to configure our EMPI to receive FHIR messages. To do this we installed the FHIR Adapter that InterSystems made available to us that configured a REST endpoint to which we could send our FHIR message. We would then get the message and transform it to a %String that we would send via TCP to the output of our EMPI configured in our HSPIDATA namespace.

Alright, it's time to see how we retrieve the message, transform it back to a %DynamicObject and parse it to the class used by the EMPI to store the information.

Based on a great sample and workshop built by @Luis Angel Pérez Ramos (see related articles and related Open Exchange app), which included a local InterSystems IRIS for Health container (and desired setup), this sample presented here, adapted the workshop for using the InterSystems Cloud FHIR Server, and it's related setup.

My main goal of this article was to prove the use of InterSystems IRIS for Health for REST FHIR interoperability between multiple applications. In this use case, some initiating application makes a REST call to IRIS for Health (which is merely a passthrough for REST calls) to retrieve FHIR data from an Oracle Health R4 FHIR repository. Ideally, it simplifies the syntax for calling the Oracle Health APIs.