1. OceanMD
  2. Intégrations
  3. Intégrations API

Intégrations API

Print Guide
S’abonner

Guide de configuration de l'intégration des eRéférences HL7 FHIR

Commencer avec l'intégration

Les fournisseurs de services peuvent gérer les eRéférences Ocean dans leur dossier médical électronique (DMÉ) du patient ou leur système de gestion de clients (CMS) grâce à l'intégration avec Ocean. L'intégration permet :

  • Que les eRéférences apparaissent dans le DMÉ/CMS sans nécessiter d'activité initiale dans le portail Ocean
  • Que les mises à jour d'état de l'eRéférence (par exemple, acceptée, réservée, annulée) soient envoyées à Ocean (ce qui entraînera une notification au fournisseur et au patient)
  • Que les mises à jour de la démographie de base du patient soient envoyées à Ocean
  • Que les communications liées à la référence soient ajoutées à la référence (par exemple, instructions pour le patient ou le fournisseur, pièces jointes)

Ocean prendra en charge deux versions de l'API d'eRéférence FHIR : v0.10.0 et v0.11.1. Les nouveaux intégrateurs sont fortement encouragés à utiliser la v0.11.1. Les intégrateurs existants qui s'étendent à de nouveaux sites peuvent continuer à utiliser la v0.10.0.

Réception des références d'Ocean

Le guide de configuration suivant vise à fournir aux développeurs de logiciels les étapes préliminaires nécessaires pour préparer un site Ocean à l'intégration avec un DMÉ/CMS. Des détails supplémentaires pour chaque étape sont fournis dans les articles de support liés. L'achèvement de ces étapes permettra de tester la connectivité non authentifiée et la réception du lot de ressources eRéférence FHIR HL7 d'Ocean.

  1. Envoyez un courriel à Soutien Ocean avec le domaine de courriel que vous utiliserez pendant le développement technique et les tests (par exemple, pour enregistrer de nouveaux utilisateurs, recevoir des notifications de référence, etc.). Veuillez identifier le nom de votre entreprise et le parrain du projet d'intégration (par exemple, une organisation clinique ou juridictionnelle).
  2. Créez un compte utilisateur Ocean et un site sur test.cognisantmd.com
  3. Générez la clé de chiffrement partagée (SEK) du site.
  4. À partir du Menu, sélectionnez Admin puis sélectionnez Fonctionnalités du site. Activez l'option "Activer Ocean Cloud Connect". Cela déclenchera une boîte de dialogue vous indiquant de configurer Cloud Connect. Sélectionnez le bouton "Aller à Cloud Connect".
  5. Dans Cloud Connect, sélectionnez "Conserver ma clé de chiffrement". (N'accédez pas à l'option "Intégrer avec mon DMÉ".) Entrez la SEK du site et sélectionnez 'Sauvegarder'
  6. Configurez le point de terminaison API pour votre DMÉ/CMS - onglet HL7 FHIR eRéférence > Étape 1
  7. Configurez l'annuaire des services pour votre site - complétez les détails de base pour l'inscription et sous "Politique d'eRéférence", activez 'Accepter les eRéférences'.
  8. Établissez un lien entre l'annuaire des services et le point de terminaison API - onglet HL7 FHIR eRéférence > Étape 2.
  9. Ajoutez les adresses IP de test.cognisantmd.com Ocean à votre liste d'autorisations.
  10. Si vous souhaitez que Ocean vous envoie des notifications par courriel lorsqu'il reçoit une réponse d'erreur de votre point de terminaison, à partir du Menu, sélectionnez Admin puis sélectionnez Compte du site. Dans le champ "Administrateur clinique / Contact de soutien Ocean", saisissez l'adresse courriel du(des) destinataire(s) de la notification d'erreur.
  11. Créez un deuxième site (en accédant à Mon compte (menu en haut à droite) et en cliquant sur 'Créer un nouveau site'. (Cela vous permettra de reproduire le flux de travail de référence réel d'une référence envoyée de et vers un site Ocean au site 'fournisseur de services' pris en charge par votre intégration. Vous n'avez qu'à compléter).
  12. Dans le deuxième site ('expéditeur'), recherchez l'inscription de l'annuaire du 'fournisseur de services' (du premier site) dans Healthmap Ocean et soumettez une eRéférence.
  13. Suivez ces instructions pour vous abonner à la section Mise à jour de l'intégration API Ocean afin de recevoir des notifications critiques spécifiques aux incidents d'intégration.

Vous êtes maintenant prêt à recevoir des eRéférences!

Traitement des lots de messages d'eRéférence HL7 FHIR

  1. Pour en savoir plus sur les cas d'utilisation, le flux d'intégration, les méthodes et le profilage des ressources FHIR, veuillez consulter le Guide de mise en œuvre HL7 FHIR de l'eRéférence Ontario v0.10.0, pour la version v0.10.0. Pour en savoir plus sur la version bêta v0.11.1, veuillez consulter Guide de mise en œuvre HL7 FHIR de l'eConseil - Brouillon v0.11.1 de l'eRéférence Ontario 
  2. Pour voir comment ces éléments sont mis en œuvre par Ocean, veuillez consulter notre documentation de l'API HL7 FHIR.
  3. Un compagnon important de cette documentation est notre article sur les directives de mise en œuvre de l'API HL7 FHIR de l'eRéférence, qui décrit les concepts clés et les considérations dont vous devez être conscient lors du développement de votre intégration.

 

Envoi de mises à jour de référence à Ocean

Pour que le DMÉ/CMS envoie des mises à jour à Ocean, les étapes de configuration supplémentaires suivantes sont nécessaires. Les API HL7 FHIR qui prennent en charge le cycle de vie du message de l'eRéférence sont décrites dans une documentation API distincte.

  1. Configurer les informations d'identification OAuth2 spécifiques au site pour communiquer avec Ocean - Onglet HL7 FHIR eRéférence > Étape 3.

 

 

Guide de mise en œuvre de l'API eRéférence HL7 FHIR

Nous avons hâte de communiquer avec vous !

Le but de cet article est d'accélérer vos activités de mise en œuvre de l'eRéférence HL7 FHIR en partageant des conseils et des considérations recueillis auprès d'autres mises en œuvre de l'eRéférence HL7 FHIR Ocean. Il est divisé en sections suivantes :

  • Documentation d'authentification - liée à la mise en œuvre de l'OAuth2 d'Ocean
  • Documentation de l'API - liée à la mise en œuvre de l'eRéférence HL7 FHIR de l'Ontario par Ocean
  • Mapping des données - conseils sur l'intention et l'utilisation des différents champs de ressources FHIR dans le contexte de la mise en œuvre d'Ocean
  • Considérations techniques - choses à considérer lors du développement de vos APIs
  • Mise en œuvre et tests - conseils pour évaluer le comportement de l'intégration dans Ocean

Cet article de support sera "vivant" car des conseils supplémentaires seront recueillis. Il est recommandé de suivre ce guide afin de recevoir une notification lors de sa mise à jour (voir : 'Rester à jour avec les mises à jour des fonctionnalités d'Ocean' ).

Ocean prendra en charge deux versions de l'API d'eRéférence FHIR : v0.10.0 et v0.11.1. Les nouveaux intégrateurs sont fortement encouragés à utiliser la v0.11.1. Les intégrateurs existants qui s'étendent à de nouveaux sites peuvent continuer à utiliser la v0.10.0.

Définitions utilisées dans cet article

  • Demandeur - l'individu (fournisseur ou patient) qui soumet une demande de référence.
  • Fournisseur de services - le service/organisme/fournisseur clinique ou communautaire qui reçoit une demande de référence pour fournir un service au patient
  • Cible RMS - le(s) système(s) en aval d'Ocean qui reçoit et agit sur une eRéférence.
  • ID de demande de service - cela correspond dans les messages FHIR à l'identificateur de référence d'Ocean
  • ID de site - l'identificateur d'Ocean pour le site mis en place par le fournisseur de services dans Ocean pour envoyer et/ou recevoir (et gérer) des eRéférences
Documentation d'authentification
  • Pour définir les informations d'identification OAuth2 dans le Portail Ocean, vous devez disposer de la Clé de chiffrement partagée du site (SEK) (voir l'étape 2 de l'article suivant : Guide de configuration de l'intégration HL7 FHIR eRéférence). Si vous ne l'avez pas déjà, l'administrateur du site Ocean peut vous la fournir ou vous pouvez la récupérer depuis Cloud Connect. Consultez le guide suivant pour plus d'informations Récupération d'une clé de chiffrement partagée perdue / oubliée
  • L'URL pour la demande de jeton d'accès OAuth2 dans l'environnement de test d'Ocean est 
    https://test.cognisantmd.com/svc/oauth2/token
    (le Documentation du serveur d'autorisation OAuth 2.0 fait référence à l'environnement de production).
  • Ocean renvoie les codes d'erreur standard 401/403 en cas d'erreurs liées à l'autorisation pour l'accès à nos points de terminaison sécurisés via OAuth2.
  • Si vous êtes bloqué dans l'échange de jetons OAuth2, cela peut être réinitialisé par l'administrateur du site. Ils peuvent accéder à Admin du site > Informations d'identification du site > page des informations d'identification OAuth et cliquer sur l'icône du cadenas.
Documentation de l'API

Guide de mise en œuvre de l'eRéférence en Ontario :

  • Les API FHIR de l'eRéférence d'Ocean sont conformes à la version 0.10.0 du Guide de mise en œuvre de l'eRéférence en Ontario.
  • Il existe une version plus récente (v0.10.1) qui introduit des "changements majeurs" (c'est-à-dire non rétrocompatibles) dans l'ensemble de valeurs MessageEventCode, qui ne sont pas pris en charge par Ocean pour le moment.

Section Profils et Opérations :

  • Le guide de mise en œuvre de l'eRéférence en Ontario comporte une section Profils et Opérations qui inclut des liens vers une documentation de profilage spécifique pour chaque ressource FHIR utilisée dans la spécification.
  • Chaque profil liste pour chaque champ s'il est requis, la cardinalité requise, les valeurs énumérées acceptées le cas échéant, les invariants spécifiques et toute autre information pertinente qui y est associée.
    • Exemple : Le champ de télécommunication dans la ressource Patient est requis, et les sous-champs système, valeur et utilisation sont requis, mais pas les sous-champs rang ou période.

Extension FHIR d'Ocean

  • L'implémentation d'Ocean utilise trois extensions FHIR.
    1. "http://ehealthontario.ca/fhir/StructureDefinition/ext-id-message-header" dans la ressource MessageHeader
    2. "http://ehealthontario.ca/fhir/StructureDefinition/ext-id-health-card-version-code" dans la ressource Patient
      • Les deux premières sont spécifiées dans le profilage des ressources v0.10.0.
    3. "https://ocean.cognisantmd.com/svc/fhir/v1/CodeSystem/ontario-clinical-wait-time-codes" dans la ressource Rendez-vous du notify-add-appointment et notify-update-appointment messages. 
      • La troisième (pour les temps d'attente) a été ajoutée pour répondre aux besoins du Programme des services électroniques de l'Ontario.

Calcul des temps d'attente :

  • Ocean calcule les temps d'attente pour chaque répertoire de référencement et les affiche dans la Healthmap d'Ocean.
  • L'extension FHIR pour les temps d'attente doit être envoyée dans la ressource Rendez-vous pour qu'Ocean mette à jour le temps d'attente en conséquence.
    • Exemple : Lorsqu'une date de rendez-vous est soumise avec l'extension définie sur "wait-1", Ocean utilisera cette date comme date de la première consultation avec le fournisseur de services de santé dans les calculs de temps d'attente.
      • L'extension devrait être définie sur "wait-1a" si le rendez-vous est l'évaluation initiale de dépistage plutôt que la consultation réelle.

Gestion des Réponses/Erreurs

  • Les messages réussis renverront un code de réponse 200, indiquant qu'Ocean a reçu et traité avec succès la référence.
  • Les messages qu'Ocean ne peut pas traiter pour une raison quelconque (mauvaises données, données manquantes, JSON non analysable, etc.) renverront un code de réponse 40X/50X avec une Ressource FHIR OperationOutcome comme corps qui aura une description de l'erreur. Il inclut une section "problèmes" où le serveur présentera des informations de débogage lisibles par l'homme pour aider à déterminer la raison pour laquelle l'erreur a été émise.
    • Ces informations peuvent être n'importe quoi, des erreurs d'analyse JSON, des erreurs de validation de spécification (champs requis manquants ou utilisation de mauvais types de données), des erreurs de logique métier (par exemple, essayer de mettre à jour une référence qui n'existe pas) et des exceptions de traitement interne de notre part (généralement des bogues).
    • Avec ces informations et la réponse d'erreur, il y a généralement assez d'éléments pour essayer de trouver efficacement le problème sous-jacent.

Ressource de tâche :

  • Ocean n'envoie pas de ressource de tâche dans aucun de ses messages. La ressource de tâche est uniquement envoyée par le système cible RMS pour indiquer comment la demande de service originale a été traitée par le système cible RMS. La documentation de l'API inclut des exemples de la ressource de tâche dans les événements de message entrants envoyés à Ocean par le système cible RMS.

Champs démographiques :

  • Ocean ignorera tout champ démographique vide envoyé dans le message 'mise à jour de la demande de service' du système cible RMS (plutôt que de remplacer/supprimer la valeur existante).

Adresses des patients :

  • Si le système cible RMS envoie à Ocean deux adresses de patient FHIR, Ocean les stockera toutes les deux mais n'affichera que la première dans la charge utile.
  • Si plus de deux adresses sont envoyées, Ocean ignorera toutes sauf les deux premières.

Jeton OAuth2 :

  • Le jeton OAuth2 envoyé par le système cible RMS fournit à Ocean les informations nécessaires pour déterminer à quel site appartient le message (puisque chaque modèle de jeton est spécifique au site). C'est pourquoi l'ID du site Ocean n'a pas besoin d'être transmis dans la charge utile.

RefID :

  • Le RefID est utilisé par Ocean pour déterminer à quelle eRéférence spécifique la charge utile se réfère dans le site Ocean.

Ressources de rôle de praticien :

  • Le bundle contiendra deux ressources PractitionerRole, l'une décrivant le demandeur et l'autre décrivant le fournisseur de services.
  • Les liens dans la demande de service/MessageHeader établissent quelle ressource est connectée à chaque praticien.
  • Les identifiants de numéro de facturation basés sur notre modèle de données Clinician ont été intégrés dans nos ressources FHIR Practitioner au sein des API sortantes. Pour garantir une solution complète, cette mise à jour a maintenant été étendue au traitement des API entrantes. Par conséquent, définir les numéros de facturation sur les objets cliniciens lors de l'arrivée des praticiens FHIR est désormais pris en charge de manière transparente.
  • Certaines références et consultations Ocean impliquent un autre acteur (par exemple, un secrétaire médical, un résident) qui soumet la demande au nom du clinicien. Dans ce cas, il y a un autorisateur de la demande et un soumetteur de la demande. La charge utile FHIR inclura une troisième ressource Practitioner et PractitionerRole dans le bundle pour le soumetteur, (avec l'autorisateur et le destinataire). Voici des exemples de la façon dont les informations du soumetteur et de l'autorisateur seront renseignées dans la charge utile:
     

    MessageHeader.sender

    ServiceRequest.requester

    MessageHeader.author
    Assistant médical PA envoyant une référence sous la supervision du médecin Dr. D PA Dr. D Dr. D
    Résident R envoyant une référence sous la supervision du médecin Dr. D R Dr. D Dr. D
    Infirmière praticienne NP envoyant une référence (ordonnant une IRM) sous la supervision du médecin autorisant Dr. Digley NP Dr. D Dr. D
    Secrétaire médical MOA envoyant une référence en tant que délégué sous la supervision du Dr. D MOA Dr. D Dr. D

Identifiant du référent :

  • L'identifiant du référent n'est pas garanti d'être unique. Cela est dû au fait que le référent peut avoir créé la référence sans se connecter à un compte utilisateur Ocean (par exemple, directement depuis Healthmap Ocean), donc Ocean peut ne pas être en mesure d'attribuer un identifiant unique.

Document de référence :

  • Chaque bundle de demande de service inclura un Document de référence pour récupérer une copie PDF de l'eRéférence Ocean.
  • Si le demandeur inclut des pièces jointes dans l'eRéférence, celles-ci seront ajoutées au bundle en tant que ressources Document de référence distinctes. Dans ce cas, la copie PDF de l'eRéférence sera toujours la première ressource Document de référence incluse dans le bundle.

Type de contenu de la pièce jointe :

  • Conformément à la spécification HL7 FHIR eRéférence, il n'est pas obligatoire de préciser le type de contenu/MIME d'une pièce jointe à l'eRéférence.

  • Ocean fournira l'information si elle est connue, mais les systèmes récepteurs ne doivent pas supposer qu'elle sera toujours disponible ou qu'il s'agira d'un type de contenu spécifique (par exemple, PDF), car les demandeurs peuvent inclure d'autres pièces jointes (par exemple, des images).

Récupération du résumé de la référence et des pièces jointes :

Limites de taille des pièces jointes :

  • Les API d'Ocean acceptent des tailles de pièces jointes/fichiers allant jusqu'à 10 Mo par fichier et jusqu'à un maximum de 50 Mo de pièces jointes pour une référence.
  • Ocean renverra une réponse d'erreur au point de terminaison d'envoi si les pièces jointes dépassent ces limites.
  • Les systèmes intégrés sont responsables de notifier leurs utilisateurs en cas d'erreur (par exemple, afficher un avertissement à l'utilisateur indiquant que les pièces jointes ont dépassé les limites acceptables).

Mode Test :

  • Les cibles de référence d'Ocean ont la possibilité de définir leur répertoire de listage (dans la section Avancé de la liste) en 'Mode Test eRéférence'. Cela signifie que toutes les références définies dans cette liste seront traitées comme des patients fictifs.
  • Pour indiquer qu'une charge utile FHIR correspond à une référence de test, Ocean ajoutera la propriété  meta.security = HTEST à chaque ressource dans le bundle.
Cartographie des données

Démographie obligatoire pour les eRéférences dans Ocean :

      • Ocean envoie les données démographiques de base du fournisseur suivantes pour chaque eRéférence :
  • Les données démographiques suivantes sont obligatoires pour soumettre une eRéférence dans Ocean et doivent être présentes dans la ressource Patient :
    • Prénom(s)
    • Nom de famille
    • Date de naissance
    • Adresse (champ de rue)
    • Ville
    • Un champ de contact téléphonique (mobile, fax ou professionnel).

Gestion des valeurs nulles :

  • Ocean n'envoie pas de valeur 'nulle' lorsque le champ n'a pas été renseigné.

Champ de sexe :

  • L'objet Patient standard FHIR R4 prend en charge les quatre valeurs AdministrativeGender suivantes pour sa valeur "sexe" : "masculin", "féminin", "autre" et "inconnu". Par conséquent, Ocean utilise "inconnu" lorsque la valeur fournie dans la section "Sexe" est laissée vide, "masculin" et "féminin" lorsque ces choix sont sélectionnés, et "autre" lorsque toute autre valeur est fournie. Les fournisseurs de services peuvent inclure des valeurs plus flexibles ou spécifiques selon les besoins cliniques en utilisant le corps du formulaire de demande de service.

Champ HN-Province et Identificateur HN :

  • Ocean vérifie si le champ HN-province est renseigné avec un code alpha provincial standard à deux lettres (par exemple, ON, PE).  Si c'est le cas, l'identificateur JHN aura un système de dénomination comme

    https://fhir.infoway-inforoute.ca/NamingSystem/ca-XX-patient-hcn où XX est le code alpha à deux lettres et le champ d'utilisation de l'identificateur sera défini sur OFFICIEL.

Saisie des systèmes d'identificateurs :

  • Les utilisateurs sont invités à saisir le nom du système d'identificateur dans le champ de province lorsqu'ils soumettent un numéro d'identification autre qu'un numéro d'assurance maladie provincial. Par exemple, ils saisiront "ID militaire" dans le champ HN-province et le numéro d'identification dans le champ d'assurance maladie. Ocean fournira la valeur saisie dans le champ HN-province en tant qu'identificateur de santé secondaire et définira le champ d'utilisation de l'identificateur JHN sur SECONDAIRE.
  • Ocean ne valide pas si le numéro d'identification soumis appartient au système d'identification (par exemple, il ne vérifie pas la somme de contrôle des numéros d'assurance maladie provinciaux).

Catégories de services de santé :

  • Les catégories de services de santé utilisées pour identifier les services offerts pour chaque annonce répertoriée dans l'annuaire sont mappées à SNOMED CT et LOINC.
  • Une liste principale des catégories et des mappages est disponible en bas de cet article (fournie en PDF et .xlsx).

Données du formulaire de référence :

  • Le corps du formulaire de référence (par exemple, Allergies, Antécédents médicaux et toutes les questions ajoutées par le fournisseur de services cliniques à leur formulaire de référence Ocean) sera envoyé dans la ressource QuestionnaireResponse sous forme de paire clé-valeur.
  • Ocean ne contrôle pas ni ne limite les noms de clés créés par le fournisseur de services. Par conséquent, si vous avez l'intention de mapper les réponses de champs spécifiques du formulaire de référence dans les champs cibles RMS, vous devrez coordonner avec le fournisseur de services sur les noms de clés. (Cela est défini dans le champ de légende de la question, qui est décrit dans l'onglet Général de l'article suivant : Guide de l'éditeur de formulaire électronique - Ajouter un élément.)

État du cycle de vie de l'eRéférence :

  • Le tableau ci-dessous illustre les états du cycle de vie de l'eRéférence qui peuvent être communiqués par le RMS Target à Ocean et l'état interne de l'eRéférence Ocean correspondant.
  • L'état est communiqué par Ocean dans le champ État de la ressource ServiceRequest et est mis à jour par le RMS Target dans le champ État de la ressource Tâche.

Ressource Patient :

  • Une ressource Patient qui inclut l'adresse e-mail du patient doit être envoyée dans l'événement de message entrant à Ocean afin de déclencher des notifications par e-mail au patient.
  • L'onglet Patient du guide de support suivant : Où les e-mails de notification d'eConseil et/ou d'eRéférence sont-ils envoyés ? liste quand les changements d'état dans Ocean enverront un e-mail (si reçus dans la ressource Patient).

Dates de Rendez-vous Multiples :

  • Si le site permet plusieurs dates de rendez-vous pour une seule référence, la liste de références devrait avoir plusieurs étiquettes configurées.
  • Par défaut, Ocean active uniquement une seule étiquette pour chaque liste nommée "Rendez-vous". Chaque liste de références (Administrateur du site > Répertoire des services > Section Détails du service) peut être configurée par l'administrateur du site pour ajouter des étiquettes supplémentaires parmi les valeurs suivantes : rendez-vous 1 - 5, date de consultation, date de suivi, date de première visite, date de procédure, date de chirurgie.
  • Il est fortement recommandé d'utiliser uniquement ces valeurs dans le champ textuel Appointment.appointmentType.text lors de la création et de la mise à jour d'un rendez-vous en utilisant les messages API.
  • Aussi, pour des raisons sémantiques, les seules étiquettes Ocean pouvant être utilisées pour stocker l'attente 2 sont Date de procédure et Date de chirurgie.

État de Réservation dans Ocean :

  • Le renvoi est mis à jour à un état "Réservé" dans Ocean (ce qui correspond au dossier 'Réservé non confirmé' dans le portail Ocean) une fois qu'il reçoit les données de rendez-vous du RMS dans l'événement de message 'ajouter-notifier-rendez-vous'.
  • Le renvoi peut être directement déplacé à l'état 'Confirmé' dans Ocean (ce qui correspond au dossier 'Réservation confirmée' dans le portail Ocean) si une ressource Patient est référencée dans le champ Appointment.participant.actor et que le statut de l'acteur du rendez-vous est défini sur accepté . 
    • Note : Si un renvoi passe directement de l'état Nouveau ou Accepté à l'état Réservation confirmée, Ocean n'enverra pas d'e-mail au patient lui demandant de confirmer son rendez-vous.

Instructions par courriel de rendez-vous pour le patient :

  • Les instructions pour le courriel de rendez-vous du patient (par ex., instructions de préparation) peuvent être incluses dans le champ Appointment.patientInstruction de l'événement de message 'notifier-ajouter-rendez-vous'.

Spécification du moyen de rendez-vous :

  • Le moyen de rendez-vous (vidéo, téléphone) peut être spécifié dans le champ Location.type qui est référencé par le champ Appointment.participant.actor :
    • Si le moyen est inconnu/non spécifié ou connu pour être en personne :
      Inclure un participant contenant un acteur avec le code "LOC", afficher "Emplacement de la clinique" et une référence à la ressource Emplacement de l'inscription.
    • Si le rendez-vous est basé sur téléphone :
      Inclure un participant contenant un acteur avec le code "LOC", afficher "Visite téléphonique" et une référence "Emplacement/X" à un Emplacement avec l'ID X dans le Bundle. Définir le téléphone de l'Emplacement pour correspondre au numéro de téléphone de l'inscription.
    • Si le rendez-vous est une visite à domicile :
      Inclure un participant contenant un acteur avec le code "HH", afficher "Emplacement du patient" et une référence "Emplacement/X" à un Emplacement avec l'ID X dans le Bundle. Définir l'adresse de l'Emplacement pour correspondre à l'adresse du patient si elle est disponible.
    • Si le rendez-vous est à un emplacement alternatif :
      Inclure un participant contenant un acteur avec le code "LOC", afficher "Emplacement alternatif de la clinique" et une référence "Emplacement/X" à un Emplacement avec l'ID X dans le Bundle.  La ressource Emplacement doit contenir une adresse et sa description doit correspondre à la description de l'emplacement alternatif (par ex., "Emplacement de visite de clinique alternatif : ___"   (REMARQUE : la ressource Emplacement d'exemple fournie dans le fichier zip en bas de la page sera mise à jour pour inclure l'adresse alternative)

Appel API pour les données de rendez-vous :

  • Si un appel API est envoyé avec des données de rendez-vous sans étiquette, alors Ocean assignera la première étiquette de rendez-vous qui n'a pas été utilisée dans ce renvoi pour ce rendez-vous. Si un appel API est envoyé avec des données de rendez-vous sans étiquette, alors Ocean assignera la première étiquette de rendez-vous qui n'a pas été utilisée dans ce renvoi pour ce rendez-vous.
  • Si un deuxième rendez-vous est envoyé sans étiquette et que toutes les étiquettes de rendez-vous ont déjà été assignées pour ce renvoi, l'API renverra une erreur.
  • Alternativement, les données de rendez-vous peuvent être envoyées avec une étiquette de rendez-vous, mais elle doit correspondre à l'une des étiquettes configurées pour ce site.

Champ statut de la tâche :

  • Le message de mise à jour de statut de notification est utilisé pour transmettre à Ocean les valeurs d'état de référence suivantes dans le champ État de la tâche : Accepté, Refusé, Confirmé, Annulé, Terminé, Imprimé, Incomplet, Envoyé.
  • Le champ est facultatif et ne doit être renseigné que par le système tiers lorsque la valeur d'état de référence est différente de la mise à jour précédente envoyée à Ocean.
  • Ocean renverra une erreur de "La référence est déjà dans l'état demandé" si deux mises à jour sont envoyées avec la même valeur d'état. Par conséquent, si l'ensemble interne de statuts de référence du système tiers est plus détaillé que celui d'Ocean, les mises à jour de référence doivent contenir les informations mises à jour pertinentes sans valeur d'état à moins que cela ne modifie l'état de référence d'Ocean.
  • Lors de l'envoi de la ressource Tâche pour mettre à jour l'état de la référence, une raison explicative du changement d'état (par exemple, pourquoi la référence a été refusée) peut être ajoutée en utilisant la propriété texte de Task.businessStatus.

ID de service externe :

  • L'"ID de service externe" dans la liste des répertoires est utilisé comme "id" unique pour le Service de santé. L'administrateur du site peut définir l'ID de service externe comme un ensemble unique de chiffres pouvant être utilisé pour identifier l'inscription dans l'intégration.
Considérations techniques
  • Ocean prend en charge à la fois IPv4 et IPv6
  • Ocean enverra l'ensemble des ressources/bundles de ServiceRequest à chaque mise à jour de l'un des champs de recommandation. La liste des modifications est fournie dans le MessageHeader.reason, qui peut servir de « indices » pour que la cible RMS évalue ce qui a changé. Il revient à la cible RMS de décider quelles mises à jour nécessitent une mise à jour interne et/ou une notification au fournisseur de services.
  • Les événements de mise à jour sont suivis dans notre journal d'audit et déclencheront une notification « mise à jour ». Il est sûr d'ignorer les notifications avec le MessageHeader.reason = ÉVÉNEMENT_ENREGISTRÉ.
  • Il n'est pas nécessaire de fournir une réponse synchrone à la transmission du message de ServiceRequest entrant, autre qu'une réponse HTTP 200 pour indiquer que le message a été reçu avec succès. La prochaine mise à jour d'état asynchrone envoyée à Ocean peut fournir un état plus spécifique pour la recommandation lorsqu'elle est traitée par la cible RMS.
  • Si vous utilisez un seul point de terminaison pour recevoir des bundles de ServiceRequest pour plusieurs sites Ocean, vous pouvez identifier le destinataire prévu en examinant l'Identificateur de ServiceRequest / Performer / PractitionerRole / Identifier, qui contiendra l'ID du site.  
  • L'Identificateur de ServiceRequest doit être renseigné dans la section meta->profile du MessageHeader. Cela est requis pour qu'Ocean puisse identifier les messages entrants comme conformes à la spécification eRéférence HL7 FHIR de l'Ontario v0.10.0 afin qu'ils puissent être traités en conséquence.
  • De même, lorsque la cible RMS devient « opérationnelle » avec l'intégration, les eRéférences préexistantes qui existent dans le site Ocean ne seront pas envoyées à la cible RMS tant qu'elles ne seront pas mises à jour (ce qui déclenchera l'envoi d'une notification webhook par Ocean).
  • Ocean conserve un journal de tous les envois de messages qui peut être utilisé pour déterminer quels messages ont été manqués. Ils peuvent être « forcés » à être renvoyés à la cible RMS en apportant une mise à jour à la recommandation dans le Portail Ocean.
Mise en œuvre et Test
  • À partir du moment où une référence est mise à jour dans Ocean, elle se déplacera entre différents 'dossiers' dans le tableau de bord eRéférence. C'est une façon de voir que la mise à jour de statut envoyée à Ocean a été traitée.
  • Le journal des événements pour chaque référence peut être consulté en ouvrant le dossier de référence et en sélectionnant 'Voir le journal des événements' dans le menu 'Action' en haut à droite. Cela peut aider à déterminer si la référence est mise à jour comme prévu.
  • Lorsque les API Ocean détectent un taux d'erreur d'appel de plus de 5% dans les 20 premières tentatives, elles désactivent automatiquement l'API. Elle peut être réactivée en retournant dans Menu Admin > Intégrations, en ouvrant la configuration d'intégration pertinente, puis en la sauvegardant.
  • Les sites de référence Ocean peuvent offrir aux patients un formulaire de site web d'auto-référence ainsi que la liste eRéférence dans le Healthmap Ocean.
  • Si cela est activé, ces auto-références déclencheront une notification webhook avec un bundle ServiceRequest.
  • Elles peuvent être distinguées des références initiées par le fournisseur de services car ServiceRequest.requester fera référence à une ressource Patient plutôt qu'à une ressource PractitionerRole.
  • Les intégrateurs devraient confirmer avec les parties prenantes commerciales du site s'ils veulent que les auto-références des patients soient traitées de la même manière que les références initiées par le fournisseur de services (par exemple, peuvent-elles créer une nouvelle référence dans la cible RMS/POS ou devraient-elles le faire uniquement une fois qu'elles ont été 'acceptées' dans le Portail Ocean).

Activation des Intégrations Ocean

Les sections ci-dessous décrivent les étapes nécessaires pour activer différents types d'intégrations entre Ocean et vos autres systèmes d'information commerciale afin d'automatiser et de rationaliser les flux d'informations :

  • API eRéférence HL7 FHIR d'Ocean pour recevoir des références et envoyer des mises à jour à Ocean en utilisant le format HL7 FHIR R4
  • API eRéférence ouverte d'Ocean pour recevoir des notifications de référence, récupérer des références et envoyer des mises à jour à Ocean
  • API d'Engagement Patient ouverte d'Ocean pour créer des eFormulaires Ocean spécifiques au patient et les récupérer une fois qu'ils sont terminés.
  • Un Lancement de Système de Référence pour rediriger vers un site web externe afin de compléter une référence qui a été initiée dans Ocean.
  • Une Source de Données Externe pour récupérer des données à partir d'un point de terminaison externe à intégrer dans un eFormulaire Ocean.
  • Crochets CDS Externes pour s'intégrer avec des systèmes externes de support à la décision clinique.
eRéférence HL7 FHIR eRéférence Open API eFormulaires Open API Lancement du système de référence Source de données externe Hooks CDS externes

Étape 1 : Configuration d'un point de terminaison de webhook

  • À partir de la page des Paramètres d'administration, cliquez sur Intégrations> "Enregistrer une intégration."
  • Cliquez sur l'option eRéférences pour le type d'intégration.
  • Pour le Type de charge utile , sélectionnez l'option FHIR.
  • Nommez l'intégration et collez dans le champ URL de la requête l'URL à laquelle Ocean enverra les charges utiles FHIR.
  • Sélectionnez le schéma d'authentification qu'Ocean utilisera pour s'authentifier avec le point de terminaison de votre système et saisissez les paramètres pertinents.
  • Sélectionnez les événements pour lesquels Ocean doit informer votre système et les actions qui peuvent être effectuées une fois la référence envoyée.

Étape 2 : Lier l'annuaire des services à une intégration

  • À partir de la page des Paramètres d'administration, cliquez sur Annuaire des listes> onglet et ouvrez la section Avancé en bas de la page.
  • Les intégrations spécifiées pour le site Ocean seront répertoriées dans le champ Intégration . Sélectionnez celle qui doit être liée à cette liste d'annuaire. Saisissez la même valeur dans le champ ID de service externe .

Votre site Ocean est maintenant prêt à envoyer des eRéférences à votre système de point de service en utilisant les API d'eRéférence HL7 FHIR.

 

Étape 3 : Génération des identifiants OAuth Ocean

Les systèmes doivent envoyer à Ocean un identifiant client spécifique au site et un secret afin de recevoir un ou plusieurs jetons OAuth pouvant être utilisés pour soumettre des mises à jour de références pour ce site Ocean. Pour générer l'identifiant client et le secret :

  • À partir de la page Paramètres administratifs, cliquez sur le bouton Gérer les identifiants > Gérer les identifiants OAuth.
  • Ajoutez un nom significatif et cliquez sur le bouton "Ajouter un nouvel identifiant."
  

Votre site Ocean est maintenant prêt à recevoir des eRéférences de votre système de point de service en utilisant les API d'eRéférence HL7 FHIR.

Configuration des paramètres et des autorisations pour les intégrations API

Ocean offre une grande flexibilité pour effectuer des mises à jour de la référence et recevoir des notifications tout au long du cycle de vie de la référence. Cela peut introduire de la complexité dans une intégration d'API eRéférence entre Ocean et un système en aval. Cet article décrit ces notifications, paramètres et autorisations afin que les implémenteurs puissent évaluer celles qui peuvent être prises en charge par leur intégration.

  • Les notifications, paramètres et autorisations se trouvent sur la page Admin > Intégrations > eRéférence.
  • Après avoir sélectionné "eRéférence", la fenêtre de configuration complète apparaîtra.

Nom de l'Intégration

  • Le nom de l'intégration est utilisé pour identifier l'intégration lors de sa liaison à une ou plusieurs fiches de répertoire.
  • Il est également utilisé pour identifier l'intégration si le site a plusieurs intégrations configurées.

  • Note : La liste des intégrations inclut également des icônes d'état d'intégration. Un hexagone jaune ou rouge apparaissant à droite du nom de l'intégration indique qu'Ocean ne peut pas communiquer avec succès avec le point de terminaison.

    En survolant l'icône avec votre curseur, des détails supplémentaires sur le code d'erreur de réponse qu'Ocean reçoit sont fournis.

Point de Terminaison Webhook

  • Utilisé pour spécifier où Ocean enverra les notifications webhook eRéférence lorsque la référence est mise à jour dans le Portail Ocean.
  • Si le Type de Payload est défini sur Open API, Ocean vérifiera automatiquement si l'URL saisie dans ce champ est valide. Si elle est invalide, un hexagone jaune apparaîtra.

Type de Payload

Ocean propose deux ensembles d'API pour l'intégration eRéférence - les API Open et les API HL7 FHIR. Ce paramètre est utilisé pour sélectionner quel ensemble d'API Ocean utilisera pour communiquer avec votre système.

Note: Les deux ensembles d'API ne sont pas équivalents en termes d'événements pris en charge, de structures de données ou de mécanismes de sécurité. Étant donné que les API FHIR sont basées sur des normes et plus largement adoptées, il est conseillé aux implémentateurs de les utiliser sauf s'il existe une raison spécifique d'utiliser les API ouvertes, comme le lancement de système contextuel.

Lancement de système contextuel

  • Certains cibles de recommandation nécessitent le lancement d'un autre système pendant ou après la création d'une recommandation.
  • L'onglet "Lancement de système de recommandation" dans l'article "Activation des intégrations Ocean" décrit comment configurer un lancement de système de recommandation.

    Note: Cette fonctionnalité n'est disponible que pour des workflows spécifiques. Veuillez soumettre un ticket de support pour vérifier si elle s'applique à votre intégration.

Notifications par courriel

  • Lorsque des mises à jour eRéférence sont effectuées dans le Portail Ocean, Ocean envoie des notifications par courriel. Celles-ci sont décrites dans l'article de support "Où sont envoyés les courriels de notification eConseil et/ou eRéférence?".
  • Par défaut, les mises à jour effectuées via les API ne déclencheront pas de notifications par courriel aux participants de la recommandation. S'ils sont activés, Ocean enverra une notification par courriel aux participants appropriés.

Paramètres de soumission

  • Par défaut, tous les formulaires de recommandation incluent un bouton "Ajouter la pièce jointe" pour télécharger des fichiers.
  • Activer la case à cocher "Empêcher les expéditeurs de recommandation d'inclure des pièces jointes" masque le bouton sur toutes les recommandations initiées vers les listes configurées avec cette intégration. C'est utile si le système en aval ne souhaite pas stocker ou gérer les pièces jointes.

Permissions

Étendez chaque paramètre ci-dessous pour des informations supplémentaires concernant la fonctionnalité.

Effectuer les mises à jour d'état suivantes dans Ocean : Accepter, Diviser, Compléter, Marquer comme incomplet, Accepter la réponse, Annuler
  • Par défaut, un site avec une intégration API aura les boutons d'action liés à ces mises à jour d'état cachés dans la page de référence.
  • Ces mises à jour d'état sont similaires à celles prises en charge par les API, donc le site doit déterminer s'ils veulent les activer afin que les utilisateurs d'Ocean puissent également gérer la référence dans le Portail Ocean.
Envoyer des messages depuis la page d'enregistrement de l'eRéférence
  • La messagerie au sein de l'eRéférence permet à l'expéditeur et au destinataire de communiquer au sujet de la référence. Par exemple, le destinataire peut demander des informations supplémentaires avant d'accepter la référence ou l'expéditeur pourrait s'informer sur le traitement auprès du destinataire.
  • Par défaut, Ocean désactive le volet de messagerie pour les expéditeurs et les destinataires, afin qu'ils n'aient pas accès pour taper ou envoyer des messages sur les références envoyées à une liste configurée avec une intégration API.
  • Cette autorisation doit être activée si l'intégration prend en charge la messagerie ou si la messagerie n'a pas besoin d'être stockée comme partie de la référence dans le système en aval. Que ce soit activé ou non, les messages peuvent toujours être envoyés via l'intégration API.
Ajouter des pièces jointes aux messages dans la page d'enregistrement de l'eRéférence
  • Certains sites avec une intégration API qui prennent en charge la messagerie ne prennent pas en charge le stockage et la gestion des pièces jointes.
  • Par défaut, la fonctionnalité 'Ajouter la pièce jointe' est cachée à moins qu'elle ne soit activée, ce qui empêche les utilisateurs du Portail d'ajouter des pièces jointes à un message.
Ajouter des notes sur la page d'enregistrement de l'eRéférence
  • Les utilisateurs d'Ocean peuvent ajouter des notes à la référence qui aident les autres utilisateurs à comprendre comment la référence est traitée.
  • Lorsqu'une intégration API est en place, cette fonctionnalité est désactivée par défaut. Le système en aval peut prendre en charge une fonctionnalité de Notes en interne ou ne souhaite pas recevoir des mises à jour liées aux notes.
Mettre à jour la démographie du patient dans la page d'enregistrement eRéférence
  • Les données démographiques du patient peuvent être mises à jour dans le Portail Ocean après l'envoi initial de la référence. Cela peut ajouter de la complexité pour un système intégré en aval à prendre en charge en termes de gestion des enregistrements (scénarios de fusion/séparation de patients).
  • Par défaut, la fonction de mise à jour est masquée pour les références associées à une fiche répertoriée dans un annuaire qui a une intégration API, ce qui masque le bouton de modification à côté des données démographiques du patient pour les expéditeurs et les destinataires, de sorte qu'ils n'ont pas accès à la modification des données démographiques sur les références envoyées à une fiche configurée avec cette intégration.
Annuler la référence
  • Les expéditeurs de références peuvent annuler la référence dans le Portail Ocean (par exemple, si le patient n'a plus besoin du service). Cette fonctionnalité est désactivée pour les sites avec une intégration API car elle ajoute de la complexité à la gestion des références dans le système intégré en aval.
  • Si activée, Ocean enverra une notification webhook lorsque la référence a été annulée dans le Portail.
Transférer la référence vers un autre site dans le Portail Ocean
  • Les références peuvent être transférées d'un site Ocean à un autre. Par exemple, un site d'admission central transférera une référence à un fournisseur de services.
  • Cette fonctionnalité est désactivée par défaut (l'option "Transférer" est masquée dans le Menu d'action pour les destinataires) pour les sites avec une intégration API, car elle ajoute de la complexité à la gestion des références dans le système intégré en aval.
  • Lorsqu'elle est activée, les destinataires peuvent transférer manuellement la référence dans le Portail Ocean; il n'y a actuellement aucun support API pour le transfert. (Note: Les expéditeurs ne peuvent pas transférer les références.)
Mettre à jour le résumé du formulaire de recommandation
  • La section du résumé du formulaire de recommandation contient le contenu du formulaire de recommandation soumis par l'expéditeur.
  • Par défaut, lorsqu'une intégration API est présente, Ocean masque le bouton de modification à côté du Résumé du formulaire de recommandation pour les expéditeurs, afin qu'ils n'aient pas accès à la modification du formulaire sur les recommandations envoyées à une liste configurée avec cette intégration.
  • Lorsqu'elle est activée, Ocean enverra des mises à jour de la charge utile de la recommandation via l'API chaque fois que le résumé du formulaire de recommandation aura été mis à jour.

Comportement de l'API

Autoriser l'envoi d'une copie de la référence à ce point de terminaison lorsqu'une nouvelle référence est envoyée à partir de ce site

Lorsqu'une référence est envoyée à partir d'un site qui a une intégration API et que le paramètre "Poster une copie de la référence (toutes les intégrations) et toutes les mises à jour d'état ultérieures (FHIR v0.11 uniquement) à ce point de terminaison lorsqu'une nouvelle référence est envoyée à partir de ce site" est activé, Ocean enverra une copie de la référence au système expéditeur (Il s'agit de l'événement de message de demande de service d'ajout de notification FHIR et de l'événement de message de demande de service en amont de l'API ouverte).

Cela élimine le besoin pour l'expéditeur de copier et coller manuellement ou télécharger un PDF du résumé de la référence dans leur système.

Les intégrations utilisant FHIR v11 recevront toutes les mises à jour d'état en amont ultérieures (y compris les rendez-vous et les communications) à ce point de terminaison lorsqu'une nouvelle référence est envoyée à partir de ce site.

Utiliser cette intégration pour les listes de répertoires créées par l'API

Cette option applique l'intégration sélectionnée comme point de terminaison par défaut pour les listes créées à l'aide de l'API HealthcareService. Elle ne s'applique pas aux listes créées manuellement.

Lorsque les messages d'API échouent : Logique de réessai de l'API Ocean et dépannage

Qu'est-ce que c'est

Alors qu'il existe de nombreux avantages aux API RESTful, un inconvénient est qu'en cas d'appel infructueux, il n'y a par défaut aucun souvenir de la tentative échouée. Pour les intégrations d'API système-système, en particulier dans le domaine de la santé, cela peut être dangereux car cela pourrait entraîner une perte d'informations et des perturbations des processus entre les systèmes.

Pour remédier à ce problème, Ocean dispose d'une capacité de réessai automatisée intégrée pour toutes les intégrations d'API Ocean directes et basées sur FHIR. Ce service Ocean renverra toutes les notifications de webhook qui ne reçoivent pas un code de statut de classe 20X (par exemple 200, 201) une fois par heure pendant jusqu'à quatre jours.

Comment ça fonctionne

Ce service sera exploité à partir du module Ocean Cloud Connect. Cloud Connect gère une file d'attente de toutes les notifications de webhook qui y sont acheminées jusqu'à ce qu'elles réussissent ou expirent.

  • Les appels réussis sont retirés de la file d'attente.
    • Le premier appel d'API infructueux déclenchera une alerte par e-mail contenant le nom de l'intégration et le message d'erreur rencontré par Ocean, qui sera envoyé par e-mail à l'adresse e-mail du 'Administrateur clinique / Contact de support Ocean' spécifiée dans les paramètres du compte du site.
    • Ocean réessayera l'appel à l'endpoint plusieurs fois dans la première heure. En cas d'échec, Ocean réessaiera une fois par heure.
    • Toutes les 24 heures, Ocean enverra une alerte par e-mail au 'Administrateur clinique / Contact de support Ocean' pour les informer que les problèmes ne sont toujours pas résolus.
    • Si l'événement d'API en échec est envoyé avec succès pendant la période de réessai, les alertes par e-mail quotidiennes cesseront.
    • Au bout de 96 heures, Ocean abandonnera les tentatives de joindre l'endpoint. Cependant, Ocean continuera d'envoyer des e-mails quotidiens au 'Administrateur clinique / Contact de support Ocean' tant que l'intégration n'aura pas envoyé un événement réussi.
    • Une fois que l'intégration reçoit et accepte un message réussi d'Ocean, ou si les paramètres d'intégration sont sauvegardés à nouveau dans Ocean après la fin des tentatives de réessai, les notifications par e-mail quotidiennes cesseront.

Ce que vous devez faire

  • Assurez-vous que l'adresse électronique (ou les adresses électroniques) de la ou des personnes les plus responsables de l'intégration est/sont incluses dans le champ 'Administrateur clinique / Personne-ressource de soutien Ocean' du site Ocean. Il peut s'agir du gestionnaire informatique de la clinique et/ou du point de contact du fournisseur; ils n'ont pas besoin d'être un utilisateur sur le site Ocean.
    • Plusieurs adresses électroniques peuvent être spécifiées dans le champ - il suffit de séparer chaque adresse électronique par une virgule.
  • Lorsqu'une alerte par courriel est reçue de la part d'Ocean, cela indique généralement un problème avec le point de terminaison du système récepteur, pas avec Ocean. La première étape à suivre est d'examiner la santé du point de terminaison du système récepteur avant de contacter l'équipe de soutien d'OceanMD.
  • Les problèmes courants rencontrés comprennent:
    • Certificats expirés.
    • Temps d'arrêt du système non planifié.
    • Le point de terminaison du système récepteur ne sait pas comment traiter le message qu'il a reçu.
  • Si de l'aide est nécessaire ou s'il semble s'agir d'un problème lié à Ocean, veuillez soumettre un rapport d'incident à l'équipe de soutien OceanMD. Dans votre rapport, assurez-vous d'inclure:
    • Numéro du site Ocean
    • Environnement Ocean (par exemple, test.cognisantmd.com, staging.cognisantmd.com ou ocean.cognisantmd.com)
    • Une description de l'enquête effectuée jusqu'à présent pour évaluer tout problème avec le point de terminaison récepteur.
    • Une capture d'écran complète de l'alerte par courriel Ocean incluant la date et l'heure de réception du courriel.

Guide de configuration de l'intégration de l'engagement du Patient FHIR

Des outils d'engagement des patients tels que la réservation en ligne, la messagerie aux patients, les rappels aux patients, les formulaires de site Web, l'utilisation de bornes et de tablettes, y compris les complétions de formulaires, peuvent être intégrés à votre DMÉ en utilisant l'intégration de l'API FHIR.

Prérequis pour l'intégration

Configuration de l'intégration de l'engagement des patients avec Ocean

Ces étapes comprennent les étapes préliminaires requises pour configurer votre site Ocean pour l'intégration de l'engagement des patients avec un DMÉ.

  1. Compléter l'enquête d'inscription des nouveaux intégrateurs
  2. Envoyer un courriel à l'assistance Ocean avec le domaine de courriel que vous utiliserez lors du développement technique et des tests (par exemple, pour enregistrer de nouveaux utilisateurs, vous connecter au portail Ocean, etc.).
  3. Une fois qu'Ocean confirme que l'Étape 2 est complète, créer un compte utilisateur Ocean et un site sur test.cognisantmd.com
  4. Générer la Clé de chiffrement partagée (SEK) du site
  5. Dans le Menu, sélectionner Admin puis sélectionner Fonctionnalités du site. Activer l'option 'Activer Ocean Cloud Connect'. Cela déclenchera une boîte de dialogue vous indiquant de configurer Cloud Connect. Sélectionner le bouton 'Aller à Cloud Connect'.
  6. Dans Cloud Connect, sélectionner 'Intégrer mon DMÉ'. Entrer la SEK du site et sélectionner 'Sauvegarder et continuer'
  7. Sélectionner 'DMÉ basé sur FHIR' comme type de DMÉ avec lequel vous intégrez
  8. Entrer vos identifiants de DMÉ basé sur FHIR - Cette étape a des prérequis qui sont décrits dans la section des Exigences de haut niveau
  9. Une fois les exigences complétées, sélectionner 'Se connecter au DMÉ FHIR'. Si réussi, un message "Vous vous êtes authentifié avec succès auprès d'un DMÉ FHIR!" apparaîtra, 'Sauvegarder et continuer'
  10. Configurer vos paramètres Cloud Connect en spécifiant (1) combien de jours de calendrier synchroniser, (2) quels fournisseurs synchroniser, et (3) toute configuration de fournisseur sans rendez-vous (Ces configurations sont expliquées dans cet article). Cliquer sur 'Sauvegarder'. 
  11. La configuration de Cloud Connect est maintenant terminée. 
  12. Connectez-vous à votre Portail Ocean en utilisant vos identifiants de compte utilisateur Ocean
  13. Ouvrir le 'Menu' dans le coin supérieur gauche et cliquer sur 'Admin', accéder à 'Fonctionnalités du site' sous Fonctionnalités supplémentaires
  14. Activer la case à cocher 'Activer Ocean Cloud Connect' si ce n'est pas déjà activé. 

Vous avez maintenant configuré avec succès votre Portail Ocean pour l'intégration de l'engagement des patients!

 

Aperçu du lancement de l'application Ocean SMART (Lancement contextuel SMART sur FHIR de DSÉ)

Introduction

Ocean utilise la norme de l'industrie Lancement d'application SMART pour prendre en charge la connexion unique (SSO) et le lancement contextuel du patient à partir d'un dossier de santé électronique (DSÉ) ou d'un autre système de santé.

Authentification unique
  • Le cadre de lancement SMART permet à une personne authentifiée utilisant un système de santé tiers de confiance d'ouvrir une application ou une page spécifique dans Ocean sans avoir à se connecter manuellement à Ocean. Au lieu de cela, les informations d'identification de l'EHR de l'utilisateur peuvent être utilisées pour se connecter de manière sécurisée et automatique en tant qu'utilisateur Ocean correspondant.
  • Ocean respecte la norme Open ID Connect pour garantir que ce processus d'authentification unique est sécurisé.
Exigences

Pour se connecter à Ocean, les systèmes de lancement doivent :

  • Mettre en œuvre et prendre en charge la séquence de lancement SMART "EHR" en tant que "Serveur FHIR de DSÉ / Serveur d'autorisation de DSÉ" (Ocean est l'« Application » dans ce contexte).
  • Fournir des points de terminaison OAuth 2.0 pour le lancement SMART.
  • Respecter le protocole Open ID Connect en tant que système de lancement dans le cadre du protocole :
    • Fournir un accès public au point de terminaison : [le-serveur-fhir]/.well-known/openid-configuration.
      • (Ocean accède à ce point de terminaison dans le cadre du protocole Open ID, pour s'assurer qu'il peut valider la signature JWT du lanceur à l'aide de la clé publique spécifiée dans la "jwks_uri" de la configuration).
    • Signer le jeton JWT avec l'algorithme ES256 ou RS256.
  • Être capable de lancer un navigateur web moderne (intégré ou via un lien d'application de bureau).
    • Le navigateur web doit prendre en charge l'utilisation par Ocean des cookies de session HTTPS typiques et de localStorage pour les URL suivantes :
  • S'assurer que les utilisateurs du système ont accès à au moins une URL de lancement configurable pour Ocean. Ces URL doivent pouvoir accueillir des noms de chemin variables en fonction de facteurs tels que le site Ocean, l'action Ocean prévue et d'autres paramètres pertinents.
    • Une liste complète des paramètres d'« action » pour le lancement SMART dans Ocean peut être trouvée dans l'article Guide de mise en œuvre SMART on FHIR.
    • Des exemples d'URL de lancement SMART dans Ocean incluent :
      • Visualisation du patient dans la carte de santé d'Ocean - https://ocean.cognisantmd.com/sso/smart/auth?siteNum=1234&action=viewMap
      • Ouverture du "Tableau de bord du patient Ocean" - https://ocean.cognisantmd.com/sso/smart/auth?siteNum=2000&action=dashboard

Les systèmes doivent également :

  • Fournir la valeur encodée en Base64 de la Clé de Chiffrement Partagée du site Ocean en tant que valeur pour un attribut "oceanSharedEncryptionKey" dans le jeton d'accès au lancement SMART.
    • Ce paramètre élimine le besoin pour les utilisateurs d'entrer manuellement la Clé de Chiffrement Partagée de leur site dans leur navigateur web pour chaque lancement contextuel. Bien qu'il puisse être omis si une clinique préconfigure les navigateurs web des utilisateurs en stockant la Clé de Chiffrement Partagée dans le "localStorage" du navigateur, il est généralement obligatoire. Les navigateurs basés à l'hôpital ne conservent souvent pas le localStorage à travers les sessions utilisateur en raison de considérations de confidentialité.
    • Plus d'informations sur les fournisseurs de lancement SMART sont fournies ici
Lancement contextuel du patient
  • En plus de la SSO, le lancement SMART peut facultativement transmettre des informations à Ocean qui sont liées au patient actuellement sélectionné dans le DSÉ. Les informations sur le patient comprennent le numéro MRN du DSÉ, le nom, le numéro d'assurance maladie, le sexe, la date de naissance, les coordonnées et d'autres informations cliniques disponibles.
  • Ocean lit ces informations sur le patient, avec l'autorisation du DSÉ, en demandant des "scopes" pour lire les données des points de terminaison FHIR du DSÉ.
  • Certains cas d'utilisation pour le lancement contextuel du patient comprennent :
    • Ouvrir le "Tableau de bord du patient d'Ocean" pour voir un résumé des informations d'Ocean liées à ce patient, y compris les eRéférences actives, les eConseils, les résultats de questionnaires, etc. Le tableau de bord sert également de point de lancement pratique pour effectuer d'autres actions, telles que l'initiation d'une référence.
    • Visualiser le patient dans la Carte de santé d'Ocean.
    • Créer une nouvelle eRéférence préremplie avec les informations démographiques et cliniques du patient basées sur le dossier du DSÉ.
    • Utiliser Ocean pour envoyer un lien de message sécurisé ou un questionnaire directement à partir du dossier du DSÉ.
Exigences d'intégration pour le lancement contextuel du patient dans les systèmes Ocean

De plus, pour prendre en charge le lancement contextuel du patient, les systèmes doivent respecter les exigences suivantes :

  • Prise en charge de FHIR R4 pour le point de terminaison Patient.read :
    • L'intégration doit inclure la prise en charge du point de terminaison Patient.read dans le contexte de lancement de l'application SMART, en suivant les normes FHIR R4.
  • Inclure le paramètre "patient" dans le jeton d'accès au lancement SMART :
    • Assurer la fourniture d'un paramètre "patient" dans le jeton d'accès au lancement SMART pour permettre des lancements contextuels du patient sans heurts.
  • Respect des conventions FHIR pour le stockage des RPS :
    • Respecter les conventions FHIR établies pour le stockage des RPS pertinents utilisés par Ocean. Cela inclut l'utilisation de l'identificateur de numéro d'assurance maladie "JHN" et de l'identificateur de code de version pour les patients de l'Ontario.
  • Facultatif : Prise en charge de l'opération FHIR R4 /Patient/[id]/$everything :
    • Prendre éventuellement en charge l'opération FHIR R4 /[/Patient/[id]/$everything pour préremplir les médicaments, les allergies, les antécédents médicaux et les pièces jointes du dossier.
Séquence d'événements pour les utilisateurs
    1. Un utilisateur est connecté au système DSÉ.
    2. L'utilisateur clique sur un bouton de lancement "Ocean" dans l'interface utilisateur du DSÉ.
    3. Le bouton de lancement ouvre Ocean dans un nouvel onglet ou une nouvelle fenêtre du navigateur web. Le lanceur fournit à Ocean une URL contenant les informations de base de lancement (basées sur le protocole SMART).
    4. Ensuite, en arrière-plan :
      • Ocean utilise les informations de lancement pour demander des informations d'authentification au DSÉ en utilisant le protocole OAuth 2.0.
      • En réponse, le DSÉ fournit à Ocean un jeton d'accès, qui fournit à Ocean des informations de base concernant l'utilisateur actuel du DSÉ et le patient actuel.
      • Ocean vérifie si l'utilisateur du DSÉ a déjà été lié à un compte Ocean.
    5. Si l'utilisateur n'a pas encore lié son compte DSÉ à Ocean, une invite de connexion s'affiche :
    6. Une fois le compte lié, à partir de ce moment-là, la connexion unique est automatique.
    7. Ensuite, si un patient a été spécifié, Ocean demande au DSÉ des informations sur le patient actuel (en utilisant les API FHIR du DSÉ).
    8. Enfin, Ocean redirige vers la page demandée dans Ocean. Cette page peut être soit une destination spécifique au patient, comme le tableau de bord patient Ocean, soit une destination générale comme le Portail Ocean, en fonction de l'"action" demandée par l'URL de lancement du bouton de lancement SMART.

Le diagramme de séquence ci-dessous illustre les interactions en arrière-plan entre les systèmes qui se produisent pour permettre la connexion unique et le lancement contextuel SMART d'Ocean (un fichier PDF est disponible en bas de cet article).

Autorisation

Pour des raisons de sécurité, tous les serveurs du système de santé qui souhaitent utiliser un lancement SMART dans Ocean doivent être privément autorisés par les administrateurs d'OceanMD.

Veuillez envoyer les valeurs suivantes à l'adresse e-mail de support d'Ocean 'support@oceanmd.com' afin que nous puissions créer l'entrée d'autorisation pour votre système de lancement :

  1. L'URL du serveur :
    • Fournie en tant que paramètre "iss" initial lors du lancement SMART. Cette valeur doit également correspondre au serveur API FHIR.
  2. ID client :
    • L'ID client unique et imprévisible pour Ocean, tel qu'assigné aléatoirement par le serveur de lancement. (Il s'agit du paramètre d'URL fourni par Ocean lors de la redirection SMART initiale vers le point de terminaison d'autorisation du lanceur.)
  3. Point de terminaison d'autorisation :
    • Le point de terminaison "/authorize" OAuth 2.0.
  4. Point de terminaison de jeton :
    • Le point de terminaison "/token" OAuth 2.0.
  5. URL de l'émetteur de jeton :
    • La valeur "iss" fournie dans l'ensemble de revendications JWT signé, dans la valeur id_token du jeton d'autorisation.
  6. L'URL et le corps de réponse pour le ".../.well-known/smart-configuration" accessible publiquement (si pris en charge).
  7. L'URL et le corps de réponse pour le ".../.well-known/openid-configuration" accessible publiquement.

À l'exception de l'ID client, toutes ces valeurs devraient être disponibles dans le point de terminaison .well-known/openid-configuration du serveur DSÉ et/ou le point de terminaison de métadonnées FHIR.

Pour des raisons de sécurité, Ocean effectue une validation stricte du jeton JWT pour respecter les précautions de l'Open ID Connect. (Si un aspect quelconque du jeton JWT ne passe pas le protocole, Ocean tente de fournir un message d'erreur utile pour le dépannage.)

Guide de mise en œuvre de SMART on FHIR

Information utile sur la mise en œuvre de SMART avec Ocean

Cette vidéo offre un aperçu de la manière dont HL7 SMART on FHIR peut être utilisé pour se lancer dans Ocean, ainsi que des conseils pour commencer une implémentation sur un serveur SMART. Cet article accélérera davantage vos activités de mise en œuvre en partageant des conseils et des considérations recueillis auprès d'autres implémenteurs. Il est divisé en sections suivantes :

  • Considérations de configuration - Éléments importants à prendre en compte pour préparer la 'poignée de main' entre les systèmes.
  • Plongée plus profonde dans le flux de séquence - Détails supplémentaires sur les données échangées entre les systèmes et comment elles sont utilisées.
  • Conseils pour l'opération $everything - Détail des avantages de la nouvelle opération /Patient/[id]/$everything et conseils pour les configurations d'intégration du lancement SMART.
  • Contexte FHIR - Informations supplémentaires sur le contexte FHIR avec le lancement SMART.
  • Réception automatique d'une copie de la référence - Utilisation des API et des configurations Ocean pour recevoir automatiquement une copie de la référence qui vient d'être envoyée depuis le lancement SMART.
  • Partage de l'identifiant de référence POS avec Ocean - Détails concernant l'identifiant de référence interne du serveur POS/FHIR et comment Ocean peut le renvoyer au système POS.
  • Paramètres d''action' de lancement SMART - Liste de tous les paramètres d''action' pour le lancement SMART dans Ocean.

Cet article de support sera 'vivant' à mesure que des conseils supplémentaires seront recueillis. Il est recommandé de le 'suivre' afin de recevoir une notification lorsqu'il est mis à jour.

Définitions utilisées dans cet article

  • Demandeur - l'individu (fournisseur ou patient) qui soumet une demande de référence.
  • Fournisseur de services - le service/l'organisation/fournisseur clinique ou communautaire qui reçoit une demande de référence pour fournir un service au patient.
  • Point de service (POS) - le système de gestion des dossiers des patients utilisé par le demandeur (par ex. DMÉ, DME, système de gestion de cas, CRM).
  • Serveur SMART - le composant logiciel utilisé par le POS pour permettre le lancement contextuel dans Ocean.
  • Authentification unique (SSO) - la capacité d'accéder à son compte utilisateur Ocean sans avoir à saisir manuellement son nom d'utilisateur et son mot de passe.
  • Lancement contextuel - la capacité d'accéder à Ocean en utilisant SSO, ainsi que d'avoir le patient qui est 'en contexte' dans le POS être 'mis en contexte' dans Ocean sans que le fournisseur ait à rechercher manuellement ce patient et/ou à saisir les données de ce patient.
  • ID client - un identificateur émis par le serveur SMART à Ocean pour le reconnaître en tant qu'application SMART.
  • ID site - l'identificateur d'Ocean pour le site configuré par le fournisseur de services dans Ocean pour envoyer et/ou recevoir (et gérer) des eRéférences.

Liste de vérification de configuration

  • Fournir à l'équipe Ocean les points de terminaison du serveur SMART afin qu'ils puissent être ajoutés à la liste blanche Ocean (voir la section Liste blanche ici).
  • L'identifiant du client (utilisé aux étapes 3, 4, 11) est fourni par le serveur SMART à Ocean lors de la configuration de l'intégration. Ocean le stocke et le renvoie lors de son lancement.
    • Ocean a seulement besoin d'un identifiant de client par URL de serveur SMART. Le même identifiant de client peut être utilisé pour plusieurs organisations avec des sites Ocean, tant qu'ils sont hébergés dans le même environnement (par exemple, un système de point de vente SaaS).
  • S'assurer que le cadre de développement permet la personnalisation du jeton d'accès et des jetons d'identifiant. Certains cadres, tels que Javaspring et .NET, permettent de contrôler les flux, mais d'autres sont moins personnalisables.

Approfondissement de la séquence de flux

  • L'identifiant du patient (étapes 8, 9, 15, 16) est l'identificateur utilisé pour identifier de manière unique le patient dans le point de vente. Il n'est pas nécessaire de suivre un format d'identifiant prescrit (par exemple, le GUID à l'étape 16 est un exemple).
    • Ocean utilise uniquement l'identifiant du patient comme clé au point de terminaison FHIR Patient.read pour récupérer la ressource Patient.
  • Idéalement, la ressource Patient.read du point de vente/serveur SMART fournira toutes les données requises pour pré-remplir la section Information du patient de l'eRéférence Ocean. Cependant, Ocean ne rejettera pas une ressource Patient peu renseignée ; il exploitera les données disponibles (et le demandeur de la référence devra remplir manuellement les champs manquants).
  • À l'inverse, Ocean ignorera toute donnée démographique supplémentaire reçue dans la ressource Patient qui n'est pas nécessaire pour compléter la section Information du patient de l'eRéférence.
  • Le champ sub dans la charge utile du jeton d'identifiant JWT (étape 9) contient l'identifiant unique du point de vente/serveur SMART pour l'utilisateur. Ocean effectuera une recherche basée sur les champs démographiques dans le jeton d'identifiant pour identifier un utilisateur Ocean correspondant, puis stockera un lien dans le compte Ocean de l'utilisateur vers l'ID utilisateur du point de vente pour permettre la connexion unique.
  • Le lien ID utilisateur du point de vente-ID utilisateur Ocean n'est pas affecté si l'utilisateur modifie son mot de passe du point de vente ou toute autre donnée démographique autre que l'ID utilisateur lui-même.
  • Ocean ne peut être lancé que via SMART dans un nouvel onglet de navigateur ; il ne se lancera pas dans un iFrame.

Conseils pour l'opération $everything

  • Ocean analyse tous les pièces jointes qu'il reçoit via le point de terminaison $everything.
  • L'opération /Patient/[id]/$everything est une nouvelle alternative au point de terminaison Patient.read. Elle fournit à Ocean des informations supplémentaires importantes pour le lancement contextuel.
  • Les implémenteurs peuvent configurer dans leur intégration de lancement SMART si Ocean doit utiliser Patient.read ou l'opération plus complète $everything lors du lancement contextuel.
  • En particulier, l'opération $everything permet à Ocean de lire les informations du patient suivantes dans le but de pré-remplir les formulaires Ocean :
    • Médicaments
    • Allergies
      • Liste des problèmes
    • Antécédents médicaux passés
    • Antécédents médicaux de sa famille
    • Pièces jointes du dossier (présélectionnées)
    • Observations/Vitales/Valeurs de laboratoire
    • Immunisations
  • Ocean traitera les ressources FHIR suivantes lorsqu'elles sont incluses dans le bundle $everything :
    • Déclaration de médication
    • Intolérance aux allergies
    • Conditions (pour les vitales et les valeurs de laboratoire)
    • Rendez-vous
    • Observation
    • Référence de document (pour les pièces jointes du dossier pré-sélectionnées)
    • Immunisation
  • Veuillez consulter ce guide pour des informations supplémentaires.

Spécification des valeurs de NIP et d'assurance maladie à pré-remplir

  • Dans un scénario où la ressource Patient a plusieurs propriétés d'identificateur correspondant à différents numéros de dossier médical (NIP), Ocean a introduit un paramètre de requête de lancement SMART pour indiquer à Ocean quelle valeur de NIP pré-remplir :
    • mrnText correspond au Identifier.type.text que Ocean recherchera pour obtenir la valeur de NIP correspondante.
  • De même, les serveurs SMART utilisent différents systèmes pour spécifier l'identificateur correspondant au numéro de carte d'assurance maladie (NAM). Afin d'indiquer à Ocean quel identificateur utiliser pour pré-remplir le champ NAM Ocean :
    • jhnSystem équivaut à la valeur du système de la propriété d'identificateur que Ocean recherchera pour obtenir la valeur de NAM correspondante. Par exemple, les sites Epic ajouteraient ce qui suit à leur chaîne de lancement : &jhnSystem=https%3A%2F%2Fopen%2Eepic%2Ecom%2FFHIR%2FStructureDefinition%2FPayerMemberId
  • Ocean effectuera une correspondance exacte (en excluant les "guillemets") et reviendra à la valeur par défaut si aucune correspondance n'est trouvée. Les caractères spéciaux peuvent être encodés.

Contexte FHIR

  • Lors de l'initiation d'un lancement SMART pour une demande de service (par exemple, eRéférence, eCommande ou eConseil), les implémenteurs peuvent inclure l'identifiant de l'enregistrement de demande de service préliminaire de leur système de lancement dans le fhirContext SMART.
  • Si fourni, Ocean stocke cet identifiant avec la demande de service et l'inclut dans la liste des identifiants pour les messages FHIR ultérieurs liés à la demande de service.
  • Cette fonctionnalité facilite le lien entre l'enregistrement de demande de service préliminaire dans le DSÉ (communément appelé "référence ou consultation en attente") et la messagerie FHIR en backend de la demande de service.
  • Le fhirContext est inclus dans le jeton de réponse, aux côtés de l'access_token.
  • Il doit faire partie du JSON du jeton, formaté comme un tableau, comme ceci : [{"reference": "ServiceRequest/{serviceRequestId}"}].
  • Pour plus d'informations sur le contexte FHIR, consultez l'article officiel sur les scopes et le contexte de lancement SMART.
  • Exemple d'un jeton de contexte de lancement 
    {
  "access_token": "{access_token à utiliser pour les appels API FHIR ultérieurs}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{refresh_token ; ignoré par Ocean}",
  "scope": "{scopes accordés ; devrait généralement correspondre à la demande ",
  "patient": "{identifiant du patient, ou omis s'il n'y a pas de patient dans le contexte}",
  "encounter": "{identifiant de l'interaction, ignoré par Ocean}"
  "id_token": {
    %% JWT valide signé avec des valeurs encodées compatibles OIDC 
    "sub": "{uuid de l'utilisateur}",
    "iss": "{URL de l'émetteur du jeton}",
    "aud": "{client_id}",
    "exp": {date/heure d'expiration par exemple, 1679028255},
    "iat": {date/heure d'émission par exemple, 1679024655},
    "nonce": "{GUID de nonce ; facultatif ; doit correspondre à celui d'Ocean s'il est fourni}"
  },
  "intent": "action={oceanAction}&resource={oceanResource}", %% facultatif
  "tenant": "UUID opaque de l'organisation ; ignoré par Ocean", %% facultatif
  "fhirContext": "[{"reference": "ServiceRequest/{serviceRequestId}"}]"
}

Le diagramme de séquence ci-dessous illustre les interactions en backend entre les systèmes qui se produisent pour permettre la connexion unique SMART d'Ocean et le lancement contextuel. (un fichier PDF est disponible en bas de cet article).

Recevoir une copie de la référence automatiquement

  • Le demandeur peut vouloir une copie de la référence dans le dossier du patient dans le DSÉ. Ce processus de copie peut être effectué manuellement en copiant et collant depuis Ocean.
  • Alternativement, l'automatisation est possible si le système serveur POS/SMART implémente soit l'API FHIR eRéférence d'Ocean pour recevoir de nouvelles eRéférences, soit l'API Open eRéférence d'Ocean pour récupérer des eRéférences. Dans ce cas, Ocean enverra une notification webhook au point de terminaison spécifié, avec un événement de message FHIR de notify-add-service-request (pour l'API FHIR eRéférence) ou notify-upstream-service-request (pour l'API Open).

Partager l'identifiant de la référence POS avec Ocean

  • Il est possible d'envoyer à Ocean l'identifiant de référence interne du serveur POS/FHIR afin qu'il puisse être inclus dans la charge utile de l'eRéférence FHIR renvoyée par Ocean. Ceci est utile pour les systèmes POS qui créent une référence interne avant de se lancer dans Ocean et qui souhaitent fusionner la charge utile avec cette référence interne.
  • L'identifiant de référence interne peut être envoyé dans le paramètre fhirContext de l'access token pour transmettre la référence de substitution du lanceur SMART (par exemple [{reference: “ServiceRequest/123”}]).  Ocean utilisera l'URL iss initiale du serveur fournie par le DMÉ au lancement et la combinera avec le fhirContext.
    En concaténant les deux valeurs ci-dessus, cela produira un URI globalement unique pour ServiceRequest.identifier.value = https://chr.telus.com/fhir/ServiceRequest/123
  • En plus de l'identifiant de référence d'Ocean, cet identifiant de référence POS apparaîtra dans la propriété d'identifiant de ServiceRequest avec la valeur ServiceRequest.identifier.system = urn:ietf:rfc:3986

Paramètres d'Action de Lancement SMART / Intention FHIR

Le tableau ci-dessous décrit la liste de tous les paramètres d'Action pour le lancement SMART dans Ocean.

Paramètre action Paramètre resource (si utilisé) Description
viewMap S.O. Lance l'utilisateur dans Healthmap Ocean
viewHealthServices La Catégorie de Service de Santé pertinente (par ex. SERVICES DE CARDIOLOGIE) Lance l'utilisateur dans Healthmap Ocean filtré pour un service de santé spécifique
searchHealthMap Un mot-clé ou une phrase de recherche simple (par ex. "pression artérielle"). Les caractères non alphanumériques doivent être encodés en URL (par ex. avec un "%20" à la place d'un espace). Lance l'utilisateur dans Healthmap Ocean et effectue une recherche pour le mot-clé pertinent
referDirect La valeur de référence de l'inscription dans l'annuaire Lance l'utilisateur directement dans Healthmap Ocean à l'inscription dans l'annuaire spécifiée comme la 'resource'
portal S.O. Lance l'utilisateur dans le Portail Ocean
sendMessage Optionnel - L'identificateur du modèle de message Initie un nouveau message au patient avec le modèle de message spécifié ou celui par défaut s'il n'y en a pas de spécifié
addForm S.O. Permet à l'utilisateur de rechercher et mettre en file d'attente des eFormulaires Ocean pour que le patient les complète
viewServiceRequest La valeur de référence pour la demande de service pertinente (eRéférence/eConseil/eCommande) Lance l'utilisateur directement dans une demande de service spécifique.
viewReferralFavourite L'identificateur de l'élément favori. Lance l'utilisateur directement dans une référence pour l'Offre de l'inscription dans l'annuaire dans la liste des favoris spécifiée comme la 'resource'
debug S.O. Reste sur la page de lancement à des fins de dépannage. Peut également être de la forme debug:[action] (comme debug:addForm) pour des informations plus spécifiques.
[vide] S.O.

Lorsque le paramètre Action est laissé vide ou omis, l'utilisateur est lancé dans la Vue Résumé du Patient pour le patient DMÉ actuel par défaut.

Si aucun patient n'est fourni dans le contexte de lancement, l'utilisateur est simplement redirigé vers le Portail Ocean.

Guide de mise en œuvre de l'API eRéférence ouverte

Ocean eRéférence Dépréciation de l'API ouverte

À partir du 3 novembre 2022, l'API ouverte de l'eRéférence Ocean est dépréciée. Les systèmes tiers qui développent de nouvelles intégrations avec les eDemandes Ocean (eRéférence et eConseils) doivent utiliser les API FHIR d'Ocean.

Les API ouvertes d'Ocean permettent aux systèmes tiers de s'intégrer avec Ocean afin que les fournisseurs puissent traiter les références dans leur système ou application préférés. En plus de la documentation de l'API ouverte, nous avons rassemblé les conseils d'implémentation suivants pour accélérer votre intégration.

Séquence d'intégration de l'eRéférence

Le diagramme de séquence ci-dessous illustre la séquence d'interaction entre Ocean et un système tiers après qu'une référence a été créée dans Ocean.

Ocean_eForm_Completion_API_sequence-eReferral__1_.png

Validation du webhook

  • Le webhook nécessite que l'URL réponde à un défi pour fonctionner correctement. Un test avec un webhook qui n'est pas prêt à fournir le jeton de défi dans la réponse échouera à la validation. Cela est indiqué par un symbole d'exclamation jaune à côté de l'URL.

  • La vérification de la validation ne nécessite pas les en-têtes spécifiques à Ocean (sitenum, sitekey) dans la réponse, bien qu'ils ne causent aucune erreur s'ils sont inclus. Pour plus d'informations, consultez notre documentation API

Chiffrement de la charge utile

  • Le code de chiffrement dans la documentation de l'API Ocean est un exemple qui illustre le flux de chiffrement correct et met en évidence la bibliothèque de chiffrement (CryptoJS) que nous utilisons et recommandons lors du travail en Javascript. Mais le schéma de chiffrement est simplement un chiffrement AES standard, vous pourrez donc absolument chiffrer/déchiffrer ces données dans d'autres langages. Par exemple, pour Ruby, vous pouvez utiliser le module OpenSSL de la bibliothèque standard pour exécuter les chiffrements AES afin de chiffrer et déchiffrer les données. Il existe également probablement d'autres gemmes AES/cryptographiques externes que vous pouvez utiliser si vous avez une préférence.
  • ***Lors de la récupération d'une référence, il est recommandé d'utiliser le champ oneTimeKeyEncryptedWithSitePublicKey": (plutôt que le champ oneTimeKeyEncryptedWithTargetPublicKey") afin que votre système puisse également déchiffrer les références qui sont envoyées par les sites Ocean de vos clients (et pas seulement celles qui sont reçues par celui-ci). Consultez la section "Comportement de l'API" de cet article pour plus d'informations sur la réception d'une copie des références envoyées.

Mapping des données

  • Le fichier en bas de cet article répertorie les éléments de données disponibles dans les charges utiles de l'API ouverte.
  • Si le site permet plusieurs dates de rendez-vous pour une seule référence, la liste des références doit avoir plusieurs étiquettes configurées. Par défaut, Ocean ne permet qu'une seule étiquette pour chaque liste nommée "Rendez-vous". Chaque liste de références (Administrateur du site > Répertoire des listes > Section Détails du service) peut être configurée par l'administrateur du site pour accepter des étiquettes supplémentaires parmi les valeurs suivantes : rendez-vous 1 - 5, date de consultation, date de suivi, date de la première visite, date de la procédure, date de la chirurgie.

blobid0.png

  • Si un appel API est envoyé avec des données de rendez-vous sans étiquette, alors Ocean attribuera la première étiquette de rendez-vous qui n'a pas été utilisée dans cette référence pour ce rendez-vous. Si un deuxième rendez-vous est envoyé sans étiquette et que toutes les étiquettes de rendez-vous ont déjà été attribuées pour cette référence, l'API renverra une erreur. Alternativement, les données de rendez-vous peuvent être envoyées avec une étiquette de rendez-vous, mais elle doit correspondre à l'une des étiquettes configurées pour ce site.
  • Le POST Mettre à jour une référence API accepte les valeurs d'état de référence suivantes dans le champ d'état : Accepté, Refusé, Confirmé, Annulé, Terminé, Imprimé, Incomplet, Envoyé. Le champ est facultatif et ne doit être renseigné que par le système tiers lorsque la valeur d'état de référence est différente de la mise à jour précédente envoyée à Ocean. Ocean renverra une erreur de "La référence est déjà dans l'état demandé" si deux mises à jour sont envoyées avec la même valeur d'état. Par conséquent, si l'ensemble interne de statuts de référence du système tiers est plus détaillé que celui d'Ocean, les mises à jour de référence doivent contenir les informations mises à jour pertinentes sans valeur d'état à moins que cela ne modifie l'état de la référence Ocean.
  • La référence est mise à jour à un état "Réservé" en interne par Ocean une fois qu'elle reçoit les données de rendez-vous du système tiers.
  • Une fois qu'une référence est dans l'état de référence "Terminé" ou "Annulé", elle ne peut pas revenir à un autre état de référence via l'API.
  • Ocean placera une référence dans le dossier "Besoin de révision" lorsqu'un destinataire reçoit un nouveau message (par exemple, le destinataire de la référence envoie un message à l'expéditeur avec des instructions de soins aux patients). Lorsqu'un message est envoyé en utilisant le 'Ajouter un message' endpoint (URL ci-dessous), le NuméroSiteCible doit être renseigné avec le numéro de site du fournisseur qui doit examiner le message afin qu'il soit 'signalé' pour inclusion dans le dossier Besoin de révision.

Ouvrir le guide de mise en œuvre de l'API d'engagement des patients

 

Les API ouvertes d'Ocean permettent aux systèmes tiers de s'intégrer à Ocean afin que les fournisseurs puissent envoyer des eFormulaires Ocean aux patients et que les eFormulaires complétés soient automatiquement téléchargés dans leur système ou application préférés. En plus de la documentation des API ouvertes, nous avons rassemblé les conseils d'implémentation suivants pour accélérer votre intégration.

 

Séquence d'intégration des eFormulaires d'engagement des patients

Le diagramme de séquence ci-dessous illustre la séquence d'interaction entre Ocean et un système tiers pour générer des liens web spécifiques aux patients pouvant être intégrés dans le service de messagerie sécurisé du système tiers. Le patient accédera au lien web pour compléter les eFormulaires Ocean, après quoi Ocean notifiera le système tiers pour collecter les formulaires complétés.

 

Ocean_eForm_Completion_API_sequence.jpg