We are a healthcare software development company based in Casablanca, building clinic, laboratory and patient-portal software for healthcare operators and coverage bodies — patient records, scheduling, billing, claims submission and patient portals — as a nearshore team on European hours. Four platforms in production: Médiviz, Doctifile, Parahealth and LA MAS. Business module from 40,000 MAD, full platform from 120,000 to 500,000 MAD.

What we build for a healthcare provider

Patient records — identity, history, documents, procedures performed, with role-partitioned access.
Scheduling — by practitioner, by room, by equipment, with reminders.
Procedures and billing — coding, tariff schedules, payer share and patient share calculated separately.
Claims submission — assembling pre-authorisation and reimbursement files, and tracking what happens to them.
Patient portal — results, documents, invoices, upcoming appointments.
Reporting — activity per practitioner and per procedure, settlement times, outstanding balances per payer, rejection rates.

Four healthcare platforms in production

Médiviz — a medical and pharmaceutical CRM: the commercial side of a health business, with the visit and prescriber data that comes with it.
Doctifile — the patient journey and the circulation of medical documents between practitioners and patients.
Parahealth — health and parapharmacy e-commerce: catalogue, stock and order flow rather than clinical records.
LA MAS — a health-coverage platform on the payer side: member portal, healthcare-provider workspace and administrator back office.

Four platforms covering four sides of the same industry: the provider who treats, the patient who consults, the payer who reimburses, and the retail channel that sells. That range is the reason we can tell you early which parts of your build are ordinary and which are not.

How we engage

The delivery model matters as much as the stack when the team is in another country, so this is how it works in practice — and every element of it is already published on our pricing page rather than invented for this one.

Dedicated team. Named developers embedded in your process, billed per day. You know who is on your project, and they stay on it.
Fixed-scope build. A costed scope agreed before the build starts, produced by the diagnostic below.
Maintenance and support once it is live — see maintenance and support.
A weekly demonstration. Progress is shown running, not reported in a status column. It is also the cheapest way to catch a misunderstanding while it is still cheap.
Who owns the result. Source code, data and documentation are yours. We do not hold a client through a proprietary licence.

Data protection and hosting

If you are assessing a supplier for a healthcare build rather than buying a product, these are the questions that decide it — and the ones we would want answered in your position:

Data residency and hosting. Where the data physically sits is a decision, not a default. We deploy to your own infrastructure, to a provider you choose, or to hosting we manage — and the answer to “who else can reach this data” is part of the design rather than an afterthought.
Audit trail. Reads logged, not just writes. On a medical record, knowing who looked at what is the whole point, and it is the single thing most retrofits cannot add convincingly.
Role partitioning. Practitioner, front desk, billing and management do not see the same fields. “Everyone sees everything” is the most common default and the hardest to defend under audit.
Retention, enforced. A period per category of data, applied by a purge that actually runs — a written policy deletes nothing.
Interoperability. Exchanging structured data with a laboratory analyser, an imaging system or a third-party platform needs a shared format. We work in HL7/FHIR where the counterpart supports it, and through a dedicated API where it does not. We will tell you which before the quote, not during integration.
Encryption at rest and in transit, and the ability to answer an access or deletion request without manual reconstruction.

What we do not do is put a certification badge on this page that we cannot produce on request. Where a regulatory obligation is yours, we build to it and we say which parts of the evidence the software can generate and which are organisational. Where Moroccan law applies, the authorisation file is prepared during scoping rather than during testing — see CNDP compliance and the guide on health data and the CNDP. For a European controller working with a Moroccan supplier, the transfer question is covered in law 09-08 and the GDPR.

Working with a Casablanca team from the UK

Nearshore only works if the practical questions have dull answers. Ours do.

The clock. Morocco runs on UTC+1 all year, so Casablanca is one hour ahead of London through the UK winter and on the same clock during British Summer Time. There is no morning-gone-by-the-time-they-wake problem to manage, and no overlap window to protect — the working day is the same working day. The one exception is Ramadan, when Morocco moves to UTC+0 and we are on London time exactly.
Language. English and French are both working languages here. That matters when the clinical staff who use the software and the buyer who commissioned it do not share one.
Distance. Three hours from London by air, same-day travel in both directions when a workshop needs to be in a room.
Contracting. We contract directly from Casablanca. Terms, invoicing currency and the IP assignment are settled in writing during the diagnostic, before any build starts — so there is nothing left to discover at signature.
Cost. Published day rates rather than a quote on request. They are on the pricing page, and they are the same rates a Moroccan client pays.

Why an off-the-shelf product is not always enough

A packaged practice-management product does one practice very well: calendar, records, billing, in a standard frame. We become relevant when one of these is true — and one is enough:

Several sites, one management. A clinic group or laboratory network wants a shared patient record, different permissions per site, and consolidated reporting. Most products handle one establishment at a time, and the consolidation ends up in a spreadsheet.
An integration that already exists. Accounting, laboratory analysers, imaging, a payer platform: as soon as a flow must be consumed rather than re-keyed, integration capability matters more than feature count.
Coverage rules that are yours. Ceilings, procedures needing prior approval, differentiated co-payments. A product offers configurable fields; whatever does not fit them leaves the software. See insurance and health funds.
A regulatory file to assemble. Health data is the most protected category under Moroccan law 09-08 and requires prior authorisation rather than a declaration — two months of review, extendable once. A purchased product does not file that for you.

Should you talk to us, or buy a product?

Several Moroccan products cover practice management — Pratisoft, Cabidoc and Sobrus among them. For a single practice with standard processes, one of them is probably the right choice: available immediately, cheaper than a build, and its limits will not get in your way.

We answer the opposite question: what to do when none of them fits. If none of the constraints above applies to you, we will say so and point you at a product. A project sold to an organisation that did not need one ends badly for both parties.

Working with a national claims scheme, not against it

Where a country runs its own electronic claims scheme — in Morocco, the CNSS electronic care claim — we integrate with it rather than competing with it. Such schemes are designed to work with the practice-management software already installed, so the work is interoperability and migration: mapping your procedures, insured parties and practitioners onto the expected reference data, tracking a submission’s state and rejection reason, and handling the transition period in which paper and digital coexist.

It is worth saying plainly, because the opposite is sometimes sold: a supplier who offers to build you a replacement for a national scheme is offering something you cannot use.

Start a scoping call

The first step is a five-day diagnostic: mapping of roles and permissions, an inventory of integrations, regulatory flows, a prioritised backlog and a costed scope. The document is yours whether or not you continue, and it is credited against what follows.

Then a business module before the full platform — usually scheduling or claims files, because those are the two that relieve the front desk immediately. Six to ten weeks, in production, with the same code growing afterwards.

Request a quote or book a scoping call. Tell us the establishment, the constraint, and the date that matters; we will tell you whether we are the right supplier for it. See also business platforms and our pricing.

Healthcare software development company