A Turn-key FHIR Server for Healthcare Data - Kodjin FHIR Server

© 2021 EDENLAB. All Rights Reserved

www.kodjin.com

A Turn-key FHIR Serverfor Healthcare Data

built from scratch

designed for high-load projects

tested by 30 million users

low-code declarative approach


www.kodjin.com

1

About Edenlab

Edenlab is a custom software and product development company with a primary focus on healthcare data interoperability based on the HL7 FHIR standard.

Founded in 2014, our team now includes more than 100 seasoned professionals:

solution architects

FHIR and infrastructure architects

business and system analysts

software development engineers

DevOps engineers

What we do is help healthcare companies with interoperability, compliance, and moving to new standards. We have designed our own Kodjin FHIR server, which provides unique configurability opportunities, specifically for high-load systems.

What is the Kodjin FHIR Server?

What Makes Kodjin Stand Out from Other Solutions

The Kodjin FHIR server is low-code smart storage and a powerful tool for processing, validating, and storing all kinds of healthcare data, from appointments to diagnoses, accessible through an FHIR-compliant RESTful API.

The Kodjin FHIR server was entirely designed and developed by our team from scratch specifically for high-load systems.

Kodjin is not based on any existing solutions. Our team spent a great deal of time researching alternatives available on the market. Unfortunately, we had to admit that all current free FHIR-based solutions contain many shortcomings.


www.kodjin.com

2

Built from scratch

What isthe value?What isthe value?

We were implementing a national, centrally managed clinical data repository (one of the requirements was the ability to support 40 million users) to store data of a dualistic nature: it can be perceived as a set of fine-grained RESTful resources (or FHIR resources) and form documents when these fine-grained resources are combined.

While there are fine-grained resources, like Observation and Composition, with the need for different kinds of Conditions and Observations (and this means different FHIR profiles), we also needed to have profiles for documents, i.e., discharge summaries, PHC clinical notes, etc. All of these documents are Compositions in FHIR terms built from FHIR resources.

So, the problem could be solved through having a powerful profiling mechanism, which would allow us to configure profiles for atomic resources alongside complex documents, as well as terminologies used by both types. We needed to work with these complex two-layer profiles on the fly, with pure configuration, and since it is a national system, we needed a scalable high-load solution.

We explored the market and tested different solutions, but none could meet the high-load system needs.

So, we decided to create an FHIR server by ourselves.

Background: why an outsource company createdan FHIR server


www.kodjin.com

3

Modern, fast, flexible, and technically created for the future

compliant with FHIR R4 and previous versions

simultaneous support for all FHIR versions in one application

microservice architecture

100% open-source modern stack

built on Rust — high-performance language

Kodjin was created with a purpose

to provide unique configurability opportunities

to ensure easy customization for a specific business context and FHIR version without any additional coding

to solve real-world, national-level business cases

Kodjin Core FeaturesThe Kodjin FHIR server unlocks FHIR potential for healthcare players by delivering the opportunity not just to store and validate their data but also to save time, cut costs, and reduce future risks associated with changing standards and new market requirements.

© 2021 EDENLAB. All Rights Reserved© 2021 EDENLAB. All Rights Reserved

www.kodjin.com

4

Category Feature Providedby FHIR / Unique

Management of supported StructureDefinition profiles and Extensions through a REST API (aka dynamic profiling)

Setup and configuration

REST APIs Support for DSTU2, R3, R4, R5, and all future versions

Unique

FHIR Bulk API full implementation FHIR

Terminology

Declarative search framework and support for custom search parameters via configuration

Search Unique

Full terminology management through a REST API (including ICD-10, SNOMED, RxNorm, LOINC, etc.) for standard and custom terminologies

Unique

Full support for CodeSystem/ValueSet/ConceptMap with all respective operations

FHIR

FHIR subscriptions

Auto-generated capability statement

FHIR

Unique

Unique

Kodjin Core Features


www.kodjin.com

5

Category Feature Providedby FHIR / Unique

Search Support for all defined standard FHIR search parameters

FHIR

Support for custom search parameters

Other Smart-on-FHIR support FHIR

Audit Log module FHIR

Security& Access Control

Pluggable security module supporting OAuth 2.0, OpenID Connect

Unique

UniquePluggable user management and access control module

Infrastructure

CapabilityStatement https://test.fhir.edenlab.tech/fhir/metadata

Automated deployment to AWS, GCP, Azure, and on-premises

Unique

UniqueProduction-ready setup meeting Scalability, High Load, and High Availability requirements

UniqueAdvanced monitoring with Prometheus, Kibana, Grafana

Full support for FHIRPath in validations

Custom resources support

FHIR

Unique

Unique

https://test.fhir.edenlab.tech/fhir/metadata


www.kodjin.com

6

FHIR server validationswith dynamic profiles

Check that all the content in the resource follows the structure from the target profile and nothing extra is present.

Structure1 23 45

Check that the cardinality of all properties follows the profile (min. & max.).

Cardinality

Check that codes provided in the code/Coding/Codeable Concept types exist in the bound terminology.

Binding

Check that all FHIRPath constraints in the profile aren't restricted. The FHIRPath spec is extended with custom callbacks.

FHIRPath

Check that the restrictions on the list of elements follow the profile.

Slicing


www.kodjin.com

7

Kodjin Terminology Serviceallows you to manage all types of medical terminologies on the clients’ side without any additional custom development

Full FHIR standard implementation

Flexible management of any type of terminologies (custom, proprietary, etc.)

Fast code system processing thanks to the unique internal logic

Low-code declarative approach

If you feel the pain of matching different complicated terminologies, here is a painkiller

Even non-technical people can manage healthcare terminologies without time-consuming paid requests to outsource teams.

All updates can be done on the client's side, with no development involved and no vendor lock.

Quick terminologies updates

Our service can process any custom, large, proprietary, and other not-typical terminologiesin a standard way without the need to re-understand the structure and build custom solutions.You can easily manage your terminologies through the API endpoints.

Complex terminologies are supported by a wide number of internal connections and complicated internal logic.

Handle sophisticated terminologies

We offer noteworthy performance, scalability, and availability due to cutting-edge caching mechanisms. The Kodjin Terminology Service can handle extremely large code systems quicklyand accurately.

Our Terminology Service can support a large number of customers; you only need to set up our service once, and the system’s customers can easily use it as a dictionary, checking terminologies in real time — no local updates, no time loss.

Better Performance


www.kodjin.com

8

While most healthcare companies are forced to build a custom facade for each large custom terminology, our Terminology Service already contains terminologies added into the code system and valueset as standard FHIR objects, which gives users a qualitatively different way of handling terminology management. There’s no need to translate into FHIR or back. We provide full FHIR implementation.

USE CASES

Case study

The Kodjin Terminology Service could be used as part of the Kodjin FHIR Server or as a standalone terminology solution

One of our clients, the largest TPA in Hong Kong, has a variety of integrated health information systems (HIS). Our client faced the problem of terminology management: different HIS had to be transferred into the same type, and physicians worked with terminologies based on different healthcare standards.Our Terminology Service solves this pain by providing unification of all used terminologies. We developed a system where all terminologies are stored on a single cloud health information system (HIS) which is not common in the terminology solutions market. Physicians can easily find and validate any code by its description and do code mapping between different terminologies in real-time without any external support. The mapped codes can be used further in health data exchanges, no matter whether FHIR is used on the other connected systems or not.

We offer an out-of-the-box service, built on FHIR principles, that lets healthcare applications make use of codes without having to become experts in the fine details of the code system, the underlying code systems, or terminological principles.

Deal with extreme, custom, proprietary terminologies with complicated structure and logic

Integrate any type of terminology quickly without a new project launch, custom facade development, and extra effort

Process different code systems and have multitype integrations with other systems

Save time and money with a fast and flexible terminology management system

Avoid sharing proprietary terminologies with third-party vendors

The Kodjin Terminology Service works in a different way compared to the most widespread market solutions:

If you need to:

Based on FHIR principles


www.kodjin.com

9

Logical architecture


www.kodjin.com

10

Kodjin Use Cases

The Kodjin FHIR Server allowsfor saving money

The FHIR server provides an opportunity to easily connect different legacy systems, normalize data, reduce time to market and development costs, minimize manual work, cut time and costsfor integration with different EHRs, streamline workflows, extend EHR functionality, etc.

Different market players can focus on values related to their business goals, but one value will always be in the spotlight — reducing costs.

We are prepared to provide cases for various market players, such as

large or network clinical facilities

clinical trials and research companies

insurance companies and third-party administrators (TPA)

telehealth businesses

healthcare exchanges

personal health apps

remote patient monitoring companies

No need to use expensive additional services — 100% open-source modern stack;

No need to hire a lot of expensive specialists — the low-code platform can be supported with one system analyst;

Highly productive system — fewer resources are needed for trouble-free operation thanks to the Rust language;

No vendor lock-in — easy data migration from our server.


www.kodjin.com

11

FHIR Implementations

The eHealth system ensures the availability of high-quality and verified data about all key participants in the process of providing medical services and provides a REST API for working with processes around these entities. Data integrity and security are ensured by electronic digital signatures and blockchain-like algorithms. The system itself was created with an understanding of the criticality of the information that will operate, and therefore all possible mechanisms are applied to protect against data leaks. This is one of the world’s largest HL7 FHIR projects in production.

National eHealth system

ABOUT THE PROJECT

Final Goal: complete digitizationof the Ukrainian healthcare system

Task

CHALLENGES

outdated Soviet-model system (designed back in the 1960s)

outdated clinical registries

low level of computer literacy among GPs and poor ICT infrastructure

lack of national infrastructure, suchas a population registry

up to 7% of facilities with mostly private EHR solutions

ineffective financial model


www.kodjin.com

12

PROCESS DESCRIPTION

Key parameters

Interoperability

HL7 FHIR for data storage

ICPC-2 methodology for primary care settings

Blockchain solution for data storage

ML for data deduplication

Secure access to medical data

RESULTS

Registered users

30M+Pharmacies

2000+

Facilities

5000+Local EHRs integrated

25

RPS current system load

1000digital prescriptions issued

25M+

development of Central Component/Open API

connection of all Medical Information Systems (MIS)

support of the PHC (Primary Healthcare)

E-prescriptions program

step 1

secondary healthcare

support inpatient/tertiary healthcare

fully anonymous monitoring

medical insurance

step 2

Patient’s cabinet

Care plan

Sensitive patient’s data (AIDS, etc.)

step 3


www.kodjin.com

13

One of the largest TPAs in Hong Kong challenged the Edenlab team to switch to a modern FHIR architecture. The project was built on top of the Edenlab Kodjin FHIR server and terminology service.

Background: obstacles

Heals.Asia

Heals.Asia needed to decrease unproductive manual work in appointments and claims processing.

Goals

CHALLENGE

to provide a third-party mobile application with access to the provider’s directory FHIR API (search facilities, search practitioners by name or specialty) and appointments FHIR API (book an appointment, check in, etc.)

SOLUTION

automate the appointment process for doctors connected to the Heals.Asia platform

automate the processing of insurance claims

For the first set of functionalities, an FHIR facade was developed on the basis of the Edenlab Kodjin FHIR server to implement extract-transform-load from the client's proprietary data in real time. Our team created custom profiles corresponding to the proprietary data with all the relevant terminologies.

The appointments module was developed from scratch based on the FHIR-first approach with custom FHIR profiles and a custom business logic layer.

Step 1. Administrative data, appointments, and CD


www.kodjin.com

14

CHALLENGE

to collect clinical data from two separate EHR systems connected to the TPA in a centralized clinical data repository (CDA)

SOLUTION

Custom profiles were created, and a terminology service was configured based on custom terminologies. A pseudonymization technique was used to protect the patients’ clinical data.

CHALLENGE

to standardize a financial API employed by various providers connected to the TPA: all the main work processes from the FHIR financial module should be exposed as FHIR operations

to automate these work processes from the TPA side, i.e., to introduce an auto-adjudication engine capable of generating eligibility responses and predetermined claim responses based on the insurance plan data and claims history

SOLUTION

The solution was found in the form of a hybrid FHIR/non-FHIR application. While all the data intended for exchanging were stored in the FHIR server, a complex structure enabling the auto-adjudication logic was implemented for the insurance plan. The engine itself was designed as a framework, so new limits and constraints can be added in the future.

Step 2: Financial data and auto-adjudication engine


www.kodjin.com

15

SLA Requirements

Service Level Agreements

SLA Calculation Method

DescriptionMetric(x)

The percentage of time when the application is available for normal business operations

99.50% Total available hours/total hours in a measurement period (example: 24 hours x 21.16 days [average working days in a month] = "monthly available" to define if the service level is reached)

Application Availability

If downtime for scheduled maintenance is required, Edenlab will notify of it (including downtime to implement upgrades, patches, and/or fixes) "x" business days prior to the expected downtime.

30Notification for Planned Maintenance

< 2 hours 95% (or 1 miss per month if the volume is low)

The period between an initial request and the time when the service provider's representative becomes involved in the issue resolution

Incident Response time - Critical


www.kodjin.com

16

SLA Requirements




< 24 hours 95% (or 1 miss per monthif the volume is low)

The period between an initial request and the time when the service provider's representative becomes involved in the issue resolution

Incident Response time - Major

< 3 days 95% The period between an initial request and the time when the service provider's representative becomes involved in the issue resolution

Incident Response time - Minor


Incident resolving time -Critical


www.kodjin.com

17

SLA Requirements





Incident resolving time - Major

< 10 business days 95%Incident resolving time - Minor


www.kodjin.com

[email protected]

Let’s get in touch!

We would be glad to share more details about our enterprise-level solutions and other cases based on the FHIR standard.

www.kodjin.com

Our team of FHIR experts designed the Kodjin FHIR server specifically for high-load systems to provide unique configurability opportunities.

Medtech is our core domain, and our primary focus is medical data interoperability based on the HL7 FHIR standard. We developed one of the world’s biggest FHIR-based solutions with over 30 million accounts and personal records amounting to tens of millions.

A Turn-key FHIR Server for Healthcare Data - Kodjin FHIR Server

Documents

Transcript of A Turn-key FHIR Server for Healthcare Data - Kodjin FHIR Server