Medical Centre CRM
When each specialty has a different appointment length, room need and price tariff but reception works from a single calendar, the referred patient gets lost on the way, the test result reaches the doctor late, and the invoice is issued to the wrong specialty.
A referral is a job with its own record, tied to the patient card; the history and the test result are seen from the same card in the new specialty, and open referrals stay on the list.
What we set up, and how
- Set up a separate calendar for each doctor; define the specialty rules (cardiology 30 min, internal medicine 20 min) and the room assignment, and let clashes and overloading be prevented by the rule set during setup
- Run cross-specialty referral inside the CRM on a single record; because the patient card, the medical history and the test results are tied to the same record, they appear on the screen of the physician in the new specialty, and let incomplete referrals stay open on the list
- Upload laboratory and imaging results to the patient card as PDF and image files and open them from the doctor's screen
- Issue the invoice to the right specialty, with each specialty's own price list, package and contracted institution rate
- Gather the patient's appointment, report and invoice history on a single card; tie a new incoming request to the same record and assign it to its owner
| Multi-Specialty Doctor Calendar | Every doctor carries their own calendar; the appointment length and the room are defined in the specialty's fields, and the clash rule is set up during setup. |
|---|---|
| Referral Within and Across Specialties | A referral is a record; because it is tied to the patient card, the medical history and the test result are seen from the same card in the new specialty, and referrals that are not closed stay on the list. |
| Laboratory and Imaging Results | The result file is an attachment on the patient record and is opened from the doctor's screen. We build the connection to the device, LIS, PACS or RIS side; there is no out-of-the-box module, the connection is built specifically for your project over the REST API, and until it is built the results are added with an import file or by hand. |
| Specialty-Based Invoicing | Each specialty's price list and contracted institution rate are defined separately; because the procedure record carries a specialty field, the invoice is produced from the right list. |
| Patient Card History | The appointment, report and invoice history sits on the patient card; a new incoming request is tied to the same record and assigned within the team according to the rule you define. |
What separates a medical centre from a single-specialty clinic is not the number of doctors but the fact that the patient changes specialty within the same day. If the medical history and the test of a patient sent from internal medicine to cardiology do not travel with them, the second physician asks the same questions from the beginning and sometimes orders the same test a second time. The shared reception and the shared laboratory try to carry this traffic by hand.
In Rapitek CRM a referral is a job with its own record and stays in follow-up until it is closed. We build the connection to the laboratory and imaging side; there is no out-of-the-box module: the result file sits as an attachment on the patient record and is opened from the doctor's screen; if a connection is wanted, it is built within the scope of the project over the REST API, OAuth2, webhooks and import/export, and its scope and cost are shared in writing in the discovery call. Because the contracted institution is tagged on the patient card, the institution's tariff is reflected in the invoice; the connection to the SGK MEDULA side is also built specifically for the project, there is no out-of-the-box module, and authorisation information is entered with an import file or by hand until the connection is built.
