Cet article décrit les étapes de conception et de développement du business process « Health Care Payment Process », l’un des POCs réalisé dans le cadre de dématérialisation du Workflow d’approbation de la demande de paiement des soins de santé dans le domaine d’assurance médicale, en utilisant Oracle Process Cloud Service (PCS) ou le BPM Cloud, l’un des produits phare du Cloud Oracle.
L’implémentation du processus « Health Care Payment Process » est effectué selon les étapes suivantes :
- Créer une nouvelle application PCS: ServiceAccessApproval
- Modéliser le flux de processus (flux BPMN, sans implémentation)
- Modéliser les types Business Object (modélisation de données)
- Modéliser les décisions (Business Rules)
- Configurer les web services externes
- Modéliser les formulaires Web (Tasks Screens)
- Finaliser la mise en œuvre du processus
- Déployer le processus
- Lancer le processus
Définition du business process ‘Health Care Payment Process’
Dans notre cas d’étude, le processus « Health care payment process » de paiement des soins de santé est classé en trois sous-processus, décrits brièvement ci-dessous :
- Vérification de l’Admissibilité du patient
- Soumission et validation de la demande (Use case choisi pour le POC à implémenter)
- Traitement du paiement des soins santé.
Pour passer rapidement et sans tarder trop sur les détails de chacun des sous-processus, les schémas suivants montrent les principales activités de chacun des sous-processus.
Process n° 1 « Vérification de l’admissibilité du patient »
Process n° 2 « Soumission et Validation de la demande de paiement »
Le graphique suivant montre des principales étapes de la phase 2 de « Soumission et Validation de la demande de paiement » et qui concernera notre cas d’étude :
Process n° 3 « Traitement du paiement des soins santé »
Et enfin, la 3ème phase de traitement du paiement, schématisée par le graphique suivant :
Comme dit, je me focaliserai de vous montrer les grandes lignes de conception et du développement du Worflow de « Soumission et Validation de la demande de paiement », que je peux schématiser comme suit :
Principales étapes – Processus ‘Soumission et Validation de la demande de paiement’
- Le bureau du praticien envoie le formulaire de la réclamation « Claim » à la mutuelle appropriée
- Vérification que les services fournis étaient dans les paramètres du plan de santé du patient et détermination des montants à payer par le patient et le donneur d’ordre.
- Après l’approbation de la demande, le payeur envoie les résultats au praticien. Cette étape définit le montant spécifique à payer par le payeur, ainsi que la responsabilité du patient pour le paiement.
- Envoi des données au bureau du praticien.
Conception du workflow ‘Soumission et Validation de la demande’ en utilisant PCS Composer
Intégration PCS / DBaaS
Au niveau de la Service Task « Sauvegarder la demande« , le PCS appelle DBaaS via une API REST exposée au niveau DBaaS qui retournera par la suite la réponse au PCS.
Ci-après, les principales étapes de cette configuration :
Etape 1. Création du service ‘restDB’ sous DbaaS, tout en accédant à votre compte Cloud DBaaS
Etape 2. Création du Schéma INTG_TTK
On insère des valeurs sur la table INTG_TTK qui feront les réponses retournés à PCS.
Etape 3. Création du service REST en utilisant DBaaS
Une fois la table INTG_TTK créée, on crée le REST Web Service à l’aide de DBaaS, exposé en tant que REST service.
Pour ce faire, depuis DBaaS, on navigue vers SQL Worshop > RESTful Service et on fournit les entrées suivantes pour les exposer en tant que service.
Dans notre cas, on définit la ressource GET comme service prêt à être consommer et qui apparaîtra dans le DBaaS RESTful services.
Et voilà, notre DBaaS REST service est prêt à emploi 😉
Etape 4. Appeler le DBaaS REST service depuis l’application PCS
Dans cette étape, on configure le service task pour appeler le REST service, effectuer l’opération GET, PUT, … et stocker les données dans des business objects, dont on configure la Data Association pour passer les nouvelles valeurs comme input et output à la service task.
Par exemple, si on configure un REST connector qui utilise un GET opération /TTKInsurence/{TTK_ID} pour extraire les information du patient à partir de son identifiant {TTK_ID}, on configure le business object pour stocker les valeurs telles qu’elles sont modifiées par les appels du service.
Etape.5. Création REST Connector
Depuis PCS, on implémente le Connector REST, qui accède au service DBaaS REST et en définit les ressources qui interrogera la table INTG_TTK.
Reste à configurer le ‘Service Task‘ comme Service Call avec l’implémentation type REST.
Pour ce faire, on parcourt avec la petite loupe le Connector REST déjà créé, sélectionner la ressource qui contient une ou plusieurs opérations qui contrôlent les données en effectuant des opérations CRUD de base telles que créer, lire, mettre à jour et supprimer des ressources à l’aide des demandes de méthode HTTP standard et choisir l’opération voulue.
Best Practice :
Appeler la ressource REST API configurée dans PCS en utilisant SOAP UI ou Postman Client et soyez sûr que le Invoke est bien réussi et que les résultats sont bien retournés. Si c’est bien le cas, il devrait fonctionner sous PCS.
Pour en finir, je vous présente de manière très brève l’interface associée en Web Forms, tout en notant, qu’il n’y a pas d’option en PCS pour implémenter l’interface utilisateur de la Humain Task ou « tâche humaine » avec ADF. Cela doit être fait avec Web Forms, le framework d’implémentation de formulaires d’interface utilisateur légère.
Ceci peut être un inconvénient, car il faudra externaliser la logique métier complexe et accéder aux collectes des données via des appels REST, au lieu de les traiter localement dans l’extension ADF.
Cet article était assez long, mais j’ai voulu partager avec vous l’offre PCS ou le BPM en Cloud à travers ce POC réalisé et j’en profite pour remercier Pierre Gelli, Michel Ribault et Mohammed Elkhoudiri pour le support durant la réalisation de ce POC en 2016.
Et Merci 🙂
