Chronic Disease Management Application

Sector: Health tech, digital therapeutics

The scenario

Imagine you are building an app for patients with type 2 diabetes and hypertension. Patients report diet, activity, glucose and blood pressure, and care coordinators follow their progress on a dashboard between clinic visits. You want to sell it to several clinic networks.

Each network wants something a little different: another blood pressure protocol, other glycemic targets, other fields for their coordinators. And some will ask for the data in the format their own system speaks: an HL7 v2 feed, openEHR, or FHIR.

What goes wrong without the right tool

  • The database schema is modified for each new client, and the code drifts into a maintenance problem of client-specific branches.
  • Adding a field for one client risks breaking another.
  • "Can we get our data out?" becomes a custom project for every customer, because the data model is private to your product.

How Atomik can be used

  1. Model a shared clinical core. Define openEHR templates for the domains all clients share (blood pressure, glucose, medication, self-reported symptoms).
  2. Extend per client. Client-specific needs become new template versions or additional templates. No schema migration and no application code change for the data layer.
  3. Keep clients apart. Atomik is single-tenant, so a typical approach is one Atomik instance per client, which also helps with data-governance requirements.
  4. Build the dashboard as a thin client. Patient lists, trends and alert flags come from stored queries called through the REST API. Scoping a query to one clinic's patients is a matter of the instance and the query criteria, not a separate code branch.
  5. Deliver data in the client's format. Data committed to Atomik is already openEHR, so openEHR-native clients need no conversion. For FHIR and HL7 v2, CaboLabs can provide the integration layer (a FHIR facade adapted to each customer's profiles, and HL7 v2 integration). This is integration work, not something you switch on.

How CaboLabs can help

Atomik was built by CaboLabs, a company specialized in healthcare systems integration, data migration and consolidation, and clinical data management and audit. Besides the software, CaboLabs offers services that fit this scenario:

  • Standards and clinical data architecture for startups. Reviewing or designing the data model so it supports openEHR, FHIR or whatever your target market requires. See Services for health tech startups.
  • API and integration design. Designing the API contract and the integrations with each client's system. See API Design.
  • FHIR and HL7 v2 integration. The FHIR facade and the HL7 v2 layer mentioned above are integration work that CaboLabs can provide. See HIS Integration.
  • openEHR modeling. Designing the shared core templates and the per-client extensions. See openEHR Implementation.

None of this is required to use Atomik; you can do it with your own team or another provider. If you'd like to talk about your case, get in touch with CaboLabs.

What this gives you

Client-specific data needs handled as templates instead of schema changes, and a data store that can hand its content to other systems in a standard format.

Why Atomik fits

A product that serves many clinics needs data that bends to each one without rewriting the app, and that can leave the building in whatever format the customer's system speaks.

← All use cases