En datamodel for en lægebestillingsapp

At bestille en lægetid ved hjælp af en online app er en nyskabelse, der forenkler hele processen. Lad os dykke ned i datamodellen bag en aftalebestillingsapp.

Hvorfor bruge en app? Det gør det nemmere for folk at finde de læger, de selv vælger, og lader dem se lægens journaler og patientanmeldelser. Når nogen finder en læge, de kan lide, kan de bestille en tid hos dem uden at forlade appen. En app kan også hjælpe læger med at holde deres patienters ventetider så korte som muligt, hjælpe dem med at planlægge deres patienter og sætte dem i stand til at holde øje med patienternes online anmeldelser.

App Krav til lægeaftaler

Kort sagt forventer vi, at vores app vil:

Tillad patienter at søge efter læger med forskellige specialer (familielæge, kardiolog, fodterapeut osv.) efter placering.
Vis en ordnet liste over læger baseret på deres års erfaring, deres afstand fra patientens placering, deres patientanbefalinger og deres gennemgangsindekser (patienternes samlede vurdering af sengestil, ventetid, personale osv.)
Vis lægernes indledende og opfølgende konsultationsgebyrer.
Fang og vis lægers profiler, herunder detaljer om deres grader, certificeringer, praktikophold og tidligere og nuværende tilknytninger til hospitaler.
Optag anmeldelser om læger fra appbrugere. Denne anmeldelse giver andre appbrugere en grundig forhåndsvisning af læger og deres personale.

Og glem ikke appens unikke salgsargument:viser kommende ledige aftaler og giver brugerne mulighed for at booke en .

Kategorisering af appkrav

Grundlæggende kan vi opdele appens krav i disse fire områder:

Administration af lægers data – Læger kan registrere sig og indtaste alle deres detaljer.
Administration af lægers OPD (ambulatorium) og klinikdetaljer – Læger (eller deres personale) kan logge detaljer om deres klinik eller OPD tidsplan og tilgængelighed.
Administration af klient- og anmeldelsesdata – Brugere kan registrere sig og indtaste deres grundlæggende detaljer. De kan også skrive anmeldelser om læger.
Håndtering af aftaler – Brugere kan søge efter læger ud fra bestemte kriterier.

Lad os se på disse områder individuelt.

Administration af lægers data

Læger kan registrere sig med appen ved at udfylde visse obligatoriske detaljer, men funktionen til at bestille tid er først aktiveret, når de har fuldført deres fulde profil. Dette inkluderer deres kvalifikationer (professionelle grader, certificeringer/specialiseringer og praktikophold) og deres tidligere og nuværende tilknytning til hospitaler og udbydere af sundhedsydelser.

Tabellerne nedenfor administrerer disse oplysninger.

doctor tabel gemmer elementære oplysninger om læger, som de indtaster under registreringen. Kolonnerne i denne tabel er:

id – Et unikt nummer, som appen tildeler læger under registreringen.
first_name – Lægens fornavn.
last_name – Lægens efternavn.
professional_statement – En detaljeret oversigt over lægens kvalifikationer, erfaring, deres faglige motto osv. Disse oplysninger indtastes af lægen og vises på hver læges profilside.
practicing_from – Den dato, hvor lægen begyndte at praktisere medicin. Dette har dyb betydning, da appen vil udlede sin erfaringsvurdering for hver læge baseret på oplysningerne i denne kolonne.

specialization tabel indeholder alle eksisterende medicinske specialer som ortopæd, neurolog, tandlæge osv. En læge kan have mere end én specialisering; faktisk er det ret almindeligt, at en læge specialiserer sig i relaterede områder. En neurolog kan for eksempel også være en psykiater; en gynækolog kan være en endokrinolog og så videre. Derfor er doctor_specialization tabel muliggør et mange-til-mange forhold mellem doctor og specialization tabeller. Attributterne på disse to tabeller er selvforklarende.

qualification tabel gemmer detaljer om lægers uddannelse og faglige kvalifikationer, herunder grader, certificeringer, forskningsartikler, seminarer, løbende uddannelse osv. For at lette de forskellige typer af kvalifikationsdetaljer har jeg givet disse felter ret generiske navne:

id – Tabellens primære nøgle.
doctor_id – Henviser til doctor tabel og relaterer lægen til kvalifikationen.
qualification_name – Angiver navnet på graden, certificeringen, forskningspapiret osv.
institute_name – Den institution, der har udstedt kvalifikationen til lægen. Dette kan være et universitet, en medicinsk institution, en international sammenslutning af læger osv.
procurement_year – Datoen for, hvornår kvalifikationen blev opnået eller tildelt.

hospital_affiliation tabel opbevarer oplysninger om lægers tilknytning til hospitaler og sundhedsydelser. Disse data er kun til visning på en læges profil og har ingen betydning i tidsbestillingsfunktionen. OPD-oplysninger (ambulatorium) indtastes separat og vil blive behandlet senere i denne artikel.

Denne tabels kolonner er:

id – Tabellens primære nøgle.
doctor_id – Henviser til doctor tabel og forbinder lægen med det tilknyttede hospital.
hospital_name – Det tilknyttede hospitals navn.
city and country – Byen og landet, hvor hospitalet ligger. Disse adressekolonner spiller ingen rolle i appens søgefunktion; de er kun til visning på lægens profil.
start_date – Da lægens tilknytning til hospitalet begyndte.
end_date – Hvornår tilknytningen ophørte. Den er nullbar, fordi nuværende tilknytninger ikke vil have en slutdato.

Administration af lægers OPD/klinikdetaljer

Oplysningerne i dette afsnit indtastes af læger (eller deres personale) og spiller en væsentlig rolle i appens søge- og bookingfunktioner.

office tabel indeholder oplysninger om ambulatoriet på de sygehuse, læger er tilknyttet samt deres egne klinikker (dvs. kontorer eller operationer). Kolonnerne i denne tabel er:

id – Den primære nøgle i denne tabel.
doctor_id – Henviser til doctor tabel og angiver den relevante læge.
hospital_affiliation_id –Betegner det hospital, hvor lægen er til rådighed for OPD. Da kolonnen gælder for OPD'er, men ikke klinikker, er den nullbar.
time_slot_per_client_in_min – Gemmer en mængde tid (i minutter) afsat til konsultationer. Antallet af minutter indtastes af læger baseret på deres erfaring. Denne kolonne hjælper appen med at bestemme den næste ledige plads. Bemærk, at dette nummer ikke er en garanti for aftalens længde, men det hjælper med at minimere patientens ventetider, hvis de bruger appen til at bestille en tid.
first_consultation_fee – Det gebyr, lægen opkræver for et første besøg. Dette kan virke ligegyldigt, men det er meget vigtigt for søgefunktionen; gebyr er et meget almindeligt filterkriterium.
followup_consultation_fee – Mange læger tager mindre for et opfølgende besøg end for en indledende konsultation. Denne kolonne gemmer omkostningerne til opfølgende konsultation.
street_address – Adressen på hospitalets OPD eller klinik.
city , state og country – Den by, stat og land, hvor hospitalet eller klinikken er placeret.
zip – Det postnummer, hvor klinikken eller hospitalet ligger. Ofte søger folk efter læger i nærliggende områder ved hjælp af et postnummer, så dette felt vil være vigtigt for appens søgefunktion.

Hvorfor er der en separat "kontor"-tabel, når OPD-detaljer nemt kan spores i "hospital_affiliation"-tabellen?

Tre grunde:

En læge kan være tilknyttet et hospital for et aspekt af deres arbejde (dvs. at udføre operationer), men ikke for andre (dvs. at se walk-in patienter). Vi kan miste sådanne tilknytninger, hvis vi forsøger at vedligeholde kontoroplysninger i hospital_affiliation kun tabel.
Mange læger er ikke tilknyttet hospitaler, men har deres egne klinikker eller kontorer. Vi skal også gemme oplysninger for disse læger.
En læge kan have flere kontorer forskellige steder eller arbejde på flere afdelinger af et hospital. Hvis lægen kun vises som værende tilknyttet ét hospitalssted, kan vi miste nogle oplysninger. Det er grunden til, at vi opretholder separate adresseoplysninger.

office_doctor_availability tabel gemmer lægernes OPD/kliniktilgængelighed i form af tidsintervaller (f.eks. 2 timer om morgenen og 4 timer om aftenen). Det er ret almindeligt at dele dagen op på denne måde, så det er fornuftigt at have et ekstra bord til at gemme ledige pladser. Plus, læger kan arbejde mere end ét OPD-skift. Kolonnerne for denne tabel er:

id – Tabellens primære nøgle.
office_id – Henviser til "kontor"-tabellen.
day_of_week – Ugedagen, dvs. mandag, tirsdag osv. Dette gør det muligt for læger at have forskellige muligheder for forskellige dage (f.eks. weekender vs. hverdage).
start_time – Når lægen er klar til den første patient.
end_time – Når den endelige aftale eller vagt er planlagt til at slutte.
is_available – Giver læger mulighed for at markere deres tilgængelighed for bestemte dage eller tidsintervaller. Denne kolonne initialiseres med et "Y" som standard og opdateres til et "N", når læger markerer deres utilgængelighed.
reason_of_unavailablity – Mange læger foretrækker at oplyse, hvorfor de er utilgængelige eller må aflyse en tid. Dette er med til at opbygge et gennemsigtigt forhold mellem læger og deres patienter. Da det er valgfrit, har jeg beholdt denne som nullbar kolonne.

in_network_insurance tabel gemmer forsikringsoplysninger. I mange lande er lægetjenester meget dyre, og sundhedsforsikring er obligatorisk. I sådanne tilfælde indeholder denne tabel detaljerne om, hvilke forsikringsselskaber der fuldt ud accepteres på hospitalets OPD eller klinik.

Administration af klient- og anmeldelsesdata

For en patient kræver tilmelding til appen meget lidt information. Herfra vil jeg bruge 'klient' frem for 'bruger' eller 'patient'.

client_account tabel gemmer grundlæggende detaljer for kunder. Disse oplysninger registreres på tidspunktet for registrering. Kolonnerne i denne tabel er:

id – Et unikt nummer tildelt hver klient.
first_name – Klientens fornavn.
last_name – Klientens efternavn.
contact_number – Kundens telefonnummer, gerne et mobilnummer, som aftaleoplysninger kan sendes til. Dette er også det nummer, hvor klienten kan kontaktes af lægens kontorpersonale.
email – Kundens e-mailadresse. Appen sender muligvis påmindelser om aftaler til kunder.

client_review tabel giver ikke kun feedback (dvs. klientanmeldelser) til læger, men den hjælper også potentielle klienter med at vælge læger. Det er en integreret del af denne app. Kolonner for denne tabel er:

id – Den primære nøgle i denne tabel.
user_account_id – Angiver, hvilken bruger der indsender anmeldelsen.
doctor_id – Lægen bliver gennemgået.
is_review_anonymous – Om kundens navn vil blive offentliggjort sammen med anmeldelsen eller ej. Dette er en sikkerhedsfunktion for klienter.
wait_time_rating – Denne talkolonne har en vurdering fra 1 (dårligst) til 10 (bedst). Det afspejler klientens mening om, hvor længe de ventede på at se lægen.
bedside_manner_rating – Gemmer klientens mening om lægens måde at være på sengen (dvs. hvis lægen er venlig, medfølende, kommunikerer godt osv.)
overall_rating – Kundens vurdering af deres generelle oplevelse med lægen.
review – Kunder kan give deres detaljerede feedback her.
is_doctor_recommended – Denne indikatorkolonne angiver, om klienten vil anbefale lægen.
review_date – Hvornår anmeldelsen blev indsendt.

Håndtering af aftaler

Denne sektion er den førende USP (Unique Selling Point) for denne app, da den giver kunderne mulighed for at tjekke tilgængeligheden af forskellige læger og bestille en tid.

appointment tabel indeholder aftaledetaljer for kunder. Dens kolonner omfatter:

id – Hver aftale tildeles et unikt nummer. Dette nummer er refereret andetsteds.
user_account_id – Hvilken kunde bestiller tid.
office_id – Angiver hvilken læge og hvilket hospital OPD eller klinik der er involveret i udnævnelsen.
probable_start_time – Dette er en tidsstempelkolonne, der indeholder det sandsynlige starttidspunkt for aftalen. Lægeaftalers starttider er normalt sandsynlige snarere end absolutte.
actual_end_time – Det faktiske sluttidspunkt for konsultationen. Til at begynde med er denne kolonne tom, da mange faktorer kan påvirke, hvornår en aftale slutter. Derfor er dette en nullbar kolonne.
appointment_status_id – Dette er refereret fra appointment_status tabel, og det angiver den aktuelle status for aftalen. Mulige værdier for status er "aktiv", "annulleret" og "fuldført". Til at begynde med ville status være "aktiv". Det ville blive "fuldstændigt", når udnævnelsen er gennemført. Det vil blive "aflyst", hvis klienten aflyser sin aftale.
appointment_taken_date – Datoen for udnævnelsen.
app_booking_channel_id – Kanalen, hvorigennem en tid blev bestilt. Der er flere kanaler, hvorigennem aftaler laves:gennem appen, ved at ringe til hospitalet, ved at ringe til lægen eller deres kontor osv.

Se den komplette datamodel

Søgefunktionen i aktion

Lad os søge efter en øjenlæge i postnummeret 63101. Søgeresultater skal sorteres efter følgende kriterier:

Mest erfaring
Højeste kundeanbefalingsbedømmelse
Laveste indledende konsultationsgebyr

Her er koden:

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;

Hvad vil du tilføje?

Hvad kan der ellers tilføjes til denne app og denne datamodel? Del dine synspunkter i kommentarerne.