Skip to content

Create an account

Sign in
HekimBis home

Patient registration software builds each patient's file correctly

The job of patient registration software is not typing names; it is building the right file for a person in your clinic. Opening the same patient twice, filing someone else's result in a file, or recording a foreign patient in a field their ID does not fit are mistakes that are hard to fix later. HekimBis builds the registration screen to prevent them from the start.

Try it free for 7 daysRequest a demo

What is on the registration screen

The registration screen is arranged in tabs. A front-desk employee can open a new patient quickly, and the details are completed when needed.

  • Identity and contact

    Name, surname, date of birth, gender, ID document type and number, phone, e-mail and address. The ID number can be masked on screen; removing the mask needs permission and a reason, and is written to the audit trail.

  • Guardian and emergency contact

    The patient's parent or guardian, the person to call in an emergency and the type of relationship. For children or patients who need a guardian, who may approve which action is kept together with the relationship.

  • Institution and insurance

    If the patient is covered by an institution or private insurer, the information is tied to the card and reflected in the payment flow. Corporate health agreements are supported with a separate specialty profile.

  • Preferences and tags

    Preferred contact channel, quiet hours, language; tags defined by the clinic and alerts the team should notice. The tag system is controlled: defined values are used instead of free text.

  • Timeline

    In the Patient 360 view, appointments, exams, tasks, messages, consents, documents, tests, payments and follow-up stand in one sequence. See Patient management and Patient 360 for details.

Record status is managed too: active, inactive, archived and deceased. So that nothing is lost by mistake, records are not deleted in a way that is hard to recover; a record is archived, and the reason and date are tracked.

Registration speed matters as much as quality; the front desk does not want to fill in a long form with a patient waiting in line. In HekimBis registration has two stages. In the first stage only the minimum fields that identify the patient, meaning name, surname, date of birth and contact, are entered and the patient is taken to the appointment or exam. The details, meaning relatives, institution, preferences and custom fields, are completed later or through the pre-visit form the patient fills in on the portal. When patients enter their own details before the appointment, the front desk only verifies them, and typos and missing fields drop. For a patient arriving by kiosk or QR code, the identity is verified once and the card is updated. The minimum-data principle applies here too: a field that is not needed in the first stage is not asked for until it is.

How duplicate records are prevented

A duplicate record is a problem that builds up silently in a clinic. For a patient split across two files, the allergy is written in one, the debt sits in the other and the test result waits in a third record. HekimBis handles this problem in three stages.

The cost of a duplicate is not only a scattered file. The same patient gets two reminders, the debt is split across two accounts, a critical allergy marker stays in only one of them, and when answering a data subject request under KVKK, not every record may be found. A check at registration is therefore far cheaper than cleaning up afterwards.

A medical secretary at a desk comparing two closed patient folders side by side
  1. A warning at registrationWhile a new patient is entered, the system looks at name, date of birth and contact details, finds candidate matches and shows them to the front desk. Most duplicates are prevented here, before the patient card is opened.
  2. Human confirmationA candidate match is not merged automatically. The system shows the two cards in a field-by-field comparison preview, and authorized staff decide whether they are the same person. Two different patients with similar names, such as a mother and daughter or siblings, are not merged by mistake at this step; a not the same person decision is marked and the same pair does not raise the warning again.
  3. Traceable mergeIf the decision is the same person, the two cards merge into one timeline. Who made the merge, when and why is recorded. If a wrong merge is noticed, it is undone through the merge record.

The same logic works during data migration: if the list from the old program contains duplicates, a matching decision is requested during import. See Data migration. Patient identity is scoped to the organization; in a multi-branch structure the same patient stays one identity across branches, while access to another branch's clinical record is opened separately through branch membership and care relationship.

Record06End

Trail: who, when, why

  • The process is complete here.
  • If a wrong merge is noticed06a Wrong merge noticed: reversed from the merge record
6 / 12

All steps

  1. 01 New registration entered (name, date of birth, contact) (Front desk)
  2. 02 Candidate match found (System)
  3. 03 Comparison preview, field by field (System)
  4. 04 Human decision: same person? (Authorised staff)
  5. 05 Merge: two cards, one timeline (Record)
  6. 06 Trail: who, when, why (Record)

Alternative path from 04 Human decision: same person?; it returns to the main flow at 06 Trail: who, when, why.

  1. 04a Not the same person: stays separate, decision marked (Authorised staff)

Alternative path from 06 Trail: who, when, why; it returns to the main flow at 02 Candidate match found.

  1. 06a Wrong merge noticed: reversed from the merge record (Authorised staff)

06 Trail: who, when, why

Foreign patients, children and patients who need a guardian

If a registration program is built to work only with the Turkish ID number, foreign patients, children and patients who need a guardian are constant exceptions. In HekimBis these three cases are the normal flow.

A parent looking at a phone in a paediatric waiting room, with blurred toys behind.

  • Foreign patient

    For passports and supported foreign identity documents, the document type, number, issuing country, validity and verification record are kept; a Turkish ID number is not requested from a foreign patient. Preferred language, phone country code, time zone and currency are stored on the patient card and used in reminder and quote flows. See Health tourism for the international patient flow and Medical tourism CRM for the CRM side.

  • Child and parent

    The parent of a child patient appears on the card with the relationship type and authority. Consent and information are addressed to the parent; portal access is opened as a dependent account with proof of relationship, duration and scope.

  • Guardian and emergency contact

    For patients who need a guardian, authority to act and authority to be contacted are defined separately. The emergency contact is kept only for contact, without permission to access the clinical record.

The shared rule of these three cases is that on whose behalf what can be done must be clear in the record. Otherwise responsibility for consent and contact becomes unclear. See KVKK-compliant patient tracking for how the privacy notice and explicit consent are kept as separate records.

Registration quality can be measured. The clinic manager or compliance officer can follow the number of patients with missing contact details, the frequency of merges, not the same person decisions and inactive or archived records in a report. More frequent merges usually point to a process that has broken down, for example the same patient being recorded separately by phone and through the portal; a short rule clarification with the front desk is often enough.

The visibility of registration fields should be reviewed too: the front desk sees identity and contact details but does not need to see the clinical note, and when the ID number is masked the front desk needs only the last digits. These settings start with role templates and are customized in the Pro and Clinic packages. See Roles and permissions.

What comes after registration

Registration is the start of the patient journey; its value is measured by how well it connects to the next steps.

Appointment
An appointment is given to the patient at registration, or the record is created automatically after an online appointment. See Appointments and calendar and Doctor appointment system.
Forms and consent
The pre-visit form, privacy notice, explicit consent and procedure consent are separate records tied to the patient card. See Forms, consent and documents.
Messaging
Reminders and information go out according to the patient's preference and permission status. See Patient messaging.
Portal
Patients see their own details, request corrections or printouts, and open the results their physician has published. See Patient portal.
Lead
A first contact by phone or from the web is tracked first as a lead and becomes a patient record when the visit happens. See Lead CRM.
The general umbrella
See Patient tracking software for the system in which all of these work together.

There is a practical test to apply when choosing registration software: try entering the same patient twice with different spellings and see whether the system warns you. Then enter two people with the same name and surname but different dates of birth and check that the system does not merge them by mistake. Register a foreign patient with a passport, a child with no ID number and a patient who needs a guardian. Finally, archive a patient and bring them back; see that the record was not deleted, only its status changed. This five-minute trial shows how well the registration software stands up to real life, and it can be done with sample data in the HekimBis trial workspace.

Every field entered at registration should have an owner and a purpose. The clinic decides which fields are mandatory and which are optional; mandatory fields exist to complete the record, and optional ones to improve the patient experience. A field that is never filled in is a field that slows the form down and should be reviewed.

Frequently asked questions

Is there a difference between patient registration software and patient tracking software?

Registration software focuses on identity, contact and setting up the file; tracking software also covers appointments, exams, tests and payments. In HekimBis they are the same product.

How are duplicate records prevented?

The system finds candidate matches and warns at registration; the decision belongs to authorized staff. A warning at registration and a traceable merge make the duplicate problem smaller, and a wrong merge can be undone.

Can I register a foreign patient without a Turkish ID number?

Yes. For passports and supported foreign identity documents, the document type, number, country and validity are kept.

Can I import patients from my old program?

Patients are imported from CSV and Excel files with a field-mapping preview and a trial import; a matching decision is requested for duplicates. Real data import happens after production activation. See Data migration.

Who sees identity and contact details?

Visibility follows role, branch and care relationship; the ID number can be masked, and every sensitive view is written to the audit trail. See Security.

How does a child's parent appear in the record?

The parent is kept on the card with the relationship type and authority. Consent and information are addressed to the parent; portal access is opened as a dependent account with proof of relationship, duration and scope.

Related pages

Features

Specialties

Solutions and process

Software guides