Skip to main content

Medblocks Ignite

The landscape of what constitutes an "EHR" is changing. With the advent of the Digital Health Platform, the EHR is no longer a monolith. It is now a collection of services that can be composed together to form a complete solution.

This calls for a new way of thinking about "EHRs". Medblocks Ignite provides an answer to this by reimagining what it means to be an EHR.

What is Medblocks Ignite?

Medblocks Ignite is a web application that operates natively on Digital Health Platform APIs to enable excellent clinical workflows. It can be thought of as a "launcher" on top of the Digital Health Platform that interweaves different services and applications to provide the end user with a seamless unified experience to manage their patients and health data.

(Simple architecture diagram - Ignite on top of Digital Health Platform, with different services and applications and Users on top of Ignite)

Building Blocks of Ignite

Medblocks Ignite provides a set of primitives that can be used to configure even the most challenging clinical workflows. Almost all of Ignite's primitives can be configured per user. This allows for a high degree of customization and personalization.

The primitives that make up Ignite are:

  • Users: Users are the end users of Ignite. They can be configured to have different roles and permissions.
  • Clients: Clients are applications need to programmatically access Ignite and the Digital Health Platform APIs. They can be configured to have different scopes.
  • Workspaces: Workspaces provide the practitioner with their working list of patients. They can be configured to be filtered or sorted by different criteria.
  • Tags: Important information about a patient is extracted and displayed in the dashboard and banner using tags.
  • Forms: Forms are used to capture structured data. Forms can be configured to be show preexisting data or can be used to capture new data.
  • Widgets: Widgets are used to create a patient's clinical overview. Different kinds of widgets like tables, line charts, timelines etc. can be configured to compose a specific practitioner's dream "patient chart".
  • Applications: Applications are used to embed external applications using iFrames deeply into Ignite's workflows. These are usually applications using the SMART protocol.
  • Clinical Decision Support (CDS) Agents: Decision Support Agents are special kind clients that can listen to the current state of the clinical workflow and provide alerts, suggestions and auto-fill forms to enhance the clinical workflow at the point of care.

Setting up, customizing or building application on Ignite needs basic understanding of the underlying Digital Health Platform APIs. However, once the setup is done, the end user can use Ignite without any knowledge of the underlying APIs.

(Ignite dashboard view / video showing flow)

tip

We are always on the lookout for improvements, and new primitives to cover clinical workflow as optimally as possible. If you have any suggestions, please feel free to reach out to us at [email protected].

Getting Started

Medblocks Ignite will be setup in your base URL. For example, if you have a deployment at https://dev.medblocks.com, then Ignite will be available at that same URL. If you don't have a deployment, you can request for one by filling out this form.

Logging In

To log in, you will need to have a user account. If you don't have one, please reach out to your administrator to create an account for you. You can also request the administrator to enable Single Sign On using Google, Microsoft or other OAuth providers that are limited to your organization.

Once you have a user account, you can log in by clicking on the "Sign In" button (or "Sign in with Google" button if you have Google SSO enabled). Once you're logged in, you'll be taken to the Ignite Dashboard.

Scenarios

The following scenarios are a good way to get started with the Ignite Sandbox and understand how it works. Please confirm with the Medblocks team to ensure that your sandbox is configured to match these scenarios.

Scenario 1: A Practitioner

A practitioner is a user who is responsible for the care of a patient. They are usually a doctor, nurse or a paramedic. This scenarios goes through a basic workflows that a practitioner might encounter.

Start Practitioner's Guide

Scenario 2: A Patient

A patient is a user who is receiving care, or a family member of a patient. The patient or a guardian can be configured to have access to their own data, and can also access other applications that are configured for them. We will be continuing the Practitioner's Guide, but from the perspective of a patient after the practitioner has completed their part.

Start Patient's Guide

Scenario 3: An Administrator

An administrator is a user who is responsible for the configuration of Ignite. They can configure the different primitives of Ignite to suit the needs of the organization. This scenario can be used along with a practitioner or patient login to make Ignite work for your organization.

Start Administrator's Guide

Scenario 4: A Developer

A Developer is a user who is responsible for building applications on top of Ignite. They can use the different primitives of Ignite along with code to build a custom application that can work with Ignite.

Start Developer's Guide