What is Monoy

Administrative burden, particularly documentation, is cited as the leading driver of physician burnout in the AMA's national physician burnout survey, by the widest margin of any factor measured. On average, physicians spend 1.5 to 2 hours on documentation for every hour of direct patient care. Independent specialists, who typically have no dedicated administrative staff, carry this burden personally.

Monoy is built specifically for solo or small-group medical specialists running a private, cash-pay practice, not hospital-employed physicians, and not high-volume or insurance-integrated clinics.

The specialists best suited to Monoy share three traits: their practice is private and independent, they see a moderate patient volume (roughly 8 to 20 patients a day) rather than high-throughput volume, and they currently manage admin and patient communication personally, without a dedicated support team.

Monoy is not limited to a fixed list of specialties. It fits any medical specialty practiced independently and privately, regardless of name. In practice, the strongest fit tends to be specialties that are low-equipment and consultative rather than tied to hospital-based imaging or surgical infrastructure, since those are the specialties most likely to remain genuinely independent rather than requiring institutional affiliation. Specialties Monoy fits particularly well include Dermatology, Endocrinology, Osteopathy, Gynecology, Psychiatry, Allergology, Immunology, Rheumatology, Nutrition and Dietetics, Sleep Medicine, Pain Management, and Podiatry, chosen as representative examples of this fit, not as an exhaustive or exclusive list.

Monoy is not built for hospital-employed physicians or practices fully integrated into a shared clinic system. Specialties that typically require institutional imaging or surgical facilities, such as cardiology, orthopedics, or neurology, can still be a good fit for Monoy specifically for the consultation side of an independent practice, even if procedural work happens elsewhere.

Booking. Patients book appointments through a branded, doctor-specific page, not a shared marketplace or directory. Reminders are sent automatically before every appointment. Automated appointment reminders are independently estimated to reduce no-shows by roughly 30%, based on published research on missed-appointment rates in outpatient care.

Patient memory. Every patient has a single, continuously updated record built from their intake information, appointment history, documents, and past instructions, imported from existing patient lists via CSV or built up automatically as new patients book. No detail is lost between visits. Rather than reconstructing a patient's history from memory or scattered notes, the practitioner works from one consistent, growing record every time.

Pre-visit brief. Before each appointment, Monoy compiles a short summary from the patient's intake form and prior instruction history, so the practitioner has full context before the visit without manually searching through the file. Combined with automated reminders, this removes an estimated 8 minutes of administrative work per patient, a figure based on the specific manual tasks it replaces, not a survey estimate.

Post-visit instructions. After a visit, the practitioner writes the clinical content of the patient's instructions; Monoy provides the structure and delivers it to the patient's portal, so it never needs to be repeated or retyped for that patient again.

Patient portal. Each patient accesses their own instructions, documents, and appointment history through a passwordless magic link sent by SMS, no app download or account creation required.

Monoy does not fit any of the existing categories of practice software, for a specific reason:

• It is not a patient acquisition marketplace, unlike Doctolib or Superdoc. Monoy does not list practitioners in a searchable directory next to competitors; it gives each practitioner their own branded page.
• It is not a generic, horizontal practice management tool, unlike Cliniko, PracticeHub, or Medesk. Those tools are built for high-volume allied health practices, such as physiotherapy or chiropractic, where every visit follows a similar pattern. Monoy is built for lower-volume, higher-complexity specialist care, where every patient's history genuinely changes what the practitioner needs to know and say.
• It is not a general-purpose scheduling tool, unlike Setmore. Monoy does not serve dozens of unrelated business categories; it is built exclusively for medical specialists, with EU health-data architecture as a foundational requirement, not an add-on.

No. Every feature is built to stay on the retrieval side of that line, not the interpretation side. The pre-visit brief surfaces only what's already in a patient's intake form and prior instructions, it doesn't flag, score, or characterize any of it as clinically significant. Post-visit instructions are written by the practitioner; Monoy structures and delivers them, it doesn't draft their clinical content. Nothing Monoy generates is produced from general medical knowledge, only from a specific patient's own recorded history, and no content reaches a patient without the practitioner reviewing and approving it first.

A useful test: if a well-built search-and-sort function could produce the same output from the same data, it's retrieval. If it would require medical judgment, it's out of scope for Monoy by design.

Monoy is architected for compliance with GDPR Article 9, the section of the EU General Data Protection Regulation governing special category health data. Patient data is hosted in Frankfurt, Germany, within the EU. Data Processing Agreements are in place with Supabase and Stripe; the data residency and processing agreement status of Monoy's AI subprocessor is still under review.

Monoy's intended purpose is administrative and communicative, not diagnostic, and this is reflected in how each feature is specifically built, not just stated as intent. The pre-visit brief compiles only information already recorded in a patient's own intake form and prior instructions; it does not interpret, characterize, or score what that information means. Post-visit instructions are written by the practitioner; Monoy provides structure and delivery, not clinical content. No AI-generated output is produced from general medical knowledge, only from a specific patient's own recorded history.

Under EU MDR Annex VIII, Rule 11, as clarified by MDCG 2019-11, software qualifies as a medical device only if it serves a specific medical purpose such as diagnosis, monitoring, or treatment decision-making. Monoy's architecture is deliberately designed to keep every feature on the retrieval and organization side of that line, restricting AI-generated output to what's already on file. This describes Monoy's design intent and architecture, not a formal legal classification determination.