Des flux standards d'abord pour votre service ambulatoire.
The Clinic parle les standards avec lesquels votre équipe d'intégration travaille déjà — FHIR R4 validé en CI contre le validateur officiel HL7, HL7 v2.5 avec l'ensemble complet d'événements NABIDH, et un serveur DICOMweb en direct vers lequel vos appareils d'imagerie poussent. Les rails d'assurance sont implémentés par juridiction et s'activent une fois l'inscription auprès du régulateur achevée.
Construit sur les standards, pas autour.
Les événements cliniques se mappent en messages standards : ressources FHIR R4 validées en CI, messages HL7 v2.5 lintés et vérifiés ACK contre la spécification NABIDH v4.9 de la DHA, et examens DICOM acceptés directement depuis vos appareils.
Appareils et payeurs
- Appareils d'imagerie et PACS
- Rails d'assurance et payeurs
- Échange d'informations de santé
The Clinic
- FHIR R4, validé en CI
- Pipeline de publication HL7 v2.5
- DICOMweb — STOW · WADO · QIDO
Patients, cliniciens, administrateurs
- Portail patient
- Application clinicien
- Console d'administration
Les rails d'assurance et les connexions HIE sont implémentés par juridiction — NPHIES, eClaimLink et OHIP — et passent en production après l'inscription et les tests de conformité propres au régulateur.
Ambulatoire
Des cliniques ambulatoires enfin modernes.
La plupart des systèmes hospitaliers ont été conçus pour l'hospitalisation. The Clinic offre aux équipes ambulatoires et de soins externes une planification rapide, des notes structurées et une expérience patient à la hauteur de ce que les gens attendent en 2026 — avec les données de chaque clinique strictement isolées à la couche base de données.
- Planification avec vérification de conflits et remplissage automatique par liste d'attente
- Libre-service 24/7 avec rappels par SMS, WhatsApp et e-mail
- Résultats et documents publiés vers NABIDH via ORU et MDM
- Connexion Google ou e-mail et mot de passe, avec authentification à deux facteurs imposée par l'admin
Départements de spécialité
Des départements de spécialité, avec leurs propres règles.
La dentisterie et la physiothérapie reçoivent chacune une édition construite pour elles — charting au niveau de la dent, examens paro et plans de traitement échelonnés d'un côté ; un atlas anatomique bilingue, une bibliothèque de 202 exercices et un suivi de l'assiduité de l'autre — sans dupliquer votre installation.
- Les éditions de spécialité configurent onglets, valeurs par défaut et fonctions par clinique
- Visionneuse d'imagerie avec annotations et constatations assistées par IA
- Les appareils s'appairent une fois et poussent les examens via DICOMweb (STOW-RS)
- Permissions par rôle avec restrictions par utilisateur en retrait uniquement
Cycle de revenus
Des demandes sur le rail que votre régulateur impose.
NPHIES pour l'Arabie saoudite, eClaimLink pour Dubaï et OHIP pour l'Ontario sont implémentés dans le produit. NPHIES couvre l'admissibilité, la pré-autorisation, les demandes de remboursement et les rémittences ; eClaimLink dépose les demandes et les demandes préalables ; OHIP construit le lot de demandes MCEDT et le transmet une fois les identifiants de conformité du ministère configurés. Les identifiants des rails sont chiffrés par clinique, et l'inscription et les tests de conformité propres au régulateur constituent la dernière porte avant les demandes en production.
- Admissibilité, pré-autorisation, demandes et rémittences basées sur FHIR via NPHIES
- Dépôt de demandes et demandes préalables eClaimLink (DHPO) pour Dubaï
- OHIP construit le lot de demandes MCEDT pour l'Ontario
- Un rapport de préparation montre exactement ce qui reste avant la mise en production
Conçu pour celles et ceux qui gèrent l'informatique hospitalière.
Les primitives d'intégration, d'identité et de gouvernance que vos équipes sécurité et architecture attendent — documentées et auditables.
Messagerie HL7 v2.5
L'ensemble complet d'événements exigé par NABIDH — ADT, ORU, MDM, VXU et PPR — avec linting des messages et analyse des ACK vérifiés contre la spécification DHA v4.9.
Constructeurs FHIR R4
Ressources cliniques et de demandes construites côté serveur et validées en CI contre le validateur officiel HL7 à chaque changement.
Identité et accès
Connexion Google ou e-mail et mot de passe. Contrôle centralisé des accès : onze rôles, restrictions par utilisateur en retrait uniquement, authentification à deux facteurs imposée par l'admin avec période de grâce, et une seule politique d'expiration de session appliquée sur chaque chemin d'authentification.
Imagerie DICOMweb
Ingestion STOW-RS authentifiée par jetons révocables par appareil, récupération WADO-RS et recherche QIDO-RS — appairage dans les paramètres, sans appliance VPN.
Audit et rétention
Les événements d'administration et sensibles sont enregistrés avec persistance complète des champs, et la rétention est appliquée selon un calendrier par la plateforme — pas par de bonnes intentions.
Isolation des locataires
Chaque requête est délimitée à votre clinique à la couche ORM et de nouveau par la sécurité au niveau des lignes de PostgreSQL, avec un chiffrement par enveloppe par clinique.
Audité, attesté, prêt pour les contrats.
- types d'événements HL7 v2.5 dans l'ensemble NABIDH
- 5types d'événements HL7 v2.5 dans l'ensemble NABIDH
- rails d'assurance implémentés — NPHIES, eClaimLink, OHIP
- 3rails d'assurance implémentés — NPHIES, eClaimLink, OHIP
- services DICOMweb — STOW, WADO, QIDO
- 3services DICOMweb — STOW, WADO, QIDO
- rôles sous un registre central de permissions
- 11rôles sous un registre central de permissions
Le chemin vers la mise en production.
SaaS géré avec une isolation stricte par clinique. Voici comment un service ambulatoire démarre — et ce qui reste honnête en chemin.
Configurer votre juridiction
Les paramètres régionaux pilotent les rails.
Réglez la juridiction de la clinique et la plateforme sélectionne la passerelle, les jeux de codes et les valeurs régionales par défaut correspondants. Les identifiants des rails sont stockés chiffrés, par clinique.
- Sélection de passerelle consciente de la juridiction
- Identifiants de rails chiffrés par clinique
- Jeux de codes et grilles tarifaires régionaux
Connecter appareils et canaux
Appairer une fois, pousser pour toujours.
Appairez les appareils d'imagerie pour la poussée DICOMweb, connectez SMS, WhatsApp et e-mail sur vos propres identifiants, et imposez l'authentification à deux facteurs au personnel avant la réservation du premier patient.
- Appairage d'appareils DICOMweb avec jetons révocables
- SMS, WhatsApp et e-mail sur les identifiants de la clinique
- Authentification à deux facteurs TOTP imposée par l'admin
Vous inscrire auprès de votre régulateur
Les rails s'activent après l'inscription.
NPHIES, eClaimLink et OHIP sont implémentés dans le produit. L'inscription et les tests de conformité du régulateur constituent la dernière porte — le rapport de préparation suit chaque écart restant.
- NPHIES — Arabie saoudite
- eClaimLink (DHPO) — Dubaï
- OHIP — Ontario
Questions de l'informatique hospitalière
Ce que les équipes d'intégration demandent d'abord.
Quelle version de FHIR la plateforme prend-elle en charge ?
FHIR R4. Les ressources cliniques et de demandes sont construites côté serveur et validées en CI contre le validateur officiel HL7 à chaque changement, si bien qu'une ressource qui viole la spécification fait échouer la build au lieu d'apparaître dans votre intégration.
Nos appareils d'imagerie peuvent-ils pousser les examens directement ?
Oui, via DICOMweb. Les appareils s'appairent une fois dans les paramètres et poussent les examens avec STOW-RS, authentifiés par des jetons par appareil que vous pouvez révoquer. La récupération passe par WADO-RS, la recherche par QIDO-RS, et aucune appliance VPN ne s'interpose.
Publiez-vous des événements cliniques vers un échange d'informations de santé ?
La plateforme exploite un pipeline de publication HL7 v2.5 sortant couvrant l'ensemble d'événements exigé par NABIDH — ADT, ORU, MDM, VXU et PPR — avec linting des messages et analyse des ACK vérifiés contre la spécification DHA v4.9. Les résultats et documents sont publiés vers NABIDH via des messages ORU et MDM.
Comment les demandes de remboursement sont-elles soumises ?
Le rail suit la juridiction de la clinique : NPHIES pour l'Arabie saoudite couvre l'admissibilité, la pré-autorisation, les demandes de remboursement et les rémittences ; eClaimLink dépose les demandes et les demandes préalables pour Dubaï ; OHIP construit le lot de demandes MCEDT pour l'Ontario. Les rails passent en production après l'inscription et les tests de conformité propres au régulateur, et un rapport de préparation suit ce qui reste avant la mise en production.
Les départements de spécialité peuvent-ils exécuter leurs propres flux ?
La dentisterie et la physiothérapie exécutent des éditions construites pour elles — charting au niveau de la dent, examens paro et plans de traitement échelonnés d'un côté ; un atlas anatomique bilingue, une bibliothèque de 202 exercices et un suivi de l'assiduité de l'autre. Les éditions configurent onglets, valeurs par défaut et fonctions par clinique, sans dupliquer votre installation.
Prêt à essayer The Clinic
Voyez-le piloter votre clinique en 30 minutes.
Réservez une démo personnalisée. Nous utiliserons les véritables flux de travail de votre clinique — pas une visite générique.
Aucune carte bancaire. Aucune diapositive. 30 minutes.