Un modèle de données pour une application de prise de rendez-vous médicaux

La prise de rendez-vous chez le médecin via une application en ligne est une innovation qui simplifie tout le processus. Plongeons-nous dans le modèle de données derrière une application de prise de rendez-vous.

Pourquoi utiliser une application ? Il permet aux gens de trouver plus facilement les médecins de leur choix, leur permettant de voir les dossiers professionnels du médecin et les avis des patients. Lorsqu'une personne trouve un médecin qu'elle aime, elle peut prendre rendez-vous avec lui sans quitter l'application. Une application peut également aider les médecins à réduire au maximum les temps d'attente de leurs patients, les aider à planifier leurs patients et leur permettre de garder un œil sur les avis en ligne des patients.

Exigences de l'application pour les rendez-vous médicaux

En bref, nous nous attendons à ce que notre application :

Permettre aux patients de rechercher des médecins de diverses spécialités (médecin de famille, cardiologue, podologue, etc.) par emplacement.
Afficher une liste ordonnée de médecins en fonction de leurs années d'expérience, de leur distance par rapport à l'emplacement du patient, de leurs recommandations aux patients et de leurs indices de révision (évaluation collective des patients sur la manière de s'occuper du lit, le temps d'attente, le personnel, etc.)
Afficher les frais de consultation initiale et de suivi des médecins
Capturez et affichez les profils des médecins, y compris des détails sur leurs diplômes, certifications, stages et affiliations passées et actuelles avec des hôpitaux.
Enregistrer les avis sur les médecins des utilisateurs de l'application. Cet examen donnera un aperçu complet des médecins et de leur personnel aux autres utilisateurs de l'application.

Et n'oubliez pas l'argument de vente unique de l'application :afficher les prochains rendez-vous disponibles et permettre aux utilisateurs d'en réserver un .

Catégoriser les exigences de l'application

Fondamentalement, nous pouvons diviser les exigences de l'application en quatre domaines :

Gérer les données des médecins – Les médecins peuvent s'inscrire et saisir toutes leurs coordonnées.
Gérer les OPD des médecins (service ambulatoire) et les détails de la clinique – Les médecins (ou leur personnel) peuvent consigner des informations sur l'horaire et la disponibilité de leur clinique ou de leur OPD.
Gérer les données des clients et des avis – Les utilisateurs peuvent s'inscrire et saisir leurs informations de base. Ils peuvent également publier des avis sur les médecins.
Gestion des rendez-vous – Les utilisateurs peuvent rechercher des médecins en fonction de certains critères.

Examinons ces zones individuellement.

Gérer les données des médecins

Les médecins peuvent s'inscrire à l'application en remplissant certaines informations obligatoires, mais la fonction de prise de rendez-vous n'est activée qu'après avoir rempli leur profil complet. Cela inclut leurs qualifications (diplômes professionnels, certifications/spécialisations et stages) et leurs affiliations passées et actuelles avec des hôpitaux et des prestataires de services de santé.

Les tableaux présentés ci-dessous gèrent ces informations.

Le doctor table stocke des détails élémentaires sur les médecins, qu'ils saisissent lors de l'inscription. Les colonnes de ce tableau sont :

id – Un numéro unique que l'application attribue aux médecins lors de l'inscription.
first_name – Prénom du médecin.
last_name – Nom de famille du médecin.
professional_statement – Un aperçu détaillé des qualifications du médecin, de son expérience, de sa devise professionnelle, etc. Ces informations sont saisies par le médecin et affichées sur la page de profil de chaque médecin.
practicing_from – La date à laquelle le médecin a commencé à exercer la médecine. Cela a une signification profonde, car l'application dérivera sa note d'expérience pour chaque médecin en fonction des informations contenues dans cette colonne.

La specialization le tableau contient toutes les spécialisations médicales existantes comme l'orthopédie, le neurologue, le dentiste, etc. Un médecin peut avoir plus d'une spécialisation; en fait, il est assez courant qu'un médecin se spécialise dans des domaines connexes. Par exemple, un neurologue peut aussi être psychiatre; un gynécologue peut être endocrinologue, etc. Par conséquent, le doctor_specialization table permet une relation plusieurs à plusieurs entre le doctor et specialization les tables. Les attributs de ces deux tableaux sont explicites.

La qualification table stocke des détails sur la formation et les qualifications professionnelles des médecins, y compris les diplômes, les certifications, les travaux de recherche, les séminaires, la formation continue, etc. Pour faciliter les différents types de détails sur les qualifications, j'ai donné à ces champs des noms assez génériques :

id – La clé primaire de la table.
doctor_id – Référence le doctor tableau et relie le médecin à la qualification.
qualification_name – Signifie le nom du diplôme, de la certification, du document de recherche, etc.
institute_name – L'institution qui a délivré le diplôme au médecin. Il peut s'agir d'une université, d'un établissement médical, d'une association internationale de médecins, etc.
procurement_year – La date à laquelle la qualification a été obtenue ou décernée.

Le hospital_affiliation table contient des informations sur les affiliations des médecins avec les hôpitaux et les prestataires de services de santé. Ces données sont uniquement destinées à être affichées sur le profil d'un médecin et n'ont aucune signification dans la fonction de prise de rendez-vous. Les détails de l'OPD (ambulatoire) sont saisis séparément et seront traités plus loin dans cet article.

Les colonnes de ce tableau sont :

id – La clé primaire de la table.
doctor_id – Référence le doctor tableau et relie le médecin à l'hôpital affilié.
hospital_name – Le nom de l'hôpital affilié.
city and country – La ville et le pays où se situe l'hôpital. Ces colonnes d'adresse ne jouent aucun rôle dans la fonction de recherche de l'application ; ils sont uniquement destinés à être affichés sur le profil du médecin.
start_date – Lorsque l'affiliation du médecin à l'hôpital a commencé.
end_date – Lorsque l'affiliation a pris fin. Il est nullable car les affiliations actuelles n'auront pas de date de fin.

Gérer les détails de l'OPD/de la clinique des médecins

Les informations de cette section sont saisies par les médecins (ou leur personnel) et jouent un rôle important dans les fonctionnalités de recherche et de réservation de l'application.

Le office Le tableau contient des informations sur le service ambulatoire des hôpitaux auxquels les médecins sont affiliés ainsi que sur leurs propres cliniques (c'est-à-dire les bureaux ou les cabinets). Les colonnes de ce tableau sont :

id – La clé primaire de cette table.
doctor_id – Référence le doctor tableau et indique le médecin concerné.
hospital_affiliation_id –Signifie l'hôpital où le médecin est disponible pour OPD. Étant donné que la colonne s'applique aux OPD mais pas aux cliniques, elle est nulle.
time_slot_per_client_in_min – Enregistre une durée (en minutes) allouée aux consultations. Le nombre de minutes est saisi par les médecins en fonction de leur expérience. Cette colonne aide l'application à déterminer le prochain emplacement disponible. Notez que ce numéro n'est pas une garantie de durée de rendez-vous, mais il aide à minimiser les temps d'attente des patients s'ils utilisent l'application pour prendre rendez-vous.
first_consultation_fee – Les honoraires facturés par le médecin pour une première visite. Cela peut sembler sans importance, mais c'est très important pour la fonction de recherche; les frais sont un critère de filtre très courant.
followup_consultation_fee – De nombreux médecins facturent moins pour une visite de suivi que pour une première consultation. Cette colonne stocke le coût de la consultation de suivi.
street_address – L'adresse de l'OPD de l'hôpital ou de la clinique.
city , state et country –La ville, l'état et le pays où se trouve l'hôpital ou la clinique.
zip – Le code postal où se trouve la clinique ou l'hôpital. Souvent, les internautes recherchent des médecins dans les zones proches à l'aide d'un code postal. Ce champ sera donc important pour la fonction de recherche de l'application.

Pourquoi y a-t-il un tableau "bureau" distinct alors que les détails OPD peuvent facilement être suivis dans le tableau "hospital_affiliation" ?

Trois raisons :

Un médecin peut être affilié à un hôpital pour un aspect de son travail (c'est-à-dire effectuer des interventions chirurgicales) mais pas pour d'autres (c'est-à-dire voir des patients sans rendez-vous). Nous pouvons perdre ces affiliations si nous essayons de conserver les détails du bureau dans le hospital_affiliation tableau uniquement.
De nombreux médecins ne sont pas affiliés à des hôpitaux, mais ont leurs propres cliniques ou cabinets. Nous devons également stocker des informations pour ces médecins.
Un médecin peut avoir plusieurs cabinets à différents endroits ou travailler dans plusieurs succursales d'un hôpital. Si le médecin n'est indiqué que comme étant affilié à un seul hôpital, nous pouvons perdre certaines informations. C'est la raison pour laquelle nous conservons des coordonnées distinctes.

Le office_doctor_availability table stocke la disponibilité des médecins OPD / clinique en termes de créneaux horaires (disons 2 heures le matin et 4 heures le soir). Diviser la journée de cette façon est assez courant, il est donc logique d'avoir une table supplémentaire pour stocker les créneaux de disponibilité. De plus, les médecins peuvent travailler plus d'un quart de travail OPD. Les colonnes de ce tableau sont :

id – La clé primaire de la table.
office_id – Fait référence à la table "bureau".
day_of_week – Le jour de la semaine, c'est-à-dire lundi, mardi, etc. Cela permet aux médecins d'avoir des disponibilités différentes pour différents jours (week-end vs jours de semaine, par exemple).
start_time – Lorsque le médecin est prêt pour le premier patient.
end_time – Lorsque le dernier rendez-vous ou quart de travail doit se terminer.
is_available – Permet aux médecins de marquer leur disponibilité pour des jours ou des créneaux horaires particuliers. Cette colonne est initialisée avec un "Y" par défaut et est mise à jour avec un "N" lorsque les médecins marquent leur indisponibilité.
reason_of_unavailablity – De nombreux médecins préfèrent divulguer pourquoi ils ne sont pas disponibles ou doivent annuler un rendez-vous. Cela permet de construire une relation transparente entre les médecins et leurs patients. Comme il est facultatif, j'ai conservé cette colonne comme colonne nullable.

Le in_network_insurance table stocke les informations d'assurance. Dans de nombreux pays, les services médicaux sont très coûteux et l'assurance maladie est obligatoire. Dans de tels cas, ce tableau contient les détails sur les compagnies d'assurance pleinement acceptées à l'OPD ou à la clinique de l'hôpital.

Gérer les données des clients et des avis

Pour un patient, l'inscription à l'application nécessite très peu d'informations. À partir de maintenant, j'utiliserai « client » plutôt que « utilisateur » ou « patient ».

Le client_account table stocke les détails de base pour les clients. Ces détails sont saisis au moment de l'inscription. Les colonnes de ce tableau sont :

id – Un numéro unique attribué à chaque client.
first_name – Le prénom du client.
last_name – Le nom de famille du client.
contact_number – Le numéro de téléphone du client, de préférence un numéro de portable, auquel les informations de rendez-vous peuvent être envoyées. C'est également le numéro auquel le client peut être contacté par le personnel du cabinet du médecin.
email – L'adresse e-mail du client. L'application peut envoyer des rappels de rendez-vous aux clients.

Le client_review Le tableau offre non seulement des commentaires (c'est-à-dire des avis de clients) pour les médecins, mais il aide également les clients potentiels à choisir des médecins. Il fait partie intégrante de cette application. Les colonnes de ce tableau sont :

id – La clé primaire de cette table.
user_account_id – Indique quel utilisateur soumet l'avis.
doctor_id – Le médecin en cours d'examen.
is_review_anonymous – Si le nom du client sera publié avec l'avis ou non. Il s'agit d'une fonctionnalité de sécurité pour les clients.
wait_time_rating – Cette colonne numérique contient une note allant de 1 (la pire) à 10 (la meilleure). Il reflète l'opinion du client sur le temps qu'il a attendu pour voir le médecin.
bedside_manner_rating – Stocke l'opinion du client sur la façon dont le médecin est au chevet du patient (c'est-à-dire si le médecin est gentil, compatissant, communique bien, etc.)
overall_rating – Évaluation par le client de son expérience générale avec le médecin.
review – Les clients peuvent donner leurs commentaires détaillés ici.
is_doctor_recommended – Cette colonne d'indicateur indique si le client recommanderait le médecin.
review_date – Date de soumission de l'avis.

Gestion des rendez-vous

Cette section est le principal USP (Unique Selling Point) pour cette application, car elle permet aux clients de vérifier la disponibilité de divers médecins et de prendre rendez-vous.

Le appointment table contient les détails de rendez-vous pour les clients. Ses colonnes incluent :

id – Un numéro unique est attribué à chaque rendez-vous. Ce numéro est référencé ailleurs.
user_account_id – Quel client prend le rendez-vous.
office_id – Indique quel médecin et quel OPD de l'hôpital ou clinique est impliqué dans le rendez-vous.
probable_start_time – Il s'agit d'une colonne d'horodatage qui contient l'heure de début probable du rendez-vous. Les heures de début des rendez-vous médicaux sont généralement probables plutôt qu'absolues.
actual_end_time – L'heure de fin réelle de la consultation. Initialement, cette colonne est vide, car de nombreux facteurs peuvent influencer la fin d'un rendez-vous. Par conséquent, il s'agit d'une colonne nullable.
appointment_status_id – Ceci est référencé à partir du appointment_status tableau, et il indique l'état actuel du rendez-vous. Les valeurs possibles pour l'état sont « actif », « annulé » et « terminé ». Initialement, le statut serait "actif". Il deviendrait « complet » une fois le rendez-vous effectué. Il deviendra "annulé" si le client annule son rendez-vous.
appointment_taken_date – La date à laquelle le rendez-vous a été pris.
app_booking_channel_id – Le canal par lequel un rendez-vous a été pris. Il existe plusieurs canaux par lesquels les rendez-vous sont pris :via l'application, en appelant l'hôpital, en appelant le médecin ou son cabinet, etc.

Voir le modèle de données complet

La fonction de recherche en action

Cherchons un ophtalmologiste dans le code postal 63101. Les résultats de la recherche doivent être classés selon les critères suivants :

Plus d'expérience
Taux de recommandation client le plus élevé
Frais de consultation initiale les plus bas

Voici le 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;

Qu'ajouteriez-vous ?

Que peut-on ajouter d'autre à cette application et à ce modèle de données ? Partagez vos points de vue dans les commentaires.