Healthcare

Software that treats patient data as a permission problem

Portals, staff tools, and grounded assistants with access designed before the first prompt. Written SOW. We engineer with those constraints; we do not practice medicine.

A chatbot is not a care pathway.

You have seen the demo that answers a question from a PDF. Then someone has to decide who may see that row, log the retrieval, and still be around when a clinician says the citation is wrong. That second part is the job.

Myrafy is a software company in Noida. We take one portal, one staff tool, or one grounded assistant into production - with permissions and logging in the first slice - and put the code in your repo.

What we put in a statement of work

Pick the surface your staff or patients will actually open.

01The screens people live in

Patient and staff portals

Calm, role-aware apps for the jobs that already happen: intake, messages, schedules, the unglamorous admin. Built against the way the clinic works today.

  • Roles from the first screen
  • One product, not five micro-frontends
  • Weekly demos until it is in use
02Who may see a row is the product

Permission-aware data

Access models, audit logs, and the boring work of not leaking a chart into the wrong session. Designed before features pile up.

  • Least privilege, written down
  • Audit-friendly changes
  • No shared logins as a shortcut
03Search with citations, not a confident guess

Grounded documentation assistants

Retrieval over the policies and notes you already have. If we cannot show where an answer came from, it does not ship.

  • Citations on the answer
  • The same access model as the rest of the product
  • A person who owns a wrong answer
04The system of record stays the system of record

Integrations next to the record

APIs and jobs beside the EHR or the store you already pay for. We are not here to replace the clinical record over a weekend.

  • Your existing store if it holds
  • A written fail path
  • A handoff your next engineer can run

The model is usually not the hard part.

This dies in permissions, a corpus nobody owns, and a go-live with no fail closed. We start there.

01

Permissions

Everyone can see everything in staging, so it ships that way.

  • Shared test accounts that become production
  • No audit of retrieval
  • A prompt that ignores the role

We write who-can-see-what into the first slice, including the assistant.

02

The corpus

The PDFs are a junk drawer.

  • Policies from three years ago
  • No owner for a wrong citation
  • A demo on a clean folder that is not production

If the documents are stale or unlabeled, retrieval will be too. We say that before we index anything.

03

Fail open

When retrieval misses, the product still answers.

  • Hallucinated care advice
  • No person on the hook
  • Logging that cannot be reviewed

We fail closed. A missing citation is an empty state, not a confident paragraph.

Two ways to start

Most teams pick one. Neither needs a 40-page transformation deck first.

01If the first surface is clear

Fixed-scope portal or assistant

A staff tool, a patient slice, or one grounded search. Written inputs and acceptance. Weekly demos. Full IP when the milestone closes.

  • Best when the roles are known
  • The same engineers through release
  • Your repo
02If the clinic will keep changing the workflow

Ongoing product work

A retainer after the first surface is live. Useful when documentation, access, and small features keep moving.

  • A cadence you can plan around
  • Still a written SOW
  • You keep the source

Name the roles, build the surface, ship it, and stay until you can run it.

Four steps. We will not promise to replace the clinical record from a kickoff.

  1. 01

    Name the roles

    Sit with the people who do the work. Name who may see a row, the first surface, and what done looks like.

  2. 02

    Build the surface

    Against your APIs and data. Permissions and logging from day one. The people who scoped it are still on the calls.

  3. 03

    Ship something staff will open

    A release in an environment you control. Not a demo that dies when the project ends.

  4. 04

    Stay until you can run it

    Runbook, access, and how to keep shipping. If the work continues, that can be a retainer.

What we write into every SOW

  1. 01

    Permissions before prompts

    If we cannot say who may see a row, we are not ready to index it. Discovery can be a paid slice if you are not there yet.

  2. 02

    Fail closed

    No citation, no answer. A wrong retrieval is an empty state, not a paragraph that sounds sure.

  3. 03

    Your repo

    Code lands where you can keep it. We do not trap the work in a private toolkit only we understand.

You contract us. You keep the IP.

The commercial bit, without invented win rates. We will publish customer stories when we have permission.

  1. 01

    Written SOW

    Inputs, owners, acceptance, and the fail path before we start. Fixed-scope when the slice is clear. Retainer when it will keep growing.

  2. 02

    Senior engineers on the work

    The people who scoped it stay on delivery. 15+ years collective experience. You will not get a junior bench behind a slide.

  3. 03

    You own it

    Code, docs, and runbooks transfer to you. We do not lock this in a product only we can run.

  4. 04

    Estimate in one business day

    Typical reply from Noida the next working day. If the workflow is still fuzzy, discovery can be a paid slice.

What you receive at handover

01

A running surface

The portal or assistant in the SOW, in an environment you control.

Handover checklist
  • 01A running surface
  • 02The source
  • 03How access works
  • 04How to run it
Transferred to you
02

The source

Repos, history, and enough structure that the next engineer is not lost.

03

How access works

Roles, audit notes, and the decisions that would otherwise live in chat.

04

How to run it

Deploy path, who to call, and the IP. You own it.

Examples of this work

Shapes, not named clients yet. If yours is close, we will write a proposal around your constraints.

Representative patternStaff tools

A staff portal with roles from day one

The jobs a clinic already does - queues, notes, the admin that keeps the happy path honest - with audit-friendly changes and a written SOW.

  • Roles from day one
  • Weekly demos
  • Full IP

Representative patternGrounded search

Policy search that cites the page

Retrieval over documents you already have, with the same access model as the rest of the product. No answer without a citation.

  • Citations on the answer
  • Fail closed
  • A runbook

More shapes on representative work →

Questions we get

What we usually use

We use what is already in your stack when we can. This is not a vendor lock-in.

  • OpenAI
  • LangChain
  • TensorFlow
  • RAG
  • MLOps
  • iOS
  • Android
  • React Native
  • Next.js
  • Flutter
  • Java
  • Node.js
  • .NET
  • React
  • PostgreSQL

Have a clinical surface to ship?

Send the workflow and who may see a row. We usually reply with an estimate the next business day.

Get a Free Estimate
Contact us