Een gegevensmodel voor een app voor het boeken van medische afspraken

Het boeken van een doktersafspraak via een online app is een innovatie die het hele proces vereenvoudigt. Laten we een duik nemen in het datamodel achter een app voor het boeken van afspraken.

Waarom een app gebruiken? Het maakt het voor mensen gemakkelijker om de artsen van hun keuze te vinden, door hen de professionele dossiers en patiëntbeoordelingen van de arts te laten zien. Wanneer iemand een dokter vindt die hij leuk vindt, kan hij een afspraak met hem maken zonder de app te verlaten. Een app kan artsen ook helpen de wachttijden van hun patiënten zo kort mogelijk te houden, hen te helpen hun patiënten in te plannen en hen in staat te stellen online beoordelingen van patiënten in de gaten te houden.

Vereisten voor app voor medische afspraken

Kortom, we verwachten dat onze app:

Laat patiënten zoeken naar artsen van verschillende specialisaties (huisarts, cardioloog, podotherapeut, enz.) op locatie.
Toon een geordende lijst van artsen op basis van hun jarenlange ervaring, hun afstand tot de locatie van de patiënt, hun patiëntaanbevelingen en hun beoordelingsindexen (gezamenlijke beoordeling van patiënten aan het bed, wachttijd, personeel, enz.)
Toon de kosten voor eerste en vervolgconsulten van artsen.
Vastleggen en weergeven van doktersprofielen, inclusief details over hun diploma's, certificeringen, stages en vroegere en huidige banden met ziekenhuizen.
Records over artsen van app-gebruikers. Deze beoordeling geeft een grondige preview van artsen en hun personeel aan andere app-gebruikers.

En vergeet het unieke verkoopargument van de app niet:het toont aanstaande beschikbare afspraken en laat gebruikers er een boeken .

App-vereisten categoriseren

In principe kunnen we de vereisten van de app onderverdelen in deze vier gebieden:

Doktorengegevens beheren – Artsen kunnen zich registreren en al hun gegevens invoeren.
Het beheren van de OPD (polikliniek) en kliniekgegevens van artsen – Artsen (of hun personeel) kunnen details over hun kliniek of OPD-schema en beschikbaarheid registreren.
Klant- en beoordelingsgegevens beheren – Gebruikers kunnen zich registreren en hun basisgegevens invoeren. Ze kunnen ook beoordelingen over artsen plaatsen.
Afspraken beheren – Gebruikers kunnen op basis van bepaalde criteria naar artsen zoeken.

Laten we deze gebieden afzonderlijk bekijken.

Doktorengegevens beheren

Artsen kunnen zich bij de app registreren door bepaalde verplichte gegevens in te vullen, maar de functie voor het boeken van afspraken wordt pas ingeschakeld nadat ze hun volledige profiel hebben ingevuld. Dit omvat hun kwalificaties (professionele graden, certificeringen/specialisaties en stages) en hun vroegere en huidige banden met ziekenhuizen en zorgverleners.

De onderstaande tabellen beheren deze informatie.

De doctor tabel bevat elementaire gegevens over artsen, die ze tijdens de registratie invoeren. De kolommen in deze tabel zijn:

id – Een uniek nummer dat de app aan artsen toekent tijdens de registratie.
first_name – De voornaam van de dokter.
last_name – Achternaam van de dokter.
professional_statement – Een gedetailleerd overzicht van de kwalificaties, ervaring van de arts, hun professionele motto, enz. Deze informatie wordt door de arts ingevoerd en wordt weergegeven op de profielpagina van elke arts.
practicing_from – De datum waarop de arts de geneeskunde begon te beoefenen. Dit is van groot belang, aangezien de app zijn ervaringsbeoordeling voor elke arts afleidt op basis van de informatie in deze kolom.

De specialization tabel bevat alle bestaande medische specialisaties zoals orthopedie, neuroloog, tandarts, enz. Een arts kan meer dan één specialisatie hebben; in feite is het vrij gebruikelijk dat een arts zich specialiseert in verwante gebieden. Een neuroloog kan bijvoorbeeld ook een psychiater zijn; een gynaecoloog kan een endocrinoloog zijn, enzovoort. Daarom is de doctor_specialization tabel staat een veel-op-veel relatie toe tussen de doctor en specialization tafels. De attributen in deze twee tabellen spreken voor zich.

De qualification tabel bevat details over de opleiding van artsen en professionele kwalificaties, inclusief graden, certificeringen, onderzoekspapers, seminars, permanente training, enz. Om de verschillende soorten kwalificatiedetails te vergemakkelijken, heb ik deze velden vrij algemene namen gegeven:

id – De primaire sleutel van de tabel.
doctor_id – Verwijst naar de doctor tabel en relateert de arts met de kwalificatie.
qualification_name – Betekent de naam van de graad, certificering, onderzoekspaper, enz.
institute_name – De instelling die de kwalificatie aan de arts heeft verstrekt. Dit kan een universiteit zijn, een medische instelling, een internationale vereniging van artsen, enz.
procurement_year – De datum waarop de kwalificatie is behaald of toegekend.

De hospital_affiliation tabel bevat informatie over de banden van artsen met ziekenhuizen en zorgverleners. Deze gegevens zijn alleen voor weergave op het profiel van een arts en hebben geen betekenis in de functie voor het boeken van afspraken. OPD (polikliniek) gegevens worden apart ingevuld en komen later in dit artikel aan de orde.

De kolommen van deze tabel zijn:

id – De primaire sleutel van de tabel.
doctor_id – Verwijst naar de doctor tabel en koppelt de arts aan het aangesloten ziekenhuis.
hospital_name – De naam van het aangesloten ziekenhuis.
city and country – De stad en het land waar het ziekenhuis is gevestigd. Deze adreskolommen spelen geen rol in de zoekfunctie van de app; ze zijn alleen voor weergave op het profiel van de arts.
start_date – Toen de samenwerking van de arts met het ziekenhuis begon.
end_date – Wanneer de aansluiting eindigde. Het is nullable omdat huidige lidmaatschappen geen einddatum hebben.

De OPD/kliniekgegevens van artsen beheren

De informatie in deze sectie wordt ingevoerd door artsen (of hun personeel) en speelt een belangrijke rol in de zoek- en boekingsfunctionaliteit van de app.

Het office tabel bevat informatie over de polikliniek van de ziekenhuizen waar artsen zijn aangesloten, evenals hun eigen klinieken (d.w.z. kantoren of operaties). De kolommen in deze tabel zijn:

id – De primaire sleutel van deze tabel.
doctor_id – Verwijst naar de doctor tabel en geeft de relevante arts aan.
hospital_affiliation_id –Betekent het ziekenhuis waar de arts beschikbaar is voor OPD. Aangezien de kolom van toepassing is op OPD's maar niet op klinieken, is deze nullable.
time_slot_per_client_in_min – Slaat een hoeveelheid tijd (in minuten) op die is toegewezen voor consulten. Het aantal minuten wordt door artsen ingevuld op basis van hun ervaring. Deze kolom helpt de app bij het bepalen van het volgende beschikbare slot. Houd er rekening mee dat dit aantal geen garantie is voor de duur van de afspraak, maar het helpt de wachttijden voor patiënten te minimaliseren als ze de app gebruiken om een afspraak te boeken.
first_consultation_fee – Het honorarium dat de arts voor een eerste bezoek in rekening brengt. Dit lijkt misschien onbelangrijk, maar het is erg belangrijk voor de zoekfunctie; vergoeding is een veelgebruikt filtercriterium.
followup_consultation_fee – Veel artsen rekenen minder voor een vervolgbezoek dan voor een eerste consult. In deze kolom worden de kosten voor vervolgconsulten opgeslagen.
street_address – Het adres van de OPD of kliniek van het ziekenhuis.
city , state en country –De stad, de staat en het land waar het ziekenhuis of de kliniek zich bevindt.
zip – De postcode waar de kliniek of het ziekenhuis is gevestigd. Vaak zoeken mensen naar artsen in nabijgelegen gebieden met behulp van een postcode, dus dit veld is belangrijk voor de zoekfunctie van de app.

Waarom is er een aparte "kantoor"-tabel wanneer OPD-details gemakkelijk kunnen worden gevolgd in de "hospital_affiliation"-tabel?

Drie redenen:

Een arts kan voor één aspect van hun werk (d.w.z. operaties) aan een ziekenhuis zijn verbonden, maar niet voor andere (d.w.z. het zien van inlooppatiënten). We kunnen dergelijke connecties verliezen als we proberen om kantoorgegevens te behouden in de hospital_affiliation alleen tafel.
Veel artsen zijn niet aangesloten bij ziekenhuizen, maar hebben hun eigen klinieken of kantoren. We moeten ook informatie voor deze artsen opslaan.
Een arts kan meerdere kantoren hebben op verschillende locaties, of kan op verschillende afdelingen van een ziekenhuis werken. Als de arts slechts aan één ziekenhuislocatie is verbonden, kunnen we gegevens kwijtraken. Daarom houden we aparte adresgegevens bij.

De office_doctor_availability tabel slaat de OPD/kliniekbeschikbaarheid van artsen op in termen van tijdvakken (zeg 2 uur 's ochtends en 4 uur' s avonds). Het is vrij gebruikelijk om de dag op deze manier op te splitsen, dus het is logisch om een extra tafel te hebben om beschikbaarheidsslots op te slaan. Bovendien kunnen artsen meer dan één OPD-ploeg werken. De kolommen voor deze tabel zijn:

id – De primaire sleutel van de tabel.
office_id – Verwijst naar de tabel "kantoor".
day_of_week – De dag van de week, d.w.z. maandag, dinsdag, enz. Hierdoor kunnen artsen verschillende beschikbaarheid hebben voor verschillende dagen (bijvoorbeeld weekends versus weekdagen).
start_time – Als de dokter klaar is voor de eerste patiënt.
end_time – Wanneer de laatste afspraak of dienst is gepland om te eindigen.
is_available – Hiermee kunnen artsen hun beschikbaarheid voor bepaalde dagen of tijdvakken markeren. Deze kolom wordt standaard geïnitialiseerd met een 'Y' en wordt bijgewerkt naar een 'N' wanneer artsen hun onbeschikbaarheid markeren.
reason_of_unavailablity – Veel artsen geven er de voorkeur aan om te vertellen waarom ze niet beschikbaar zijn of een afspraak moeten annuleren. Dit helpt om een transparante relatie op te bouwen tussen artsen en hun patiënten. Omdat het optioneel is, heb ik dit als een nullable kolom gehouden.

De in_network_insurance tabel slaat verzekeringsinformatie op. In veel landen zijn medische diensten erg duur en is een ziektekostenverzekering verplicht. In dergelijke gevallen bevat deze tabel de details over welke verzekeringsmaatschappijen volledig worden geaccepteerd in de OPD of kliniek van het ziekenhuis.

Klant- en beoordelingsgegevens beheren

Voor een patiënt is het registreren voor de app heel weinig informatie nodig. Vanaf nu gebruik ik 'klant' in plaats van 'gebruiker' of 'patiënt'.

Het client_account table slaat basisgegevens op voor klanten. Deze gegevens worden vastgelegd op het moment van registratie. De kolommen in deze tabel zijn:

id – Een uniek nummer toegewezen aan elke klant.
first_name – De voornaam van de klant.
last_name – De achternaam van de klant.
contact_number – Het telefoonnummer van de klant, bij voorkeur een mobiel nummer, waarnaar afspraakinformatie kan worden gestuurd. Dit is ook het nummer waarop de cliënt kan worden gecontacteerd door het personeel van de dokterspraktijk.
email – Het e-mailadres van de klant. De app kan afspraakherinneringen naar klanten sturen.

De client_review table biedt niet alleen feedback (d.w.z. klantbeoordelingen) voor artsen, maar helpt potentiële klanten ook om artsen te kiezen. Het is een integraal onderdeel van deze app. Kolommen voor deze tabel zijn:

id – De primaire sleutel van deze tabel.
user_account_id – Geeft aan welke gebruiker de recensie indient.
doctor_id – De arts die wordt beoordeeld.
is_review_anonymous – Of de naam van de klant wel of niet bij de recensie wordt gepubliceerd. Dit is een beveiligingsfunctie voor klanten.
wait_time_rating – Deze cijferkolom bevat een beoordeling van 1 (slechtste) tot 10 (beste). Het weerspiegelt de mening van de cliënt over hoe lang ze hebben gewacht om de dokter te zien.
bedside_manner_rating -Slaat de mening van de cliënt op over de manier waarop de arts aan het bed ligt (d.w.z. of de arts aardig, meelevend is, goed communiceert, enz.)
overall_rating – Beoordeling door de cliënt van hun algemene ervaring met de arts.
review – Klanten kunnen hier hun gedetailleerde feedback geven.
is_doctor_recommended – In deze indicatorkolom staat of de cliënt de arts zou aanbevelen.
review_date – Wanneer de beoordeling is ingediend.

Afspraken beheren

Dit gedeelte is de belangrijkste USP (Unique Selling Point) voor deze app, omdat klanten hiermee de beschikbaarheid van verschillende artsen kunnen controleren en een afspraak kunnen maken.

De appointment tafel bevat afspraakdetails voor klanten. De kolommen zijn onder meer:

id – Aan elke afspraak wordt een uniek nummer toegekend. Er wordt elders naar dit nummer verwezen.
user_account_id – Welke klant de afspraak boekt.
office_id – Geeft aan welke arts en welk ziekenhuis OPD of kliniek bij de afspraak betrokken is.
probable_start_time – Dit is een tijdstempelkolom die de vermoedelijke starttijd van de afspraak bevat. De starttijden van medische afspraken zijn meestal waarschijnlijk in plaats van absoluut.
actual_end_time – De werkelijke eindtijd van het consult. In eerste instantie is deze kolom leeg, omdat veel factoren van invloed kunnen zijn op het beëindigen van een afspraak. Daarom is dit een kolom met nullwaarden.
appointment_status_id – Hier wordt naar verwezen vanuit de appointment_status tabel, en het geeft de huidige status van de afspraak aan. Mogelijke waarden voor status zijn "actief", "geannuleerd" en "voltooid". Aanvankelijk zou de status "actief" zijn. Het zou "compleet" worden zodra de afspraak is gemaakt. Het wordt "geannuleerd" als de klant zijn afspraak annuleert.
appointment_taken_date – De datum waarop de afspraak is gemaakt.
app_booking_channel_id – Het kanaal waarlangs een afspraak is geboekt. Er zijn meerdere kanalen waarlangs afspraken worden gemaakt:via de app, door het ziekenhuis te bellen, door de dokter of hun kantoor te bellen, enz.

Bekijk het volledige gegevensmodel

De zoekfunctie in actie

Laten we een oogarts zoeken in de 63101 postcode. Zoekresultaten moeten worden gerangschikt volgens de volgende criteria:

Meeste ervaring
Hoogste klantaanbeveling
Laagste initiële consultkosten

Hier is de code:

SELECT doctor_name, hospital_name, practicing_from, first_consultation_fee, recomm_count FROM
(SELECT d.doctor_id, d.first_name || ‘ ‘ || d.last_name as doctor_name, 
ha.hospital_name, d.practicing_from, o.first_consultation_fee 
FROM office o, doctor d, doctor_specialization ds, specialization s, hospital_affiliation ha 
WHERE o.doctor_id = d.id AND d.id = ds.doctor_id 
AND s.id = ds.specialization_id AND s.specialization_name = ‘Ophthalmologist’
AND o.hospital_affiliation_id = ha.id (+)
AND o.zip = ‘63101’) doctor_detail, 
(SELECT doctor_id, count(1) as recomm_count FROM client_review 
WHERE is_doctor_recommended = ‘Y’ GROUP BY doctor_id) review_count
WHERE doctor_detail.doctor_id = review_count.doctor_id
ORDER BY doctor_detail.practicing_from DESC, review_count.recomm_count DESC doctor_detail.first_consultation_fee ASC;

Wat zou je toevoegen?

Wat kan er nog meer worden toegevoegd aan deze app en dit datamodel? Deel uw mening in de opmerkingen.