Skip to content

Create an account

HekimBis home

Patient management and Patient 360

Every patient's appointments, visit notes, test results, messages, consents and payments appear on the same patient card. Duplicate records are caught before they are created; when one slips through, an authorized user approves the merge and it stays traceable.

A medical secretary at a desk comparing two closed patient folders side by side
Clinic staff welcoming two patients at a reception desk with teal chairs

The patient card is the clinic's memory

A clinic should not have to get to know a patient again at every visit. The main card holds identity and contact details, family and guardian relations, the emergency contact, insurer or institution details and communication preferences, and every event concerning the patient attaches to it.

The card rests on one patient identity for the whole organization, so a person who visits two branches is never split into two files. A shared identity is not open access, though: another branch's clinical information becomes visible through explicit membership, assignment and a care relationship.

When a card is opened, HekimBis shows candidate matches, and if the patient was previously recorded as a prospect, the source and conversation history carry over to the card. Records that arrive through data migration go through the same duplicate check.

International patients
Passports and supported foreign ID documents are recorded with type, number, issuing country and expiry date. A foreign patient's card is opened without a Turkish ID number.
Institution and insurance
Institution or insurance details are kept on the patient card, and the appointment and finance screens use the same information.
Relatives and emergency contact
The person to call in an emergency is recorded on the card together with the patient's relatives.
Parents and guardians
For children and patients who need a guardian, the relationship, its scope and its duration are kept on the card, and the guardian's portal account works within that relationship.
Communication preferences
The patient's preferred channel, time window and language sit on the card. Reminders and confirmations follow them, and commercial messages additionally pass a channel-consent check and, where required, an İYS check.
Tags and alerts
Tags group patients. Alerts such as an allergy, a high-risk flag or a contact warning sit where everyone who opens the card sees them first.
Custom fields
Information specific to your organization lives in controlled custom fields rather than free text. Sensitive fields are masked and shown only with separate permission.
Record status
A record can be active, inactive, archived or marked deceased. Archiving and deactivating can be reversed, and records are never deleted in a way that cannot be undone.
A physician and a nurse reviewing a patient's history on the monitor before the consultation

A patient's history on a timeline

The Patient 360 timeline lists appointments, visits, tasks, messages, consents, documents, tests, payments and follow-ups in date order.

The physician reviews the history before the patient comes in. The front desk sees the pending appointment and the messages already sent while the patient is still on the phone. Accounting follows which procedures have been posted to the account at the cash desk. Everyone opens the same card, and each role sees the part it needs for its own work.

When patient information changes in one place it is current everywhere, and no one keeps a second list or file to copy it into.

Beside every entry on the timeline, who made it, when and why are kept, so the source of each entry is clear whenever the patient's history is read.

Clinical recordsAppointments and calendar

For duplicate records, the system suggests and a person decides

Two files for the same patient can mean a missing history and test results attached to the wrong record. HekimBis lists similar records as candidate matches when a record is opened, during imports and in regular scans.

A match never rests on name alone; identity, date of birth and contact details are compared together. Only an authorized user can approve a merge.

The preview shows which field will come from which record. The merge history is kept, so who did it, when and why can be answered later.

The check starts the moment a record is opened: when the front desk enters a name and date of birth on the phone, similar records are listed and the existing card can be picked instead of opening a new file. During an import the same check runs in bulk.

Merge previewAwaiting approval
NameM. KayaMehmet KayaMehmet KayaB
Date of birth03/12/198003/12/198003/12/1980A and B
Contact preferenceSMSWhatsAppWhatsAppB
AlertAllergyNoneAllergyA

The names and details shown are examples.

A front desk clerk on the phone checking a paper agenda while a patient waits behind

Each role sees the part of the card its work needs

Visibility does not depend on role alone; branch membership, the care relationship and the sensitivity of the information decide together. A starter role template is provided and adjusted to your organization.

Physician
Sees the clinical summary, sensitive notes and test results of patients in their care.
Clinical staff
Follows the clinical summary and tests of the patients their duties involve; sensitive notes open with separate permission.
Front desk
Sees identity and contact details, the appointment and the payment status.
Accounting
Sees collections, the patient account and revenue-share entries together with identity details.
Call center
Sees masked details, enough to find the patient and book an appointment.
Compliance and audit
Reviews masked records and the audit trail.

Another branch's patient information becomes visible through explicit membership. In an emergency, time-limited access can be opened with a written reason, and that access produces its own audit record.

Roles and permissions

Frequently asked questions

Who can change the information on the patient card?

Authorized roles can change card information, and every change is written to the audit trail with who made it, when and why. Access to sensitive fields depends on separate permission.

How does the patient portal relate to the patient card?

A portal account is linked to the patient card, and the patient sees their own appointments, forms, consents and payments in the portal. A parent or guardian account works with the relationship evidence and scope defined on the card.

Does the same patient appear in one record across two branches?

Patient identity is shared across the organization, so one person is never split into two files. Seeing another branch's clinical information requires explicit membership, an assignment and a care relationship.

How are duplicate patients prevented?

HekimBis lists candidate matches when a record is opened and during imports. An authorized user makes the merge decision, the preview shows field by field what will be kept, and the operation stays traceable. A name alone is never treated as grounds for a merge.

How do I register an international patient?

Passports and supported foreign ID documents are recorded with type, number, issuing country and expiry date, and the card is opened without a Turkish ID number. The preferred language and communication channel are kept on the card as well.

How are parents or guardians set up for child patients?

The family or guardian relationship is defined on the patient card, with its scope and duration on record. In the patient portal, a parent or guardian account works with that relationship as evidence and with limited permissions.

Can I delete a patient?

A patient record is moved to inactive or archived status; both can be reversed and are written to the audit trail. Records are not deleted irreversibly, and retention and deletion periods follow the law and your organization's policy.

How do I bring in my existing patient list?

The data migration feature brings patient records in from CSV and Excel files and from defined legacy system exports. They pass through a mapping preview, a trial import and a reconciliation step, and duplicate candidates still go to an authorized user for a decision.

Can I add my own fields to the patient card?

Yes. Controlled custom fields store the information your organization adds in an orderly, searchable form. Fields with sensitive content can be masked, and every change is written to the audit trail.

What are communication preferences on the patient card for?

The patient's preferred channel, time window and language are kept on the card. Reminders, confirmations and notifications follow them, and commercial messages also pass a channel-consent check and, where required, an İYS check. That way the patient is not contacted through the wrong channel or at the wrong time.

What information is kept on the patient card?

Demographics, contact details, relatives and guardians, the emergency contact, institution or insurance details and communication preferences are on the main card. Tags, alerts and controlled custom fields complete it to fit your organization.

What happens when a record is made inactive or archived?

A record can be active, inactive, archived or marked deceased. Deactivating and archiving can be reversed and are written to the audit trail, and a deceased status is marked clearly on the record.

What appears on the Patient 360 timeline?

Appointments, visits, tasks, messages, consents, documents, tests, payments and follow-ups appear in date order. Each role sees only the records it is authorized to see.

How does a prospective patient relate to the patient card?

A prospect is followed in the CRM, and when the visit happens the prospect passes the duplicate check and becomes a patient card, with the source, notes and conversation history preserved.

How are sensitive notes protected?

Sensitive notes can be segmented with a narrower scope and masked at field level. Access to them requires separate permission, and every read is written to the audit trail.

Can merged records be traced afterward?

Yes. The preview shows which field came from which record, and the merge history stores who did it, when and why, so every merge stays traceable.