Skip to content
CareSewa
What’s new

Everything we have actually shipped. And nothing we have not.

Most product pages describe a finished thing. This one shows the work: every change to the engine, the ten ERPs, CareSewa One and the API, in the order it happened. The roadmap is on this page too — further down, kept firmly apart, and labelled as a roadmap.

Latest release

2026.07

calendar-versioned

Shipped to date

14

every one of them real

Last updated

11 Jul 2026

across 9 months

Milestones

2

the ones that changed shape

Latest milestone

The most recent thing that changed the shape of the platform

Most entries in the feed below are a field, a fix, a rule made stricter. A handful moved the platform somewhere it had not been. This is the newest of those.

MilestoneNewHealth accounts

Your health account belongs to you, not to a clinic

Health accounts are platform-level, not owned by any provider. Each gets a Health ID in the form CS-XXXXXXXX, and the profile travels with the person.

This is the central design decision of CareSewa One. A provider has no access to an account until the person chooses to connect and share — the relationship starts from the individual, not from the institution.

What it means

  • A Health ID in the form CS-XXXXXXXX, unique across the platform
  • The health profile is owned and edited by the person it describes
  • No provider sees anything until they are let in
2026.03
The shape of the work

Where the effort actually went

Counted from the entries below rather than asserted — so this section cannot flatter us without the timeline backing it up.

By type

New6
Improved7
Security1

Fixes are in here alongside the features, at their real proportion. A changelog with no fixes in it is not a well-built product — it is an edited one.

By area

Platform3The engine2Studio1Health accounts1CareSewa One4API1Mobile app1Security1

Not every area has an entry yet, and the ones that do are not evenly weighted. That is what building an engine first looks like: the engine, Studio and the account model had to be right before the ERPs on top of them could be interesting. How the engine works.

The changelog

Every change, in the order it happened

Filter by type or by area, or search it. Grouped by month, newest first.

Type
Area

Showing 14 of 14 updates

July 2026

ImprovedPlatform2026.07

The whole platform is verified end to end on every change

One suite boots the API against an in-memory database and exercises the real flows: register, build a model, CRUD it, gate it, connect, share, revoke, book, ask, answer.

It has grown with the platform and has repeatedly caught real bugs before they shipped — including profile fields silently reading as undefined. It needs no database to run.

  • Runs against an in-memory database — no setup
  • Covers the engine, entitlements, staff grants, the global account domain and CareSewa One

June 2026

ImprovedMobile app2026.06

The Care Node identity, and a proper first run

The app now wears the real CareSewa identity — the Care Node mark and the jade, ink, coral and saffron palette — and opens with a five-slide introduction on first install.

The mark is a broken ring for the platform, three nodes for facilities, practitioners and people, and a cross at the centre for care. The onboarding art is vector, built from that same geometry, so it costs almost nothing and stays crisp at any density.

  • Brand pulled from the website rather than invented
  • Onboarding shown once per install
NewCareSewa One2026.06

Sign in with your phone number

Your phone number is now a login identity alongside your email, matched regardless of spaces or dashes, and unique across the platform.

The phone moved off the profile sub-document, which had no uniqueness — two accounts could have claimed the same number. It now has a digits-only key with a unique index. There are no country-code heuristics, because the platform is not single-country.

  • Phone or email, whichever you remember
  • Formatting is ignored when matching
  • A duplicate number is refused even if typed differently

May 2026

ImprovedCareSewa One2026.05

Sign-up captures the whole picture

Registration now takes name, phone, email, address, blood group, gender and date of birth. Only name, email and password are required; the rest can wait.

Profile edits are validated by exactly the same rules as sign-up, so a value that would be rejected at registration cannot be slipped in through a later edit.

  • Blood group is a validated set, not free text
  • A five-step wizard, with the health and address steps skippable
  • Profile edits are validated identically to sign-up
ImprovedAPI2026.05

You are a user, not a patient

A CareSewa One account is for anyone staying on top of their health. You become a patient only in relation to a provider — connecting to a clinic is what creates that.

The distinction is now encoded rather than flattened. The global account is a UserAccount under /user/*; the provider relationship is a PatientConnection; and provider-facing responses still say "patient", because to a clinic, that is who you are. The ERP's own patient model is a different concept entirely and was never renamed.

  • The app account API moved from /patient/* to /user/*
  • Provider-facing responses keep patient naming, on purpose
  • The clinic's own patient model is untouched
NewCareSewa One2026.05

Community: ask a question, get a clinician's answer

People ask health questions; peers and clinicians answer. A clinician's answer is marked as a verified professional one, sorts to the top and marks the thread answered.

Questions can be asked anonymously, and an anonymous post never exposes its author — the display name is literally "Anonymous", and the author id is kept only so you can manage your own post. Clinicians answer but cannot ask: the two sides of the exchange stay distinct.

  • Professional answers are labelled with the clinician's organisation and sort first
  • Anonymous by default; the author is never revealed
  • Upvote questions and answers; you may delete only your own question

April 2026

ImprovedCareSewa One2026.04

Booking rules, enforced on the server

You can only book a provider you are actively connected to, only a service they actually offer, only in a mode it supports, and never in the past.

Each of these is refused by the API itself, not merely hidden in the UI — a client cannot talk its way around them. The connection requirement is the important one: it is the same ownership rule as records, applied to booking.

  • No active connection to that provider: 403
  • Service not offered, wrong mode, or a date in the past: 400
  • Another provider cannot see or change your booking

March 2026

SecuritySecurity2026.03

Provider tokens and personal tokens can never be confused

A CareSewa One account token and a provider staff token are different kinds of credential. The tenant verifier rejects any token that carries a type, so one can never be used as the other.

The two identities are kept apart at the type level as well: an app account arrives as req.appUser, a provider user as req.user. Conflating them would let a personal account be mistaken for clinic staff, so they are deliberately never the same field.

  • A personal token on a provider route is refused with a 401
  • The verifier rejects typed tokens outright, so a new token kind cannot slip through
NewHealth accountsMilestone2026.03

Your health account belongs to you, not to a clinic

Health accounts are platform-level, not owned by any provider. Each gets a Health ID in the form CS-XXXXXXXX, and the profile travels with the person.

This is the central design decision of CareSewa One. A provider has no access to an account until the person chooses to connect and share — the relationship starts from the individual, not from the institution.

  • A Health ID in the form CS-XXXXXXXX, unique across the platform
  • The health profile is owned and edited by the person it describes
  • No provider sees anything until they are let in

February 2026

NewPlatform2026.02

An append-only activity log

Every create, update and delete is recorded after it succeeds, with who did it, whether they were an owner or staff, and a plain-English summary of what happened.

The log is written fire-and-forget: it records what happened, and it can never fail or slow down the action it is describing. Entries are appended, never edited.

  • Actor, action, resource, method, path and status on every entry
  • Full provider feed for admins; own feed for every user
  • Filterable by user, action and resource, and paginated

January 2026

NewPlatform2026.01

Every provider gets a short public code

Alongside its internal id, each provider now has an 8-character public code. It is the only identifier used for public lookup — the internal id never leaves the system.

The two identifiers do different jobs and are deliberately not the same value: the Mongo _id scopes data internally, while the public code is a searchable, shareable handle. GET /public/tenants/:code returns a limited public profile with no authentication.

  • Uppercase letters and digits, unique per provider
  • Public lookup returns name, type and connected ERPs — nothing more
  • Also disambiguates sign-in when one email exists under several providers

December 2025

ImprovedStudio2025.12

Default models are suggestions — delete them, or bring them back

Any model can be deleted, including the ones an ERP ships with. "Restore defaults" re-seeds a portal's default models and pages whenever you want them back.

The defaults exist to give a new ERP a running start, not to constrain it. Deleting a default model used to be blocked; it no longer is, because the tenant owns their data structures. Restore is idempotent — running it twice changes nothing.

  • Delete any model, default or not, optionally with its records
  • Restore defaults per portal, idempotently
  • Structure is the tenant's to shape

October 2025

ImprovedThe engine2025.10

Deterministic validation and type coercion

Required, select options and numeric ranges are enforced on write, and values are coerced to their declared type — "34" becomes 34, "true" becomes true.

Coercion is deliberately strict: an ambiguous value is rejected rather than guessed at, and record data is never silently dropped. This is medical data — a quiet failure is worse than a loud one.

  • Field-level errors returned with a 422
  • Ambiguous values are rejected, never guessed
  • Uniqueness enforced per model
NewThe engineMilestone2025.10

CareSewa now runs on a metadata-driven engine

Models are data, not code. A model definition describes its fields; records are stored as documents and validated against that definition at write time.

The platform moved to MongoDB and a two-collection core: ModelDefinition describes a model and its fields, and DynamicRecord holds the rows, keyed by tenant and model. Because the schema is data, a model can change at runtime without a migration and without a deploy.

  • ModelDefinition + DynamicRecord replace hand-written collections
  • Schema changes need no migration and no deploy
  • Records are validated against their definition on every write

Read from the platform API and refreshed hourly, so this page cannot drift from the product.

How we ship

Why most of this reached you without you doing anything

A changelog is only interesting if the changes actually arrive. Three paths, and they are genuinely different in cost — so we are specific about which is which rather than calling all of it “seamless”.

Schema changes are instant

Models, fields, pages, column order

A model is a database record, not code. Change it in Studio and the very next request renders the new shape — for every user, on every device, at once. There is no build, no migration, no release window and no version for anyone to be behind.

Nothing to install. Nothing to wait for.

App changes ship over the air

Renderer changes, logic, copy, fixes

The mobile app updates through EAS Update rather than an app-store queue. The app checks for a newer bundle on launch, downloads it and reloads. A fix reaches people the day it is written instead of the week it is approved.

The app updates itself on next launch.

Only native changes need a store build

New native modules, permissions, SDK bumps

This is the one case that goes through review, because the binary itself has to change — a new native module or an SDK bump cannot arrive as a JavaScript bundle. It is the exception, and we say so rather than implying everything is instant.

A store update, the ordinary way.

The gap between “we should change that” and “it is changed” collapses from a quarter to an afternoon. That is not a performance optimisation — it is the difference between software that shapes your practice and software your practice shapes. See Studio.

What counts

The rules this changelog is held to

A changelog is the easiest page on a website to quietly corrupt. Nobody audits it. Padding it with reworded trivia costs nothing and makes a quiet quarter look busy, and by the time anyone notices, the page has become a press release with dates on it.

So it is held to the same rule as the rest of this site: an entry describes something that is built, merged and running. Not something demoed, not something nearly done, not something on a branch. If we cannot point at it in the product, it does not get a date.

The fixes stay in, including the embarrassing ones — sign-in broken on every panel, health profiles reading back empty. A feed with no fixes in it has not been honest; it has been edited. And the quiet months stay quiet rather than getting filled.

The test we apply: would this entry still be here if it made us look slow? If the answer is no, it should not have been here when it made us look fast.

Shipped, or absent

Every entry is something running in production. Roadmap items are not in the feed at any date — they are in their own section, badged.

The fixes stay in

Including the ones that describe our own mistakes. The proportion of fixes to features is visible above, uncurated.

The API owns it

The changelog is data in the same API our apps call, not a document someone remembers to update. Until that endpoint is public this page ships a build-time copy of it, then reads it live.

Roadmap — not shipped

What is coming, labelled as a plan

None of the following is in the timeline above, because none of it is built. It is here because you deserve to know where this is going — and separate from the feed because a roadmap presented as a changelog is just a lie with a longer fuse.

Everything below is planned, not delivered. No dates, because dates we invented to sound confident would be the first thing on this page to become untrue. Ask us where any of it stands and you will get the real answer.

Roadmap

Deeper health features

Richer clinical surfaces built on the same engine — the primitives are there; the opinionated views on top of them are not, yet.

Roadmap

Family accounts

One person managing care for parents and children, without juggling logins. Family is already a plan tier; the full account model behind it is still ahead of us.

Roadmap

Reminders

Medication, follow-ups, vaccinations. Adherence is where most care actually fails, and it deserves more than a calendar entry.

Roadmap

Provider-side booking UI

Bookings work today, and providers see them. A richer scheduling surface on the provider side is being built.

Roadmap

Billing

Broader billing and settlement flows across the suite, following the same rule as everything else: your line items, your definitions.

Roadmap

Native DICOM & device bridges

Images and reports attach as files today, and the API accepts analyser writes. Native support is a roadmap item, not a shipped one.

The same list, and the same reasoning, appears on our about page — because it should not change depending on which page you land on.

Release notes

Get the next one in your inbox

An email when something ships. That is the entire proposition — no drip campaign, no “5 ways to transform your practice”, no sales cadence dressed as a newsletter.

A confirmation link, then release notes when something ships. Nothing else — no drip sequence, no sales cadence. Unsubscribe from any email.

The changelog

Fair questions about a page like this

Including the ones we would ask if we were reading it rather than writing it.

Whenever something ships — not on a marketing calendar. The entries are grouped by month and you can see the real cadence for yourself rather than take our word on it. Quiet months are left visible instead of padded, because a changelog that always has news is a changelog that has learned to count trivia as news.

This is the pace. Now imagine it pointed at your workflows.

Everything above reached its users without a migration, a change request or a release window. That is the product, not the release process.

Talk to usSee how the engine works

Multi-country by design · tenant-isolated · every change audit-logged