Branditify

Branditify for hospitals

A patient should not have to guess which department they need.

Most hospital websites list every department and answer the only question a patient actually has — where do I go, and what happens next — nowhere at all. Branditify builds the website, the service information, the appointment request and the handoff so one request carries its own context from the first search to the team that owns it.

Start a project How the booking works

Branditify is a digital studio. We build no hospital information system, EMR or clinical software, we support no diagnosis or triage, and we make no compliance, accreditation or certification claim.

Meridian HospitalMulti-speciality hospitalREQ-2048
On the book

The patient knows when, where in the building, and what to bring.

Who is asking
Ananya Rao
What they need
In their own words, kept with the request.
Which service
Outpatient consultation · the department that handles it
Source
Website · the service page
Owner
Appointments desk
Next step
Attend · the request stays open until they do.
ReferenceREQ-2048 · confirmedPre-visit informationWhere to report, and what to bring

An illustrative request. Meridian Hospital, its patient and its reference are invented.

What Branditify can build

The systems a hospital can operate, and the work that gets them there.

Two different things, and the difference decides what a project actually is. A system is something a team uses every day. A service is a piece of work with a start and an end. Everything below links to its own page, where it is described as the general thing it is rather than the hospital version of it.

Systems a hospital can operate

Four, and none of them is a hospital information system.

Branditify builds more systems than these. These are the ones that change something on the access side of a hospital — before a patient becomes a clinical record, and around the systems that already hold one.

Lead system · the appointment request

Booking Platform

Appointment requests arrive by phone, by form and by message, and the only record of Tuesday is whoever happened to answer.

A request that carries the service asked for, what the patient said, where it came from and who owns it — moving through states a team can actually see: requested, owned, confirmed, handed over.

An appointment request stops depending on who picked up.

The appointments desk, and whoever answers the phone at four in the afternoon.

It handles the request for an appointment. It is not a hospital information system, it holds no clinical record, and it does not triage, prioritise or assess anybody.

Booking Platform
System · who owns the enquiry

CRM

Enquiries arrive across departments and nobody can say which ones still need a reply, or from whom.

The enquiry relationship — where it came from, which service it concerns, who owns it, what stage it is at and what happens next.

An enquiry stops belonging to everybody and therefore to nobody.

It manages the enquiry relationship. It is not an HIS or an EMR, it holds no clinical record, and chapter eight is about exactly where that line falls.

CRM
System · what a patient can see

Patient Portal

Every appointment change and every routine question becomes a phone call to a desk that has to go and look.

A controlled patient-facing view of what the hospital has chosen to publish to them — their own requests, their confirmations, and the pre-visit information for the appointment they hold.

The routine questions stop arriving as phone calls.

The hospital decides what a patient sees. This is an access portal, not a clinical records system, and no connection to an existing HIS, EMR or lab system is assumed or implied.

Patient Portal
System · where requests are sitting

Dashboards

Nobody can see the access journey across departments without opening four things and asking two people.

The operational state of the non-clinical journey — how many requests are unowned, which services they concern, and where they have stopped.

The morning question has an answer before the meeting.

It reports the states the connected systems actually hold. It shows no clinical data, no patient counts and no outcome, and it invents no figure the source does not contain.

Dashboards

Most hospitals that start here start with the website and the request, because that is where patients are actually being lost. The portal and the dashboards earn themselves later, once the volume of routine calls or the number of departments makes the gap obvious.

What Branditify builds

The work, described for a hospital.

Each is a full service in its own right, and its own page explains it in general terms. What is below is what it means when the visitor is a patient who does not yet know which department they need.

Service · design and build

Hospital websites

The site lists forty departments alphabetically and answers the one question a patient has — which of these is mine — nowhere.

Structuring services by what a patient is actually trying to do rather than by how the hospital is organised internally: what each service is, who it is for, where in the building it happens, and how to ask for an appointment.

A patient can find the right service without telephoning to ask.

It presents what the hospital publishes about its services. It gives no medical information, no advice, and no guidance on what care anybody needs.

Hospital websites
Service · structure and discovery

Search and answer-engine work

People search in their own words and the site answers with a homepage and a department directory.

Structuring what each service is, who it is for and where it happens so that the questions patients actually type reach the page that answers them directly.

The right service page is reachable by the words a patient uses.

No ranking, position, inclusion or patient volume is promised, and no medical question is answered on the hospital’s behalf.

Search & answer engines
Service · build and connect

Connecting what already runs

The hospital already runs its own systems, and the public journey knows nothing about them.

Establishing which system is authoritative for what, what it will actually expose, and building only the bounded piece that genuinely does not exist.

The access layer and the operational layer stop being retyped between.

No integration is promised before it is verified. No connection to any named HIS, EMR, lab, pharmacy or insurer system is claimed, and many hospital systems expose nothing at all.

Custom systems
Service · only within a boundary

Assistants and routing, where they help

The same non-clinical questions arrive all day: what time, which floor, what to bring, how to reschedule.

An assistant scoped to the hospital’s own published pages that answers those, captures an appointment intent, and hands anything else to a person.

The desk stops answering the same five questions during clinic hours.

It answers from the hospital’s approved pages only. It never gives medical advice, never assesses symptoms, never triages and never handles an emergency — those go to a person, immediately and every time.

Assistants & automation

Where the journey breaks

Every one of these ends in the same place: a phone call the hospital did not need.

Hospitals rarely describe a missing feature. They describe a switchboard carrying questions the website should have answered, and requests nobody can account for.

01

Which department do I need?

The patient, and the switchboard that answers instead of the website.
What they find todayForty services listed alphabetically, described in the hospital’s own vocabulary.
What would answer themServices organised by what a patient is trying to do, in the words they would use.Hospital websites

They telephone, or they go to a hospital whose site made it obvious.

02

Who is dealing with my request?

The patient, who telephones to check, and the desk that has to go and look.
What they find todayIt arrived on a form, went to a shared inbox, and is now with whoever saw it first.
What would answer themA request that carries its service, its source and an owner from the moment it exists.CRM

A request that was ready to become an appointment quietly stops moving.

03

What am I supposed to bring?

The appointments desk, and the patient who waited on hold to ask.
What they find todayThe answer exists, somewhere, on a page nobody can find, so the desk repeats it all day.
What would answer themPre-visit information attached to the confirmed appointment rather than to a page.Patient Portal

Time that should be going to the requests that have not been answered at all.

The expensive break

A request nobody owns is not a slow request. It is a patient who went somewhere else.

Everything else on this page is an improvement. This is the failure that costs a hospital real appointments, and it is nearly invisible, because a request nobody owned leaves no trace of having existed.

What usually arrivesAs it arrives
Who is asking
A name and a phone number.
What they need
“Wants an appointment.”
Which service
Nobody recorded this
Source
Nobody recorded this
Owner
Nobody recorded this
Next step
Nobody recorded this
What can arrive insteadAs it arrives
Who is asking
Ananya Rao · a person, not a lead.
What they need
In their own words, kept with the request.
Which service
Outpatient consultation · the department that handles it.
Source
Website · the service page they read.
Owner
Appointments desk, from the moment it existed.
Next step
Confirm a time and say what to bring.

The difference is not effort. It is whether somebody can pick this up cold and act on it, or has to telephone the patient to find out what they already said.

The question the directory cannot answer

A hospital is organised by department. A patient arrives organised by problem.

This is the single structural difference between a hospital website and a clinic website, and it is the one the market ignores. A clinic has one reception and one answer. A hospital has forty services, an internal vocabulary, and a patient who does not share it.

How the hospital is organised

  • By department, because that is how the institution runs.
  • By speciality name, because that is what the consultants are.
  • By building, floor and block, because that is where things are.
  • Alphabetically, because it has to be listed somehow.

None of this is wrong. It is simply the wrong index for somebody who has never been here before.

How a patient arrives

  • With a problem described in ordinary words.
  • With a referral naming something they cannot place.
  • With a question about whether this hospital even does it.
  • With a preference about when, and how far they must travel.

A directory answers none of those. The site has to carry both indexes, and let the patient use theirs.

What should a modern hospital website include?

Enough for a patient to reach the right service without telephoning: services described by what they are for rather than only by their speciality name, who each is for, where in the hospital it happens, what to expect and how to request an appointment. A hospital is indexed by department and a patient arrives indexed by problem — the site has to carry both and let the patient use theirs. Everything else, the awards and the gallery, is optional and usually over-built.

A real decision

An enquiry form is often enough. Until it is not.

A booking system is not automatically better than a form, and selling one to a hospital that does not need it is how digital budgets get wasted. The question is what actually changes.

A form is enough

  • When one desk sees every request and answers it the same day.
  • When there is no availability to show, because a person allocates it.
  • When the volume is steady and nobody is chasing what happened.
  • When the reply is a phone call and that is genuinely the service.

What a form cannot do is hold a state. It cannot tell you what is unowned, and it cannot tell the patient anything after they press send.

A booking platform earns itself

  • When requests arrive faster than one desk can answer them.
  • When several departments must be held apart rather than pooled.
  • When somebody other than the desk needs to see what is outstanding.
  • When rescheduling is frequent enough to be its own workload.

What it will not do is replace the phone. Most hospitals that add one keep taking calls, and should.

Booking Platform

Does a hospital need online appointment booking?

Not always. A form into one desk that answers the same day is genuinely enough for lower volumes. A booking system earns itself when requests outpace the desk, when departments must be held apart rather than pooled, when somebody besides the desk needs to see what is outstanding, or when rescheduling has become its own workload. What it does not do is replace the telephone — most hospitals that add one keep taking calls.

Two different jobs

A website is for people who have not chosen you yet. A portal is for people who already have.

They get discussed as if one replaces the other. They serve different people at different moments, and building the second before the first is the most common sequencing mistake in this category.

WhatWhyPatientHospital
Their own requestsWhat they asked for, and where it has got to.✓✓
Their confirmationsWhen and where, without telephoning to check.✓✓
Pre-visit informationWhat to bring and where to report, attached to the appointment.✓✓
Their own contact detailsWhat the hospital holds, and how to get it corrected.✓✓
Clinical records and resultsThese live in the hospital’s own clinical systems. This is not one, and does not hold them.––
Internal notesWorking notes are written for colleagues, not for patients.–✓
Another patient’s anythingThe single thing a portal must never get wrong.–✓
What this portal is not
  • It is an access portal. It is not a clinical records system, not an EMR and not a patient health record, and it holds no diagnosis, result, prescription or clinical note.
  • It shows what the hospital’s own connected systems hold and what the hospital has chosen to publish. No connection to an existing HIS, EMR, lab or pharmacy system is assumed or implied.
  • Access, collection and retention are scoped around the hospital’s own requirements and obligations during scoping. Branditify claims no HIPAA, ABDM, NABH, ISO, GDPR or other compliance, accreditation or certification, and gives no legal advice.

What is the difference between a hospital website and a patient portal?

The website is for people who have not chosen the hospital yet — it explains what the services are, who they are for and how to ask for an appointment, and it has to work on somebody who has never been there. A portal is for people who already have: their own requests, confirmations and pre-visit information behind a login. They solve different problems for different people, and a portal built before the public journey works serves the patients you already have while the ones you are losing never arrive.

The distinction that gets blurred

A CRM and a hospital information system are not competitors. They barely overlap.

This is the comparison hospitals are most often sold badly, usually by somebody implying that one can stand in for the other. They hold different things about different moments, and a hospital that runs both is the normal case rather than the extravagant one.

A CRM holds the relationship

  • Where an enquiry came from, and which service it concerns.
  • Who owns it, what stage it is at, and what happens next.
  • What has been said to this person, and by whom.
  • Everything that matters before somebody becomes a patient.

What it does not hold is anything clinical. No record, no result, no history — asked to, it becomes a dangerous imitation of the next column.

CRM

An HIS or EMR holds the care

  • The clinical record, and everything recorded against it.
  • Orders, results, notes and the history of treatment.
  • Hospital-wide clinical, administrative and financial operations.
  • The systems the hospital already runs, and should keep running.

Branditify builds none of this. It is a different category of software with different obligations, and nothing on this page replaces, certifies or connects to it by default.

They are complements, and the join is scoped not assumedLarge hospitals commonly run both, and the useful question is never which to buy. It is what, if anything, should pass between them — and that is settled by what the existing system actually exposes, during scoping, rather than promised in advance. A project designed around a connection that turns out not to exist is the most expensive mistake in this category.

Hospital CRM vs HIS — what is the difference, and does a hospital need a CRM?

A CRM holds the relationship before somebody is a patient: where the enquiry came from, which service it concerns, who owns it and what happens next. An HIS or EMR holds the care — the clinical record, orders, results and hospital-wide operations. They are complements rather than substitutes, and most large hospitals run both. A CRM earns itself when enquiries arrive across several departments and nobody can say which still need a reply; it should never be asked to hold clinical information.

A real decision

A hospital app cannot help the patient who has not chosen you yet.

Apps get sold to hospitals as modernisation. An app is for people already inside the relationship; the patients a hospital is losing are, by definition, not — they will never install anything to ask a question.

A mobile website is enough for

  • Every first-time patient, all of whom arrive from a search or a link.
  • Finding the right service, and understanding what it is.
  • Requesting an appointment and receiving a confirmation.
  • Anything that must work for somebody who has never been here.

What it cannot do comfortably is hold a repeated, logged-in relationship. That is the honest limit.

An app starts to earn itself for

  • Patients in an ongoing course of care, returning repeatedly.
  • Staff workflows away from a desk, inside the hospital.
  • Anything genuinely used often enough to survive on a home screen.
  • Cases where the hospital can support it for years, not one launch.

Its limit is installation, and its real cost is the years afterwards. A hospital with one launch and no daily use ends up maintaining an app nobody opens.

App development

Should a hospital build an app or improve its mobile website first?

The website, almost always. An app cannot reach the patient who has not chosen the hospital yet — they will never install one to ask a question — so it does nothing for the people you are currently losing. An app earns itself for patients in an ongoing course of care or for staff workflows inside the building, where there is genuine repeated use. Its real cost is not the build; it is maintaining it for years afterwards.

One possible setup

How this connects around a single request — and where it stops.

One architecture, not a package. Most hospitals build the first three and stop there for a year, which is usually right. The last line is the important one.

03 stepsWhere the patient is found
01Search or referralWhere a patient actually starts.
02The hospital websiteServices indexed by what they are for.
03Service informationWhat it is, who it is for, where it happens.
04 stepsWhere the hospital operates
04An appointment requestCarrying service, source and what was said.
05Booking workflowRequested, owned, confirmed — states a team can see.
06The owning teamA named desk, from the first moment.
07Confirmation and pre-visitWhen, where, and what to bring.
02 stepsOnly where it earns itselfNeither is a default.
08Patient portalOnly where routine questions justify it.
09DashboardsOnce there is enough to need a view across it.
Where this stops, precisely
  • The hospital’s existing clinical and operational systems remain the source of truth. Nothing here replaces an HIS, an EMR, a LIS or a pharmacy system, and nothing here is a clinical system.
  • Whether the access layer exchanges anything with those systems is established during scoping, against what they actually expose. Many expose nothing, and a project designed around a connection that does not exist is the expensive mistake here.
  • No integration with any named vendor or national platform is claimed on this page, and no compatibility is implied by the diagram above.

Can a new booking or CRM layer connect with existing hospital software?

Sometimes, and it depends entirely on what the existing system exposes. Some publish an interface worth building against; many hospital systems publish none at all. For those the honest answer is one authoritative source and a defined direction of travel, kept in step deliberately, rather than a pretence of live two-way sync. That is settled before the build, because a project designed around a connection that turns out not to exist costs more than the connection would have.

Where to start

Digitise the handoff that is failing, not the one that is easiest to buy.

Hospitals rarely lack systems. They lack a working join between the public journey and the operational one, and the right first project is whichever join is currently costing the most.

Find where the phone calls come fromThe switchboard already knows. The questions it answers most are the pages the website is missing, and that is free research nobody does.
Fix the finding problem before the booking oneA booking system underneath a site nobody can navigate collects requests from the few who got through. The order matters more than the tools.
Give the request an ownerBefore availability, before rescheduling, before a portal. An unowned request is the failure that actually loses patients.
Only then, add what earns itselfA portal when routine questions occupy somebody daily. Dashboards when several departments need one view. An app almost never first.
Leave the clinical systems aloneThey work, they are governed, and replacing them is not a digital-experience project. Connect where it is possible and stay out of the way where it is not.

What should a hospital digitise first?

The handoff that is currently failing, which is almost never the one easiest to buy. In practice that means the finding problem before the booking problem — a booking system underneath a site nobody can navigate only collects requests from the few who got through — and then giving every request a named owner before adding availability, rescheduling or a portal. The switchboard already knows which questions the website is failing to answer; that is the cheapest research available and almost nobody does it.

Selected work

Website, request and product work.

Each of these is shown for a specific thing it documents about the journey on this page, and each says exactly what it was and in which category.

Ayurveda & wellness · 2024

VedaMedi

A brand identity and a premium website built together, so the site expressed the positioning rather than decorating it.

BrandingPremium WebsitesLogo DesignBrand Identity

Shown for the website build. A wellness brand, and not a hospital.

View VedaMedi
B2B logistics · 2024

Swift Logix

A website carrying a service booking interface and a CTA-led enquiry journey — the closest documented case for a site whose job is to hand over a request somebody can act on.

Website DevelopmentUX/UI DesignLogistics Website DesignResponsive Web Design

Shown for the request handover. Logistics, and not healthcare.

View Swift Logix
Health & fitness · 2024

LeanTrack

A mobile application designed and built around genuine repeated daily use — the evidence behind the website-versus-app chapter above.

EditorialMobile App DevelopmentUX/UI DesignHealth App Design

Shown for the app decision. A consumer health app, and not a hospital system.

View LeanTrack
Insurance · 2024

FWD Insurance

A digital experience engagement for an institution whose customers arrive with questions before they arrive with intent — UX and interface design, website experience design, interaction design and brand storytelling.

UX/UI DesignWebsite Experience DesignInteraction DesignBrand Storytelling

Shown for institutional website experience. Insurance, and not a hospital.

View FWD Insurance

Scope shown per project is taken from that project’s own record. No patient, appointment, enquiry, wait-time, occupancy, revenue or clinical figure is attached to any of them, and no hospital deployment is claimed.

Questions

Hospital questions, answered directly.

What should a modern hospital website include?

Enough for a patient to reach the right service without telephoning: services described by what they are for rather than only by their speciality name, who each is for, where in the hospital it happens, what to expect and how to request an appointment. A hospital is indexed by department and a patient arrives indexed by problem — the site has to carry both.

Does a hospital need online appointment booking?

Not always. A form into one desk that answers the same day is genuinely enough at lower volumes. A booking system earns itself when requests outpace the desk, when departments must be held apart rather than pooled, when somebody besides the desk needs to see what is outstanding, or when rescheduling has become its own workload. It does not replace the telephone.

What is the difference between a hospital website and a patient portal?

The website is for people who have not chosen the hospital yet and must work on somebody who has never been there. A portal is for people who already have: their own requests, confirmations and pre-visit information behind a login. Building the portal before the public journey works serves the patients you already have while the ones you are losing never arrive.

Hospital CRM vs HIS — what is the difference, and does a hospital need a CRM?

A CRM holds the relationship before somebody is a patient: source, service, owner, stage and next step. An HIS or EMR holds the care — the clinical record, orders, results and hospital-wide operations. They are complements rather than substitutes, and most large hospitals run both. A CRM earns itself when enquiries arrive across several departments and nobody can say which still need a reply; it should never hold clinical information.

Should a hospital build an app or improve its mobile website first?

The website, almost always. An app cannot reach the patient who has not chosen the hospital yet, so it does nothing for the people you are currently losing. An app earns itself for patients in an ongoing course of care or for staff workflows inside the building. Its real cost is not the build; it is maintaining it for years afterwards.

How can hospitals organise appointment enquiries?

So that each request arrives carrying which service it concerns, what the patient actually said, where it came from and who owns it — before anybody picks up the phone. The owner matters most: a request belonging to every department belongs to none, and that is the failure that quietly loses appointments rather than delaying them.

What digital systems are useful for a multi-speciality hospital?

Fewer than most vendors suggest, and in a specific order. A website that lets a patient find the right service in their own words; somewhere an appointment request gets a service, a source and an owner; and confirmation and pre-visit information attached to the appointment. A patient portal and dashboards earn themselves later, once routine questions or the number of departments make the gap obvious.

Can a new booking or CRM layer connect with existing hospital software?

Sometimes, depending entirely on what the existing system exposes. Some publish an interface worth building against; many hospital systems publish none. For those the honest answer is one authoritative source and a defined direction of travel rather than a pretence of live sync. That is settled before the build, because a project designed around a connection that does not exist costs more than the connection would have.

What should a hospital digitise first?

The handoff that is currently failing, which is rarely the one easiest to buy. The finding problem comes before the booking problem, because a booking system underneath a site nobody can navigate only collects requests from the few who got through. Then give every request a named owner. The switchboard already knows which questions the website is failing to answer.

Does Branditify build a hospital information system, EMR or clinical software?

No. There is no Branditify HIS, EMR, EHR or clinical system, and clinic or practice management software is not a hospital information system either — they are materially different scopes. What Branditify builds is the access side: the website, the service information, the appointment request, the confirmation and the operational handoff around the systems a hospital already runs.

Can a hospital chatbot answer patient questions?

Non-clinical ones, from the hospital’s own published pages — timings, floors, what to bring, how to reschedule, and capturing an appointment intent. It must never give medical advice, assess symptoms, triage or handle an emergency; those go to a person immediately and every time. An assistant that answers a clinical question is not a better assistant, it is a liability.

Is Branditify’s work HIPAA, ABDM or NABH compliant?

That is not a claim we make, and treating any website or software as compliant by default would be misleading. What a specific hospital must record, retain, disclose and control depends on its own obligations, systems and jurisdiction. What we do is establish which records, permissions and retention the intended workflow requires during scoping and build to that. We hold no certification or accreditation and give no legal or compliance advice.

What determines the scope of a hospital digital project?

How many departments and sites must be represented, what state the existing service content is in, whether a booking workflow and a portal are included, what must connect and whether those systems actually expose anything, and how many teams need to agree. Getting service information into an agreed, patient-facing shape is usually the longest task, and it happens before any feature does.

Next

Ask the switchboard what people ring to ask.

The five questions they answer most are the five pages your website is missing. It costs nothing to find out, and it is a better brief than any audit we could sell you.

Start a project Talk to us
Booking PlatformCRMPatient PortalHospital websitesMultispecialty clinicsAll industries