> In development. This is an in-house product we are building, not a
> completed client engagement. The capabilities below describe the platform as
> designed. Individual modules are at different stages, and nothing here is
> represented as commercially deployed.
Why we are building it
Healthcare software has to fit the clinic, not just the specification. Working
on health information systems made a pattern obvious: the expensive failures are
rarely technical. They come from records that cannot be trusted, identity that
was never properly decided, and workflows that assume a reliable network in
buildings that do not have one.
Bararchet EMR is our attempt to start from those constraints rather than retrofit
around them.
What it is designed to do
- Patient management — registration, demographics, identifiers and a
consolidated patient timeline, with merging treated as a first-class feature
rather than a cleanup script.
- Clinical records — structured encounter notes, problem lists, allergies,
vitals and history.
- Appointments — scheduling across clinics and practitioners, with reminders
and queue visibility.
- Laboratory integration — order entry, sample status, and results released
back into the patient record.
- Pharmacy — prescribing, dispensing records and stock visibility.
- Billing and insurance — service pricing, invoices, payer details and claim
preparation.
- Analytics and reporting — operational and clinical reporting shaped by
facility and programme reporting needs.
- Role-based access — granular permissions with an audit trail that records
reads, not only writes, because "who opened this record?" is a question that
gets asked during an investigation.
Design decisions we have already made
Interoperability is a constraint, not a later phase. Internal field names are
aligned to standard resource shapes from the start. Exposing an API in the first
release is optional; having to migrate the schema to add one later is not.
Data outlives contracts. A documented schema, a scheduled export in an open
format and a tested restore are part of the product, not a professional-services
add-on. A facility that cannot get its own data out without calling us would be
a hostage, not a customer.
Degradation is designed. Facilities with intermittent connectivity will at
some point be running on a local cache. That behaviour is decided up front,
because retrofitting it into a system built for a reliable connection is close
to a rewrite.
Where it stands
In active development. If you run a facility and this is the kind of system you
need, we would genuinely rather hear from you now, while decisions are still
open, than after launch.