Dépôts clés

Le code d’O3 est hébergé dans plusieurs dépôts GitHub maintenus par la communauté. L’application O3 utilise une architecture basée sur les microfrontends. Cela signifie qu’elle est composée de nombreuses applications plus petites et indépendantes appelées “modules frontend”. Ces modules frontend sont regroupés dans différents dépôts en fonction de la partie d’O3 qu’ils supportent.

Le code dans chaque dépôt est axé sur une préoccupation particulière. Par exemple, le dépôt Patient Chart contient des modules frontend pour les fonctionnalités du dossier patient, telles que les allergies, les rendez-vous, les conditions, les formulaires, les médicaments, les notes, les programmes, les résultats de tests et les signes vitaux. C’est un exemple de monorepo, où plusieurs packages sont contenus dans un seul dépôt ; la plupart des dépôts O3 sont structurés de cette manière. Le dépôt Core est spécial. Il contient quelques modules frontend, mais aussi la logique d’application de base qui charge les modules frontend, ainsi que les outils O3 et l’API JavaScript.

Les dépôts que vous devez connaître dans O3 incluent :

Core - contient des modules frontend pour les préoccupations de bas niveau telles que l’authentification. Il contient également l’app shell, l’application de base qui charge et assemble tous les modules frontend. Core publie aussi la bibliothèque JavaScript @openmrs/esm-framework, qui fournit des préoccupations transversales essentielles telles que la configuration, l’internationalisation, les indicateurs de fonctionnalités et la gestion de l’état global. Ce dépôt contient également les outils pour O3.
Home - rend l’interface utilisateur de la page d’accueil après la connexion de l’utilisateur. Cette app vit maintenant dans le monorepo Patient Management. Les implémenteurs peuvent personnaliser cette page pour afficher des tableaux de bord pour les rendez-vous, les listes de patients, les files d’attente de services, les visualisations de données, et plus encore.
Template - un dépôt modèle de démarrage qui reste utile comme référence pour la structure générée par npm create @openmrs/o3-app@latest.
Patient Chart - regroupe les modules frontend qui constituent ensemble le tableau de bord patient, y compris les widgets pour les pièces jointes, les allergies, les rendez-vous, les conditions, les indicateurs patient, les formulaires, les vaccinations, l’impression d’étiquettes, les listes, les médicaments, les notes, les programmes, les tâches, les résultats de tests et les signes vitaux.
Patient Management - regroupe les modules frontend qui gèrent les préoccupations liées à la gestion des patients telles que la planification des rendez-vous, la recherche de patients, la gestion des listes de patients, l’enregistrement de nouveaux patients, ainsi que la gestion des files d’attente de services, des lits, des services et de la page d’accueil.
Laboratory app - Un module frontend pour gérer les demandes et les files d’attente de laboratoire construit sur OpenMRS 3.x
Angular Form Engine - une bibliothèque de moteur de formulaires construite en Angular. Elle exploite le puissant support d’Angular pour les formulaires pour fournir une solution robuste avec des capacités telles que la validation des champs, l’injection de sources de données personnalisées, le rendu conditionnel, les expressions historiques, et plus encore.
React Form Engine - une bibliothèque de moteur de formulaires construite en React. Le RFE est le successeur du moteur de formulaires Angular et est construit sur une pile technologique moderne avec l’objectif de fournir des capacités de rendu de formulaires rapides, performantes et plus flexibles.
Form Builder - permet aux utilisateurs de construire des schémas de formulaires OpenMRS de manière interactive en utilisant un éditeur de schéma JSON intégré ou une interface utilisateur de construction interactive. Il fournit également un onglet de rendu qui affiche votre schéma de formulaire en utilisant le moteur de formulaires React. Les utilisateurs peuvent publier leurs schémas sur leur serveur backend, leur permettant d’accéder à leurs formulaires et de collecter des données dans le dossier patient dans l’espace de travail Formulaires cliniques.
Fast Data Entry app - permet les flux de travail de saisie de données rétrospective et rend les formulaires JSON via le wrapper de moteur de formulaires actif, généralement le moteur de formulaires React dans l’application de référence.
Medication Dispensing app - permet aux implémenteurs de suivre les médicaments distribués dans OpenMRS.
Billing app - permet aux établissements de santé de gérer la facturation des patients, les paiements et la tarification des services. Il fournit des fonctionnalités pour générer des factures, suivre les paiements, gérer les services facturables et gérer les transactions financières dans les établissements de santé.
Stock Management - fournit un module frontend pour gérer les stocks et les niveaux d’inventaire dans les établissements de santé. Il s’intègre avec le module backend communautaire pour la gestion des stocks afin de fournir des capacités complètes de gestion des stocks pour les établissements de santé.
User Onboarding - fournit des tutoriels interactifs et des flux de travail d’intégration pour aider les nouveaux utilisateurs à apprendre à utiliser O3. Il comprend des guides étape par étape configurables qui peuvent être personnalisés pour différentes implémentations. Le système d’intégration prend en charge les fonctionnalités de transition automatique, permettant aux tutoriels de progresser automatiquement lorsque des éléments spécifiques apparaissent à l’écran.
O3 Distro Reference Application - l’implémentation de référence d’O3. Les implémenteurs peuvent l’utiliser comme point de départ pour leurs propres distributions.
Content Packages - Artéfacts Maven qui regroupent les métadonnées sous forme de fichiers de configuration. Ces packages fournissent les métadonnées de base nécessaires pour exécuter O3, y compris les concepts, les emplacements, les formulaires et autres données de configuration.
Admin Tools - affiche une page interstitielle qui relie les utilisateurs à divers modules frontend qui ne font pas partie de l’EMR de base tels que le Form builder, le Cohort builder, le tableau de bord de gestion OCL, le tableau de bord de gestion des stocks, et plus encore. Il fournit également un lien vers l’interface utilisateur d’administration O2 Legacy pour les utilisateurs administrateurs.
Cohort Builder - un outil qui permet aux utilisateurs de construire et de gérer des cohortes dynamiques de patients (groupes) basées sur plusieurs critères cliniques et démographiques.
Module Management - un module frontend d’apprentissage basé sur l’interface utilisateur de gestion des modules OpenMRS legacy. Le code dans ce dépôt est annoté avec des commentaires et peut servir de bon point de départ pour les nouveaux développeurs cherchant à comprendre comment construire des modules frontend.
Frontend RFC - un dépôt où les décisions architecturales affectant les technologies et les processus qui s’appliquent à toutes les nouvelles distributions O3 sont d’abord présentées, discutées et finalement approuvées par consensus.
JSON schemas - un dépôt qui héberge les schémas JSON standard utilisés dans OpenMRS. Ces schémas sont utilisés pour fournir des capacités d’auto-complétion et de validation lors de l’édition des fichiers de registre de routes pour les modules frontend O3 et les schémas de formulaires O3.

Core

Core regroupe un mélange d’applications de base qui incluent à la fois des modules frontend typiques ainsi que des packages qui ne rendent pas d’interfaces utilisateur. Les modules frontend typiques incluent :

Login - responsable du rendu de la page de connexion lorsqu’un utilisateur lance l’application pour la première fois, et du sélecteur d’emplacement après la connexion d’un utilisateur.
Devtools - rend l’interface utilisateur import-map-overrides qui permet aux développeurs de remplacer les modules frontend au moment de l’exécution, les remplaçant essentiellement par des versions locales. Ce mécanisme permet aux développeurs de tester leurs modifications locales aux modules frontend par rapport à la version de production la plus à jour de l’application sans avoir besoin de reconstruire et redéployer l’application entière.
Help Menu - fournit un bouton de menu d’aide et une popup qui affiche les extensions liées à l’aide. Il expose un slot d’extension help-menu-slot où les modules peuvent enregistrer des éléments d’aide tels que les notes de version, les liens de documentation et les informations de contact.
Implementer Tools - fournit une interface utilisateur permettant aux implémenteurs et aux développeurs de modifier dynamiquement les propriétés de configuration au moment de l’exécution et de visualiser les informations administratives sur leur frontend. Il fournit également un éditeur JSON intégré, qui permet aux développeurs de modifier les propriétés de configuration via le code, un mode d’éditeur d’interface utilisateur pour voir quels slots d’extension existent dans l’application et leurs configurations actuelles, une interface utilisateur pour basculer les indicateurs de fonctionnalités, un visualiseur de modules backend, et un visualiseur de modules frontend qui montre des informations détaillées de configuration et de dépendance pour chaque module installé.
Primary Navigation - rend le menu de navigation supérieur dans l’application, présentant le widget de recherche de patient compact, des liens vers le menu Outils d’implémentation, la page d’enregistrement, le menu utilisateur et le changeur d’applications.
Offline Tools - responsable du rendu des widgets liés au mode hors ligne.

En plus de ces packages liés à l’interface utilisateur, Core inclut également les packages non-UI suivants :

Core Framework - regroupe les packages qui composent l’API du framework O3 de base, y compris les objets API partagés (tels que les objets patient et visite), le menu des fils d’Ariane, le système d’extension, les utils React partagés, les outils de gestion d’état global, la gestion des erreurs, et le guide de style, entre autres choses. La fonctionnalité exportée par ces packages est regroupée dans un package JavaScript NPM appelé @openmrs/esm-framework qui est réutilisé par la plupart des modules frontend.
App Shell - l’app shell est le point d’entrée de l’application. Il est responsable du chargement et de l’enregistrement des modules frontend dans la carte d’importation, de la coordination du cycle de vie de l’application, de la gestion des mécaniques de routage et de chargement des modules de base, et plus encore. Lisez le guide de l’app shell pour plus d’informations.
Tooling - fournit une interface en ligne de commande unifiée pour diverses tâches de développement et de déploiement frontend. La CLI est regroupée dans un package NPM appelé openmrs . Les développeurs peuvent utiliser la CLI pour lancer des serveurs de développement Rspack ou Webpack pour le développement local, assembler des modules frontend pour une distribution, construire l’application, et plus encore.

Home

Contient le module frontend home , qui rend la page d’accueil à laquelle les utilisateurs accèdent après s’être connectés avec succès. Cette page a un menu de navigation gauche avec des entrées pour les rendez-vous, les listes de patients et les applications de file d’attente de service.

Par défaut, vous verrez un widget de visites actives et un widget pour les rendez-vous programmés pour ce jour dans l’interface utilisateur. Le schéma de configuration pour l’application home permet aux développeurs et aux implémenteurs de configurer quelle URL utiliser pour naviguer l’utilisateur après qu’ils cliquent sur un résultat de recherche suite à une recherche de patient. Par défaut, l’utilisateur sera dirigé vers le dossier patient. Le menu latéral et le tableau de bord d’accueil exposent des slots d’extension dans lesquels se branchent les tableaux de bord du dépôt Patient management. Ceux-ci incluent des tableaux de bord pour les Rendez-vous, les Listes de patients de laboratoire, les Files d’attente de service et les Services.

Template

Un Dépôt Modèle de démarrage qui reste utile comme référence pour de nouveaux modules frontend. La plupart des nouveaux modules devraient commencer avec le workflow publié npm create @openmrs/o3-app@latest, qui crée des modules autonomes, des modules dans des monorepos existants et de nouveaux monorepos. L’application template reste utile quand vous voulez inspecter un module minimal à la main; la plupart de ses composants sont annotés avec des commentaires qui guident les développeurs dans la structure de l’application.

Patient Chart

Contient divers modules frontend qui constituent des widgets dans un tableau de bord patient. Ces widgets incluent :

Allergies - fournit une vue d’ensemble tabulaire des allergies enregistrées pour un patient ainsi qu’un formulaire pour enregistrer les allergies.
Attachments - montre une galerie de pièces jointes téléchargées pour un patient ainsi qu’une interface de téléchargement de fichiers pour télécharger de nouvelles pièces jointes via le système de fichiers ou la caméra de l’utilisateur. Les utilisateurs peuvent télécharger des images et des documents PDF ou des images capturées à l’aide de la caméra de leur appareil. Ils peuvent également supprimer les pièces jointes existantes.
Conditions - fournit une vue d’ensemble tabulaire des conditions enregistrées pour un patient ainsi qu’un formulaire pour enregistrer de nouvelles conditions et modifier les existantes.
Indicateurs patient - affiche des indicateurs visuels dans le dossier patient afin que les cliniciens voient rapidement le contexte important du patient.
Forms - fournit une vue d’ensemble tabulaire des formulaires cliniques disponibles dans le système. Les formulaires HTML Form Entry configurés s’ouvrent dans une page HTML Form Entry intégrée, tandis que les formulaires JSON O3 sont rendus via form-widget-slot, où le moteur de formulaires React enregistre le renderer par défaut dans l’application de référence.
Widgets Génériques pour Patients - Ceci est une preuve de concept pour un widget générique qui peut être ajouté au dossier patient via la configuration. Il peut afficher n’importe quelle observation soit dans une vue tabulaire soit dans une vue graphique. Il est conçu comme une voie pour créer des widgets réutilisables dans toute l’application.
Vaccinations - fournit une vue tabulaire des vaccinations enregistrées pour un patient ainsi qu’un formulaire pour enregistrer de nouvelles vaccinations. Cette application est incluse dans la configuration de distribution de l’application de référence.
Impression d’étiquettes - fournit des actions réutilisables d’impression d’étiquettes et de documents pour le dossier patient et les workflows associés.
Listes - affiche les vues de listes de patients depuis le dossier patient, y compris les détails d’une liste et les patients inscrits.
Médicaments - fournit une vue tabulaire des médicaments actifs et passés enregistrés pour un patient. Il fournit également un formulaire pour prescrire de nouveaux médicaments.
Notes - fournit une vue tabulaire des notes de visite enregistrées pour un patient ainsi qu’un formulaire pour enregistrer de nouvelles notes de visite.
Ordonnances - affiche le Panier d’ordonnances dans l’espace de travail qui permet aux utilisateurs de prescrire de nouvelles ordonnances de médicaments et d’examens, de modifier les existantes, et plus encore.
Bannière Patient - affiche une bannière qui montre le nom du patient, son avatar, son genre, son âge et ses identifiants. Elle fournit également un panneau extensible qui montre son adresse, ses coordonnées et ses relations avec d’autres patients. La bannière patient peut aussi afficher des étiquettes personnalisées pour indiquer si un patient a une visite active en cours ou s’il est décédé entre autres.
Programmes - fournit une vue tabulaire des programmes auxquels un patient est inscrit ainsi qu’un formulaire pour inscrire le patient à de nouveaux programmes.
Tâches - fournit un workspace du dossier patient pour créer, consulter et gérer les tâches du patient. Il dépend du module backend Tasks.
Tests - fournit des fonctionnalités pour prescrire et visualiser les résultats de tests pour un patient. Cela peut inclure des tests de laboratoire, des examens radiologiques, et plus encore.
Signes Vitaux - fournit des vues tabulaires et graphiques des signes vitaux et biométriques enregistrés pour un patient ainsi qu’un formulaire pour enregistrer les signes vitaux et biométriques. Il fournit également un en-tête des signes vitaux qui affiche un résumé des signes vitaux les plus récemment enregistrés.

En plus de ces widgets, il existe deux autres microfrontends qui encapsulent des préoccupations transversales. Ce sont :

Bibliothèque Commune - une bibliothèque de composants et d’utilitaires partagés entre les widgets du dossier patient. Ceux-ci incluent :
- Des composants personnalisés pour les en-têtes de cartes, les états d’erreur et vides, et la pagination.
- Des hooks personnalisés pour récupérer les ordonnances, les métadonnées de concepts, les inscriptions aux programmes, les propriétés globales, et plus de logique réutilisable.
Dossier Patient - fournit le cadre sous-jacent sur lequel tous les widgets individuels fonctionnent. Il configure la disposition du dossier patient et gère le routage entre le résumé du dossier et les tableaux de bord des widgets. Il configure également les extensions principales, l’espace de travail, la navigation gauche et les menus latéraux, les fonctionnalités de visites ainsi que le mode hors ligne.

Le dossier patient inclut également des packages qui fournissent des wrappers pour les moteurs de formulaires Angular et React. Les deux wrappers s’attachent à form-widget-slot, donc une distribution devrait choisir le wrapper qui correspond à son workflow de formulaires au lieu de charger les deux comme renderers concurrents.

Gestion des patients

Ce monorepo inclut les modules frontend suivants :

Visites Actives - fournit une vue tabulaire des patients enregistrés pour la journée en cours.
Rendez-vous - fournit des capacités pour créer, modifier et gérer les rendez-vous des patients.
Gestion des lits - fournit les écrans de configuration des types de lits, des étiquettes de lits et des lits dans les services.
Home - rend la page d’accueil après la connexion et héberge les slots d’extension du tableau de bord d’accueil.
Files D’attente de Service - fournit des capacités pour créer, gérer et visualiser les files d’attente dans un lieu.
Recherche de Patient - permet de rechercher des patients existants en utilisant une recherche simple et avancée.
Enregistrement de Patient - permet d’enregistrer de nouveaux patients et de les vérifier via des registres externes de patients configurables.
Liste de Patients - fournit une interface utilisateur pour créer et gérer des listes de patients.
Services - fournit une interface utilisateur pour gérer les admissions dans les services.

Application de laboratoire

L’Application de laboratoire fournit une interface utilisateur pour gérer les demandes et les files d’attente de laboratoire. Elle comprend les widgets suivants :

Tuiles de résumé de laboratoire - Fournissent des résumés numériques des tests de laboratoire, indiquant le nombre de tests commandés, en cours et terminés.
Onglets des commandes de laboratoire - Widgets (boutons) qui permettent de basculer entre les résultats de tests commandés, en cours et terminés. Ces résultats sont affichés sous forme de tableau dans la superposition.

Moteur de Formulaires Angular

Le Moteur de Formulaires Angular est une solution de moteur de formulaires initialement construite par AMPATH. Il exploite les capacités de formulaires d’Angular pour construire un moteur de formulaires complet avec des capacités telles que la validation des champs, l’injection de sources de données personnalisées, le rendu conditionnel, les expressions historiques, et plus encore. Le dossier patient fournit un wrapper Form Entry Angular micro frontend qui consomme la bibliothèque du moteur de formulaires et expose sa fonctionnalité via une parcelle Single SPA. Les distributions qui utilisent encore des schémas de formulaires Angular peuvent charger ce wrapper comme renderer de form-widget-slot; le workflow actuel de formulaires JSON O3 dans l’application de référence utilise plutôt le wrapper React. Pour en savoir plus sur le moteur de formulaires Angular, consultez son README et sa feuille de route technique . Vous pouvez en apprendre davantage sur le framework Angular ici .

Moteur de Formulaires React

Le Moteur de Formulaires React est une bibliothèque React qui permet la création et le rendu de formulaires médicaux standardisés au sein de l’écosystème O3. Il fournit un système de schéma de formulaire flexible basé sur JSON avec validation intégrée, rendu conditionnel et support multilingue - le rendant idéal pour les besoins complexes de collecte de données de santé. Les schémas de formulaire O3 sont écrits en JSON et sont conformes à la spécification standard du schéma JSON O3 qui définit la structure et les contraintes des données du formulaire. L’application de référence O3 intègre un Form Builder que les utilisateurs peuvent utiliser pour construire des formulaires de manière interactive, en utilisant le constructeur de schéma interactif, ou en écrivant du code dans l’éditeur JSON intégré. En savoir plus sur le moteur de formulaires React dans la documentation officielle .

Constructeur de Formulaires

Le Constructeur de Formulaires est un module frontend utilisé pour créer des schémas de formulaires OpenMRS. Il permet aux utilisateurs de créer de nouveaux schémas et de modifier les existants. Il fournit un éditeur de code intégré qui accepte le code JSON et un éditeur interactif où les utilisateurs peuvent construire un schéma de manière interactive sans écrire de code. Les schémas construits à l’aide du constructeur de formulaires peuvent être persistés sur le serveur, et optionnellement publiés, ce qui les rend disponibles pour le frontend via le widget des formulaires. Les schémas construits dans le constructeur de formulaires sont rendus via le moteur de formulaires React, ce qui permet aux utilisateurs de valider et de tester leurs formulaires directement depuis l’interface utilisateur du constructeur de formulaires.

Saisie Rapide de Données

L’Application de Saisie Rapide de Données est un module frontend qui permet un flux de travail naturel lors de la saisie de nombreux formulaires pré-enregistrés à la fois. Il n’est pas destiné aux flux de travail au point de service, mais plutôt comme un moyen de faire une saisie de données rétrospective. Il permet la saisie rapide de formulaires pour les sessions de groupe permettant d’enregistrer des informations sur une session de groupe ou pour les participants à la session. FDE rend les formulaires via form-widget-slot, donc il fonctionne avec le wrapper de moteur de formulaires JSON actif, par exemple le wrapper React utilisé par l’application de référence.

Distribution de Médicaments

L’application de Distribution de Médicaments est un outil simple qui permet de suivre les médicaments distribués. Elle est conçue pour servir les petits sites qui ne veulent pas gérer l’implémentation d’un système complet externe de chaîne d’approvisionnement/ERP. Ces sites ne se soucient généralement que de suivre ce qui doit être distribué par rapport à ce qui a déjà été distribué. Les principaux utilisateurs cibles de cette fonctionnalité sont les implémentations et les établissements qui ont une pharmacie sur place et ne facturent pas le patient/client pour les services, qui veulent distribuer des médicaments basés sur des ordonnances au sein de la même instance OpenMRS. La facturation et l’inventaire sont hors de portée.

Application de facturation

L’application de facturation est un module frontend conçu pour rationaliser les opérations financières dans les établissements de santé. Il facilite la gestion de la facturation des patients, des paiements et de la tarification des services. Le module s’intègre avec la plateforme OpenMRS et permet aux prestataires de soins de santé de générer des factures, suivre les paiements, gérer les services facturables et gérer diverses transactions financières. Il dépend du module backend OpenMRS Billing pour fonctionner correctement. L’application de facturation fournit des fonctionnalités telles que les tableaux de bord de facturation, le suivi de l’historique des factures, la génération de factures, la gestion des paiements et l’administration des services facturables.

Gestion des stocks

L’application de Gestion des stocks est un module frontend pour gérer les stocks et les niveaux d’inventaire dans les établissements de santé. Il fournit des fonctionnalités pour suivre les articles en stock, gérer les opérations de stock (réceptions, émissions, ajustements), surveiller les niveaux de stock et générer des rapports de stock. Le module s’intègre avec le module backend communautaire pour la gestion des stocks pour fournir des capacités complètes de gestion des stocks pour les établissements de santé.

Intégration des utilisateurs

L’application d’intégration des utilisateurs fournit des tutoriels interactifs et des flux de travail d’intégration pour aider les nouveaux utilisateurs à apprendre à utiliser O3. Il comprend des guides étape par étape configurables qui peuvent être personnalisés pour différentes implémentations. Le système d’intégration prend en charge les fonctionnalités de transition automatique, permettant aux tutoriels de progresser automatiquement lorsque des éléments spécifiques apparaissent à l’écran. Cela facilite la création d’expériences d’intégration personnalisées pour leurs utilisateurs, les aidant à comprendre les fonctionnalités et les flux de travail clés dans l’application O3.

Application de référence de distribution

Ce projet contient la configuration de build pour l’application de référence OpenMRS 3.0, disponible sur https://dev3.openmrs.org et https://o3.openmrs.org . La distribution de base se compose de quatre images Docker :

db - C’est simplement l’image MariaDB standard fournie pour être utilisée comme base de données
backend - Cette image est le backend OpenMRS. Elle est construite à partir du Dockerfile principal inclus dans la racine du projet et basée sur le fichier Docker core OpenMRS. Le contenu supplémentaire pour cette image est tiré du sous-répertoire distro qui inclut une configuration complète Initializer pour l’application de référence destinée comme point de départ.
frontend - Cette image est un simple conteneur nginx qui intègre le frontend 3.x, y compris les modules décrits dans frontend/spa-assemble-config.json.
gateway - Cette image est un proxy inverse nginx qui se situe devant les conteneurs backend et frontend et fournit une interface commune aux deux. Cela aide à atténuer les problèmes CORS.

Lorsque l’overlay SSL est activé, la distribution inclut aussi un service certbot pour générer et renouveler les certificats.

Packages de contenu

Les packages de contenu sont des artéfacts Maven qui regroupent les métadonnées sous forme de fichiers de configuration. Ils sont référencés dans distro.properties et chargés automatiquement lorsque le backend démarre. Les packages de contenu peuvent inclure à la fois des métadonnées backend (chargées par le module Initializer) et des fichiers de configuration frontend.

L’application de référence utilise deux packages de contenu :

Reference Application Content - Contient les métadonnées de base nécessaires pour exécuter O3. Cela inclut la configuration essentielle telle que le tag “Login Location”, les ensembles de concepts CIEL et d’autres métadonnées de base requises pour que le système fonctionne. C’est le package de contenu minimum requis.
Reference Application Demo Content - Contient des métadonnées de démonstration/kit de démarrage optionnelles, y compris les laboratoires, les diagnostics, les médicaments et d’autres données d’exemple utiles pour les démonstrations et les démarrages rapides. Ce package inclut également la configuration frontend pour la configuration des slots d’extension. Ceci est optionnel et principalement utilisé à des fins de démonstration.

Les packages de contenu sont chargés par le module OpenMRS Initializer et peuvent être personnalisés ou étendus pour des implémentations spécifiques. Ils fournissent un moyen standardisé de partager les configurations de métadonnées entre différentes instances OpenMRS.

Outils d’administration

Initialement conçus comme une interface utilisateur pour les outils d’administration existants, les outils d’administration fournissent une page intermédiaire qui relie l’utilisateur aux applications EMR non-essentielles telles que le générateur de cohortes, le générateur de formulaires, l’interface d’administration existante, la page de gestion OCL, et plus encore. Il contient également le module frontend OCL.

Générateur de cohortes

Le générateur de cohortes utilise le module de Compatibilité des Rapports pour permettre aux utilisateurs d’effectuer des requêtes ad-hoc pour les patients ayant des caractéristiques définies et de combiner plusieurs requêtes en des requêtes plus complexes.

Gestion des Modules

Le module frontend de gestion des modules est destiné à servir de ressource d’apprentissage pour nos conventions de codage et nos meilleures pratiques lors de la construction d’un micro frontend.

Cette application est basée sur la page de gestion des modules d’administration système de l’application de référence 2.x existante. Elle permet aux utilisateurs de gérer les modules. Elle liste tous les modules installés et permet aux utilisateurs administrateurs de contrôler les modules en utilisant les actions Démarrer, Arrêter et Décharger. Les utilisateurs peuvent également consulter des informations détaillées sur les modules listés. Cela inclut des métadonnées telles que l’auteur du module, la version, la version OpenMRS requise, et plus encore.

RFC Frontend

Un dépôt où sont expliquées les technologies et les processus qui s’appliquent à toutes les nouvelles distributions OpenMRS. L’objectif de ce dépôt est de :

Fournir un moyen d’apporter des changements dans le frontend OpenMRS.
Clarifier les points sur lesquels nous sommes alignés dans tout OpenMRS afin que tout le reste puisse être décidé par les modules et distributions individuels.

Le processus RFC a réussi à mettre en place l’architecture frontend, et les pull requests fusionnées constituent une excellente ressource pour quiconque souhaite comprendre comment nous en sommes arrivés là où nous sommes aujourd’hui.

Schémas JSON

Un dépôt qui héberge les schémas JSON standards utilisés dans OpenMRS. Ces schémas sont ensuite publiés via une URL accessible sur le web. Par exemple, le schéma des routes standard est utilisé pour fournir des capacités d’auto-complétion et de validation lors de l’édition d’un fichier routes.json dans votre IDE.