Skip to main content

The Medblocks Stack

Defining the standard vendor-neutral data models and APIs as well as building applications that work with a Digital Health Platform is not easy.

At Medblocks, we found the need to define and adopt vendor-neutral API standards for the platform as well as provide tools to make it easier to build and ship applications that work with these APIs. The unfortunate truth is that today, there is no "single standard" for healthcare data and APIs that can readily be used to build a Digital Health Platform. There are multiple standards that are being adopted by different organizations and vendors.

Medblocks, and others in the industry, however, have identified a few key APIs and data standards that are widely adopted by the industry and have the potential to be used as the foundational APIs for a Digital Health Platform. Medblocks is also spearheading the development and formalisation of a few new standards that is needed to bridge the gap between existing standards. Fundamentally, the Medblocks Stack is an implementation guide for a Digital Health Platform that works on the following publicly available API standards:

  1. FHIR REST API
  2. openEHR REST API
  3. SMART on FHIR + openEHR
  4. S3 Compatible Object Storage REST API

The rationale behind the decision to use these APIs and how they work together is explained below. The Medblocks Digital Health Platform is built to work with any vendor that provides these APIs. Medblocks also provides a few non-standard APIs that are built on top of the above mentioned APIs to make it easier to build applications that work with the platform.

FHIR REST API​

HL7 FHIR is data format and transport "framework" developed for modern healthcare by Health Level 7. The RESTful paradigm of FHIR provides an excellent foundation for the Digital Health Platform.

The international FHIR standard developed by HL7 is more of a "framework" than a "standard". It is being adopted by many countries as the standard for healthcare data exchange after profiling the resources and defining an Implementation Guide. Today there are already 100+ SMART on FHIR applications available on the market that can work with profiled FHIR data structures and APIs (most of them work on US Core). FHIR REST APIs are also being adopted by major vendors, including cloud providers like AWS, Google and Microsoft Azure as the primary API for healthcare data.

The Medblocks Digital Health Platform uses FHIR as the primary API for storing and querying administrative data such as Patient, Encounter, Practitioner, Location etc. Most of these administrative resources - like Patient, Encounter don't vary too much with the profiles of different countries, except for identification systems and a few other fields.

Clinical data in FHIR however vary a lot between countries and even between different institutions. HL7 does not define any clinical data models in the core FHIR specification. It is usually left up to the implementer to define the profiles and resources that are used to represent clinical data.

The Observation resource for example, is used by some institutions to represent a Lab Result, while other profiles use DiagnosticReport to represent the same information. There are also multiple profiles for the same resource. For example, the US Core profile, German profile and Indian profile all define a different set of resources and usage for the same data.

While there are some efforts to standardise clinical data models in FHIR, for example by Implementation Guides such as the International Patient Summary, most of these are still in draft and are not widely adopted. And many governments have already defined their own profiles for clinical data, and it's unlikely that they will adopt the international profiles immediately. Moreover, the number of clinical data models defined by the international profiles pale in comparison to a dedicated clinical data standard like openEHR.

This makes it hard to build applications that work with clinical data across different institutions while also trying to maintain interoperability with the government profiles.

Vendor support​

  • HAPI FHIR JPA Server (open-source)
  • Smile CDR FHIR API
  • Google Cloud Healthcare API
  • Microsoft Azure FHIR API
  • Amazon AWS Healthlake
  • Health Samurai Aidbox
  • Better CDR
  • Vitagroup HIP CDR

openEHR REST API​

openEHR is an open, vendor-neutral standard for healthcare data modelling, storage and querying. openEHR clearly separates the modelling artefacts from the API standard. The standard is more than 20 years old and has been adopted by many countries as the standard for healthcare data modelling and storage - including the UK, Sweden, Norway, Slovenia, Brazil, Russia, Spain, Germany and many more.

caution

openEHR should NOT be confused with a similarly named open-source PHP based mega-suite product called openEMR. openEHR is a standard for vendor-neutral health data platforms, not a product.

The number of maximal clinical domain models called "archetypes" defined by the openEHR community far surpases that by any other healthcare standard. Unlike with FHIR where there is no specific data model for clinical data, these archetypes serve as a foundation for interoperability and application vendors can "profile" these models by removing data points they don't use. This two levels of modelling - the standardised archetypes and the profiles defined by the application vendors allow for a lot of flexibility in the way clinical data is represented while still maintaining interoperability.

The openEHR REST API and the internal Reference Model are separate from the clinical data models. This results in the clinical artefacts like archetypes often being updated and released by the community in a much faster pace than the API standard. Application vendors can also define and publish their own archetypes and profiles without having to wait for the API standard to be updated. This results in an organic growth of the clinical models as practices in healthcare evolve.

The Medblocks Digital Health Platform uses openEHR as the primary API for modelling, storing and querying clinical data.

Why use openEHR instead of FHIR for clinical data?​

As stated above, FHIR for clinical data has the following drawbacks:

  • No standard clinical data models
  • Multiple profiles for the same data
  • No clear separation between the API standard and the clinical data models

For these reasons, we find it much more future-proof to use openEHR for clinical data, and build integrations to the FHIR data repository based on the specific profile that has to be used. For example, if the US Core profile has to be used, we can build or procure an integration to the FHIR REST API that maps the standard openEHR data to the US Core profile. If the German profile has to be used, we can build or procure an integration to the FHIR REST API that maps the standard openEHR data to the German profile.

We believe these integrations will be much easier to build and maintain than trying to build applications that works with multiple FHIR profile directly, or building integrations between multiple FHIR profiles (We get the same n*n problem mentioned above). In the future, these "integration" pieces for different profiles might be widely available as open-source or commercial apps.

Vendor support​

  • EHRbase (open-source)
  • EHR Server (open-source)
  • Vitagroup HIP CDR
  • Better CDR
  • Solit Cloud EHR.DB
  • Atomik

SMART on FHIR + openEHR​

Uniform Authentication by applications to the vendor-neutral APIs is a key requirement for the Digital Health Platform. Medblocks is spearheading this effort to define a standard for authentication of applications to vendor-neutral APIs.

While SMART on FHIR provides a starting point, we need a way to authenticate applications to the openEHR REST API, and other future APIs (like DICOMWeb) as well. The SMART on openEHR specification is a backward-compatible extension of the SMART on FHIR specification that allows applications to authenticate to the openEHR REST API, as well as any other APIs using the same OAuth2.0 mechanism.

The SMART mechanism also provides a definition for the "App Launcher" - a web application that allows users to launch applications in the context of a patient or encounter within an iFrame.

Vendor support (SMART on FHIR)​

  • HAPI FHIR JPA Server with SMART Dev Sandbox (open-source)
  • Smile CDR FHIR API
  • Microsoft Azure FHIR API
  • Health Samurai Aidbox
  • Medblocks Ignite

Vendor support (SMART on openEHR)​

  • Medblocks Ignite
note

Today, Medblocks is the only vendor that supports the SMART on openEHR specification. However, we are working with other vendors to adopt the specification. If you are a vendor and would like to adopt the specification, please reach out to us at [email protected].

S3 Compatible Object Storage API​

Storing large binary files like Images, Videos and PDFs, etc in the FHIR or openEHR repository is not a good idea. It is better to store these files in a distributed object storage system like Amazon S3, Google Cloud Storage, etc. The S3 API is a widely adopted standard for object storage and is supported by most cloud providers, with multiple open-source implementations as well.

Vendor support​

  • MinIO (open-source)
  • Amazon AWS S3
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • Digital Ocean Spaces
  • Wasabi
  • Backblaze B2
  • IBM Cloud Object Storage
  • Alibaba Cloud Object Storage

What the Medblocks Stack does not cover​

The core focus of the Medblocks Stack is on providing an organisation specific platform for storing, querying and analysing healthcare data, and obtaining a longitudinal view of the patient's health. While clinical workflows are an important part of the platform, the platform does not cover all use-cases of an organization. We believe that the core platform should be built to work with other applications and systems, not replace them.

Enterprise Resource Planning​

The Medblocks Stack does not and will not cover "Enterprise Resource Planning" (ERP) use-cases like:

  • Billing and Invoicing
  • Inventory Management
  • Human Resource Management
  • Expense Management

There are already many great solutions available for these. The Medblocks Stack is built to work with these solutions, not replace them. Some examples of open-source applications that cover these use-cases are: Odoo and ERPNext. There are also many commercial solutions like SAP, Salesforce, Zoho, etc that are available.

Cross Organization Use-cases​

The Medblocks Stack is build for a single organization. While this organization can have multiple locations, Medblocks does not provide solutions to share, integrate or query data across multiple organizations.

It does not cover cross-organisation use-cases like:

  • Aggregating data of a patient from other organizations using the Medblocks Stack or compatible APIs
  • Federated querying of data across multiple organizations using the Medblocks Stack or compatible APIs
  • Cross-enterprise Document Sharing (XDS)
  • Cross organization workflows like referrals, etc

There are protocols and applications that can be built on top of the Medblocks Stack to achieve these use-cases, but they are not part of the core platform. Some examples of these protocols are:

  • ABDM (for India) Link
  • nphies (for UAE) Link
  • Nuts (for the Netherlands) Link
  • Medicalchain (Blockchain based) Link

Terms and Definitions​

The table below provides a list of terms and their definitions that are used in the Medblocks documentation.

TermDefinition
FHIRFast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a standard describing data formats and an API for exchanging electronic health records (EHR). More information can be found on the FHIR website.
openEHRopenEHR (pronounced "open air") is an open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in electronic health records following a two-level modeling paradigm. More information can be found on the openEHR website.
PatientA person receiving medical care or treatment. This is usually equallent to the FHIR Patient resource.
PractitionerA person who is directly or indirectly involved in the provisioning of healthcare. This includes caregivers, nurses, pharmacists, and physicians. This is usually equallent to the FHIR Practitioner resource.
EncounterAn interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient. While the Encounter may result in hospitalization, the Encounter may occur outside of a hospital, e.g. in the patient's home, a mobile clinic, or a vehicle. This is usually equallent to the FHIR Encounter resource.
OrganizationA formally or informally recognized grouping of people or organizations formed for the purpose of achieving some form of collective action. Includes companies, institutions, corporations, etc. This is usually equallent to the FHIR Organization resource.
LocationThe Location resource describes a location (typically a building, ward, room, etc.) where healthcare is provided. Locations may be private, public, mobile or virtual spaces, or a combination of these. This is usually equallent to the FHIR Location resource.
EHRA representation of a patient's electronic health record. Refers to the EHR object according to the openEHR standard.
TemplateA structured data definition that is modelled using openEHR Archetypes. Refers to the Template and Archetypes as defined in the openEHR standard.
CompositionAn instance of structured clinical data under a specific EHR. Is always an instance of a Template. Refers to Composition according to the openEHR standard.
UserA real person who can login and use the Medblocks Stack. Can be administrators, practitioners or patients.
ClientAn application that can access the Medblocks Stack APIs. This can be a web application that requests a user to delegate access or a backend application that uses the APIs directly without delegation from a user.