En datamodell för en app för bokning av läkarbesök

Att boka ett läkarbesök med en onlineapp är en innovation som förenklar hela processen. Låt oss dyka in i datamodellen bakom en mötesbokningsapp.

Varför använda en app? Det gör det enklare för människor att hitta de läkare de väljer och låter dem se läkarens journaler och patientrecensioner. När någon hittar en läkare de tycker om kan de boka tid hos dem utan att lämna appen. En app kan också hjälpa läkare att hålla sina patienters väntetider så korta som möjligt, hjälpa dem att schemalägga sina patienter och göra det möjligt för dem att hålla ett öga på patienters onlinerecensioner.

Appkrav för medicinska möten

Kortfattat förväntar vi oss att vår app kommer:

Tillåt patienter att söka efter läkare med olika specialiteter (husläkare, kardiolog, fotterapeut, etc.) efter plats.
Visa en ordnad lista över läkare baserat på deras många års erfarenhet, deras avstånd från patientens plats, deras patientrekommendationer och deras granskningsindex (patienternas samlade betyg på sängläge, väntetid, personal, etc.)
Visa läkarnas initiala och uppföljande konsultavgifter.
Fånga och visa läkares profiler, inklusive information om deras examina, certifieringar, praktikplatser och tidigare och nuvarande anknytningar till sjukhus.
Spela in recensioner om läkare från appanvändare. Den här recensionen ger andra appanvändare en förhandsgranskning av läkare och deras personal.

Och glöm inte appens unika försäljningsargument:visa kommande tillgängliga möten och låta användare boka en .

Kategorisering av appkrav

I grund och botten kan vi dela upp appens krav i dessa fyra områden:

Hantera läkares data – Läkare kan registrera sig och ange alla sina uppgifter.
Hantera läkares OPD (poliklinik) och klinikdetaljer – Läkare (eller deras personal) kan logga detaljer om sin klinik eller OPD-schema och tillgänglighet.
Hantera klient- och recensionsdata – Användare kan registrera sig och ange sina grundläggande uppgifter. De kan också lägga upp recensioner om läkare.
Hantera möten – Användare kan söka efter läkare baserat på vissa kriterier.

Låt oss titta på dessa områden individuellt.

Hantera läkares data

Läkare kan registrera sig i appen genom att fylla i vissa obligatoriska uppgifter, men bokningsfunktionen för möten är aktiverad först efter att de har slutfört sin fullständiga profil. Detta inkluderar deras kvalifikationer (yrkesexamina, certifieringar/specialiseringar och praktikplatser) och deras tidigare och nuvarande anknytning till sjukhus och vårdgivare.

Tabellerna nedan hanterar denna information.

doctor tabellen lagrar elementära uppgifter om läkare, som de anger under registreringen. Kolumnerna i denna tabell är:

id – Ett unikt nummer som appen tilldelar läkare vid registreringen.
first_name – Läkarens förnamn.
last_name – Läkarens efternamn.
professional_statement – En detaljerad översikt över läkarens kvalifikationer, erfarenhet, yrkesmotto etc. Denna information skrivs in av läkaren och visas på varje läkares profilsida.
practicing_from – Datumet då läkaren började praktisera medicin. Detta har stor betydelse, eftersom appen kommer att härleda sitt erfarenhetsbetyg för varje läkare baserat på informationen i den här kolumnen.

specialization Tabellen innehåller alla befintliga medicinska specialiseringar som ortoped, neurolog, tandläkare, etc. En läkare kan ha mer än en specialisering; i själva verket är det ganska vanligt att en läkare specialiserar sig på relaterade områden. En neurolog kan till exempel också vara en psykiater; en gynekolog kan vara en endokrinolog och så vidare. Därför är doctor_specialization tabellen tillåter en många-till-många-relation mellan doctor och specialization tabeller. Attributen i dessa två tabeller är självförklarande.

qualification Tabellen lagrar information om läkares utbildning och yrkeskvalifikationer, inklusive examina, certifieringar, forskningsrapporter, seminarier, fortbildning etc. För att underlätta de olika typerna av kvalifikationsdetaljer har jag gett dessa områden ganska generiska namn:

id – Tabellens primärnyckel.
doctor_id – Refererar till doctor tabell och relaterar läkaren till kvalifikationen.
qualification_name – Anger namnet på examen, certifiering, forskningsuppsats, etc.
institute_name – Den institution som utfärdade examensbeviset till läkaren. Detta kan vara ett universitet, en medicinsk institution, en internationell sammanslutning av läkare, etc.
procurement_year – Datum då kvalifikationen erhölls eller tilldelas.

hospital_affiliation Tabellen innehåller information om läkarnas anknytning till sjukhus och vårdgivare. Denna information är endast för visning på en läkares profil och har ingen betydelse i funktionen för bokning av tid. OPD-uppgifter (poliklinisk avdelning) skrivs in separat och kommer att hanteras senare i denna artikel.

Den här tabellens kolumner är:

id – Tabellens primärnyckel.
doctor_id – Refererar till doctor tabell och länkar läkaren till det anslutna sjukhuset.
hospital_name – Det anslutna sjukhusets namn.
city and country – Staden och landet där sjukhuset ligger. Dessa adresskolumner spelar ingen roll i appens sökfunktion; de är endast för visning på läkarens profil.
start_date – När läkarens anknytning till sjukhuset inleddes.
end_date – När anslutningen upphörde. Den är nullbar eftersom nuvarande anslutningar inte kommer att ha ett slutdatum.

Hantera läkares OPD/klinikdetaljer

Informationen i detta avsnitt skrivs in av läkare (eller deras personal) och spelar en betydande roll i appens sök- och bokningsfunktioner.

office tabellen innehåller information om polikliniken på de sjukhus som läkare är knutna till samt sina egna kliniker (d.v.s. kontor eller mottagningar). Kolumnerna i denna tabell är:

id – Den här tabellens primärnyckel.
doctor_id – Refererar till doctor tabell och anger relevant läkare.
hospital_affiliation_id –Betecknar sjukhuset där läkaren är tillgänglig för OPD. Eftersom kolumnen är tillämplig på OPD men inte kliniker är den nullbar.
time_slot_per_client_in_min – Lagrar en tid (i minuter) som avsatts för konsultationer. Antalet minuter skrivs in av läkare baserat på deras erfarenhet. Den här kolumnen hjälper appen att avgöra nästa tillgängliga plats. Observera att detta nummer inte är en garanti för möteslängden, men det hjälper till att minimera patientens väntetider om de använder appen för att boka tid.
first_consultation_fee – Den avgift som läkaren tar ut för ett första besök. Detta kan tyckas oviktigt, men det är väldigt viktigt för sökfunktionen; avgift är ett mycket vanligt filterkriterium.
followup_consultation_fee – Många läkare tar mindre betalt för ett uppföljningsbesök än för en första konsultation. Den här kolumnen lagrar kostnaden för uppföljande konsultation.
street_address – Adressen till sjukhusets OPD eller klinik.
city , state och country – Staden, staten och landet där sjukhuset eller kliniken är belägen.
zip – Det postnummer där kliniken eller sjukhuset ligger. Ofta söker människor efter läkare i närliggande områden med hjälp av ett postnummer, så det här fältet kommer att vara viktigt för appens sökfunktion.

Varför finns det en separat "kontorstabell" när OPD-detaljer enkelt kan spåras i tabellen "sjukhustillhörighet"?

Tre skäl:

En läkare kan vara knuten till ett sjukhus för en aspekt av sitt arbete (d.v.s. att utföra operationer) men inte för andra (d.v.s. att träffa inkommande patienter). Vi kan förlora sådana anknytningar om vi försöker behålla kontorsuppgifter i hospital_affiliation endast tabell.
Många läkare är inte anslutna till sjukhus, utan har sina egna kliniker eller kontor. Vi måste lagra information för dessa läkare också.
En läkare kan ha flera kontor på olika platser, eller kan arbeta på flera filialer av ett sjukhus. Om läkaren endast visas som knuten till en sjukhusplats kan vi förlora viss information. Det är anledningen till att vi har separata adressuppgifter.

office_doctor_availability tabell lagrar läkarnas OPD/kliniktillgänglighet i form av tidsluckor (säg 2 timmar på morgonen och 4 timmar på kvällen). Att dela upp dagen på det här sättet är ganska vanligt, så att ha ett extra bord för att lagra tillgänglighetsplatser är vettigt. Dessutom kan läkare arbeta mer än ett OPD-skift. Kolumnerna för denna tabell är:

id – Tabellens primärnyckel.
office_id – Refererar till "kontorstabellen".
day_of_week – Veckodagen, dvs måndag, tisdag, etc. Detta gör att läkare kan ha olika tillgänglighet för olika dagar (till exempel helger kontra vardagar).
start_time – När läkaren är redo för den första patienten.
end_time – När det slutliga mötet eller skiftet är planerat att avslutas.
is_available – Tillåter läkare att markera sin tillgänglighet för särskilda dagar eller tidsluckor. Den här kolumnen initieras med ett "Y" som standard och uppdateras till ett "N" när läkare markerar att de inte är tillgängliga.
reason_of_unavailablity – Många läkare föredrar att berätta varför de är otillgängliga eller måste avboka ett besök. Detta hjälper till att bygga en transparent relation mellan läkare och deras patienter. Eftersom det är valfritt har jag behållit denna som nullbar kolumn.

in_network_insurance tabell lagrar försäkringsinformation. I många länder är medicinska tjänster mycket dyra och sjukförsäkring är obligatorisk. I sådana fall innehåller denna tabell information om vilka försäkringsbolag som är fullt accepterade på sjukhusets OPD eller klinik.

Hantera klient- och granskningsdata

För en patient kräver registreringen av appen väldigt lite information. Från och med nu kommer jag att använda "klient" snarare än "användare" eller "patient".

client_account tabellen lagrar grundläggande detaljer för kunder. Dessa uppgifter registreras vid tidpunkten för registrering. Kolumnerna i denna tabell är:

id – Ett unikt nummer som tilldelas varje kund.
first_name – Kundens förnamn.
last_name – Kundens efternamn.
contact_number – Kundens telefonnummer, gärna ett mobilnummer, dit mötesinformation kan skickas. Detta är också det nummer där klienten kan kontaktas av läkarens personal.
email – Kundens e-postadress. Appen kan skicka mötespåminnelser till kunder.

client_review Tabellen ger inte bara feedback (d.v.s. kundrecensioner) för läkare, utan den hjälper också potentiella kunder att välja läkare. Det är en integrerad komponent i denna app. Kolumner för den här tabellen är:

id – Den här tabellens primärnyckel.
user_account_id – Anger vilken användare som skickar recensionen.
doctor_id – Läkaren granskas.
is_review_anonymous – Om kundens namn kommer att publiceras med recensionen eller inte. Detta är en säkerhetsfunktion för klienter.
wait_time_rating – Den här sifferkolumnen har ett betyg som sträcker sig från 1 (sämst) till 10 (bäst). Det återspeglar klientens uppfattning om hur länge de väntade på att träffa läkaren.
bedside_manner_rating – Lagrar klientens åsikt om läkarens sätt att vara vid sängen (dvs. om läkaren är snäll, medkännande, kommunicerar bra, etc.)
overall_rating – Kundens bedömning av deras allmänna erfarenhet av läkaren.
review – Kunder kan ge sin detaljerade feedback här.
is_doctor_recommended – Denna indikatorkolumn anger om klienten skulle rekommendera läkaren.
review_date – När recensionen lämnades in.

Hantera möten

Den här sektionen är den främsta USP (Unique Selling Point) för denna app, eftersom den tillåter kunder att kontrollera tillgängligheten för olika läkare och boka tid.

appointment Tabellen innehåller mötesinformation för kunder. Dess kolumner inkluderar:

id – Ett unikt nummer tilldelas varje möte. Detta nummer hänvisas till någon annanstans.
user_account_id – Vilken kund bokar mötet.
office_id – Anger vilken läkare och vilket sjukhus OPD eller klinik som är inblandad i mötet.
probable_start_time – Detta är en tidsstämpelkolumn som innehåller den troliga starttiden för mötet. Läkarbesöks starttider är vanligtvis troliga snarare än absoluta.
actual_end_time – Den faktiska sluttiden för konsultationen. Till en början är denna kolumn tom, eftersom många faktorer kan påverka när ett möte avslutas. Därför är detta en nullbar kolumn.
appointment_status_id – Detta refereras från appointment_status tabell, och det anger den aktuella statusen för mötet. Möjliga värden för status är "aktiv", "avbruten" och "slutförd". Till en början skulle statusen vara "aktiv". Det skulle bli "komplett" när mötet är klart. Det kommer att bli "inställt" om kunden avbokar sitt möte.
appointment_taken_date – Datum då mötet gjordes.
app_booking_channel_id – Kanalen genom vilken ett möte bokades. Det finns flera kanaler genom vilka möten görs:genom appen, genom att ringa sjukhuset, genom att ringa läkaren eller deras mottagning, etc.

Se den fullständiga datamodellen

Sökfunktionen i funktion

Låt oss söka efter en ögonläkare i postnummer 63101. Sökresultat bör sorteras efter följande kriterier:

Mest erfarenhet
Högsta betyg för kundrekommendationer
Lägsta avgiften för initial konsultation

Här är 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;

Vad skulle du lägga till?

Vad mer kan läggas till i den här appen och den här datamodellen? Dela dina åsikter i kommentarerna.