Ona at FHIR DevDays 2022

Back in June, I was part of the Ona contingent attending the 2022 HL7 FHIR DevDays in Cleveland, Ohio. This was a once-in-a-lifetime opportunity for me to visit the U.S., learn more about FHIR, and hone my FHIR skills.

DevDays is the annual physical manifestation of the growing FHIR community. The hybrid and international 2022 convention gave us the chance to observe how the community was implementing the FHIR spec. We absorbed best practices to strengthen the functionality of Ona’s OpenSRP FHIR Core product offering, which encompasses various health verticals across the world. So what were my key takeaways from this expedition seeing what the rest of the world was up to? Let’s get into it.

We are not alone!

We met allies and collaborators, such as the Google Android FHIR SDK team and our technical partner Venture Dive, in person for the first time, and put actual human faces to the e-faces. Given that we operate in a tiny digital village yet are spread out in terms of timezone, culture, and location, we normally have to go out of our way to communicate our diverse experiences and cultures in online interactions.

In person, we were able to recognize, affirm, and blend our team goals, and to forge even closer links. Most importantly, we discussed how to get to the next frontier of great innovations in the digital health space by building tools that make a change in the livelihoods of millions of people.

SMART on FHIR has enormous potential

The SMART on FHIR specification is a well-liked option for giving health applications a unified approach to security and data requirements. A workflow for securely requesting access to data, receiving it, and using it is defined by SMART on FHIR. SMART on FHIR is essentially three items in one package: 1) Access to Data, 2) Identity and Access Management, and finally 2) Launch, i.e. in order to launch web-based applications with a set of context parameters supplied to the application, SMART specifies a uniform URL scheme for portals, EHRs, etc.

Despite operating in an environment that is primarily offline first, there is a huge opportunity to assist backend dashboards with lightweight apps that can boost efforts in monitoring and assessment or decision support. This means that we can take advantage of the capabilities that are already in place, spend a little time creating an adapter, and then plug them into other utilities that can be used with SMART on FHIR apps.

Imagine incorporating a CQL-based component that would alert you to new illness trends, escalating measles instances, or even misdiagnoses brought on by improper use of medical protocols. Such information would be provided depending on the patient’s time of symptomatic updates. This can save the patient time and money while also delivering the best interventions for high-quality, affordably priced healthcare. Is it the CQL I just mentioned? Next, let me explain.

Clinical Query Language unlocks Decision Support

Clinical Decision Support (CDS) and Clinical Quality Measurement (CQM) domains can both use the Clinical Quality Language (CQL), an HL7 specification for the communication of clinical knowledge. Do you recall the old jokes about doctors’ handwriting? In essence, that is the issue that CQL seeks to address. Clinical quality metrics are created by doctors and other medical professionals and are, in principle, shared with other medical professionals via electronic records. But in this instance, that isn’t necessarily the case. Such requirements will be simpler to produce and distribute thanks to the CQL language, and through this have the chance to improve patient outcomes. Additionally, it might reduce the amount of time doctors spend recording their work in electronic medical records. CQL permits the entry of data such that it can be read by whatever system is used to store data. 

Why does this matter? Clinical Health Workers may now effectively and securely rely on audited CQL expressions integrated into the Digital Health Clinical health workflow software to aid in better Diagnostic and Treatment decisions. Help them identify danger indicators, provide guidance on whether to refer patients to the next level of treatment, provide reports that are simpler to produce and read, and effectively narrate a story using the data they gather. The largest advantage is that patients can be assigned to suitable CarePlans that enable them to receive better healthcare in order to live happier and healthier lives.

SNOMED and LOINC means no more cleaning and translating strings

How can we codify various situations, standardize measurements, and preserve data, as well as better query clinical artifacts? What if I told you something like staphylococcaceae in contemporary systems can simply be referred to as 22754005? Thanks to SNOMED (Systematized Nomenclature of Medicine) and LOINC (Logical Observation Identifiers Names and Codes), we are able to standardize clinical measures and preserve clinical artifacts in a fashion that is easily transferable and interoperable between systems, and not constrained by either multilingual support or scientific nomenclature and jargon. Using these codes, such a system can query and map complex use cases in a matter of milliseconds, making health systems faster and less resource intensive.

FHIR will unlock artificial intelligence and machine learning

The industry is growing the applications and AI models that interface with their FHIR servers to give their business more value now that businesses are starting to use FHIR repositories as an operational store. This is a tremendous step forward, but because there aren’t any standards or best practices for metadata and analytics outputs on FHIR, implementations aren’t doing it uniformly.

Having stated that, data provided by models or by machines should be labeled explicitly as such to distinguish it from data produced by individuals. To ensure that explainable metadata can be recorded in FHIR and that our community can contribute to developing trust in this new wave of AI application, there is an increasing need to standardize analytics data on FHIR and to implement best practices for modeling transparent reporting. Additionally, we must assess risks associated with current machine learning implementations, short-term best practices, and a potential long-term solution for the community to consider.

Data readiness on the go

Finally, despite the fact that healthcare data is essential for high-quality, strategic planning to improve outcomes and lower costs, how can healthcare executives give the data at their disposal meaning and produce the desired outcomes in the current environment? Are we creating long-lasting answers to issues in delivering healthcare services, or are we simply shifting superficially without resolving the underlying problems in healthcare? We unpack that as we continue the next phase of FHIR Core Quest product in Introducing Quest: FHIR Native Case Management – Ona. Enjoy!