JMP Clinique a été publié il y a 11 ans spécifiquement pour l'analyse et l'examen des essais cliniques en cours centrés sur des données standardisées et structurées. L'intention était qu'un examinateur reçoive des données à examiner à intervalles réguliers (chaque semaine ou chaque mois) pour rechercher des signaux d'innocuité et/ou d'efficacité à l'aide de rapports préprogrammés, permettant à l'examinateur de se servir et d'approfondir les données sur -demande. L'espoir était d'accélérer le processus d'examen ainsi que de découvrir des anomalies qui pourraient autrement passer inaperçues lors de l'examen de tableaux statiques, de listes et de chiffres.
De plus, l'un des objectifs du logiciel était d'alléger le fardeau imposé aux équipes de programmation qui produisent les données demandées et les rapports standardisés pour les examinateurs. Cela nécessitait beaucoup de temps pour exécuter des programmes ou éditer des programmes/scripts/macro pour répondre aux besoins des réviseurs et sur une base fréquente. Les groupes de programmation et de biostatistique veulent généralement se concentrer sur les données et les rapports qui sont uniques à l'étude au lieu du tableau ou du graphique habituel qui est assez cohérent d'une étude à l'autre, ce qui leur permet d'accorder une attention plus solide et sans distraction aux anomalies spécifiques à l'étude qui nécessitent plus de connaissances statistiques ou algorithmiques.
Dans la plupart des cas, JMP Clinical a atteint ces objectifs, sauf si nous parlons d'organisations qui ont de nombreuses études qui doivent être surveillées et/ou qui ont des mises à jour fréquentes des données. Cela impose un nouveau fardeau aux équipes de gestion des données et de biostatistique pour mettre à jour les études au sein de JMP Clinical ou impose un fardeau aux examinateurs qui n'étaient pas aussi compétents dans le processus ou qui n'avaient pas le temps. La possibilité de modifier certains des rapports dans JMP Clinical et/ou d'exécuter le même modèle d'examen sur une base programmée était également intéressante. La demande d'automatisation et d'extension des capacités de JMP Clinical est devenue une demande fréquente.
Entrez les API de JMP Clinical. Autour de JMP Clinical 6, nous avons introduit le cadre et l'infrastructure pour rendre l'accès basé sur l'API aux fonctions/processus communs par programmation possible. Dans JMP Clinical 7, les API ont été publiées et mises à disposition à l'aide du langage de script JMP (JSL). Dans la version 8 (la dernière), plus de fonctionnalités ont été publiées. Cet article n'entre pas dans les détails du développement des API. Au lieu de cela, il se concentre sur leur utilisation pratique afin que vous puissiez en profiter.
Je partagerai une série de messages sur la façon d'invoquer et d'utiliser les API. Nous commençons simplement en introduisant la syntaxe de base et leur utilisation. Ensuite, nous progressons vers des utilisations plus sophistiquées en utilisant JSL. Et enfin, nous combinons les deux catégories d'API invoquées au sein de certaines JSL.
Pour ceux qui ne connaissent pas les termes Étude, Examen, Rapport et Modèle d'examen dans le contexte de JMP Clinical, veuillez consulter ce relier faire connaissance. De plus, ceux qui ne sont pas familiers avec JSL devraient lire et en savoir plus sur ce relier . La connaissance des deux est nécessaire pour comprendre l'utilisation des API.
Pour cet article, commençons par les deux catégories principales et ce qui est possible. Les deux catégories principales sont : les fonctions liées à la gestion des études (JMPClinicalStudyManagerAPI) et les fonctions liées à la revue (JMPClinicalReviewAPI). L'idée est de reproduire ce qui peut être fait dans l'interface utilisateur (principalement les clics sur le bouton) où l'utilisateur n'a pas besoin d'une décision (comme l'actualisation des métadonnées pour les études avec de nouvelles données ou l'ouverture d'un modèle de révision et son exécution pour une étude spécifique). Vous trouverez ci-dessous quelques images qui mettent en évidence les boutons liés à la section Gestion de l'étude et à la section Révision.
Fonctions de gestion des études liées à JMPClinicalStudyMangerAPI
Réviser/Réviser les fonctions du générateur liées à JMPClinicalReviewAPI
L'API est destinée à prendre en charge les tâches de routine et à les automatiser, comme l'actualisation des études avec de nouvelles métadonnées ou pour ajouter/supprimer du contenu d'un rapport dans un modèle de révision. Voici un lien pour le JMPClinicalStudyManagerAPI fonctions et un autre lien pour le JMPClinicalReviewAPI fonctions pour référence.
Alors, que peut nous apporter cette API JMPClinicalStudyMangerAPI ? Il nous fournit deux ensembles de fonctions : les fonctions d'obtention (celles qui obtiennent des informations sur les études) et les fonctions de manipulation (celles qui ajoutent, suppriment ou mettent à jour des études). Voici un tableau de ce qui est possible avec la syntaxe de base pour appeler cette fonction. Les deux points (:) séparent l'appel d'API et l'appel de fonction. Certaines fonctions ont des entrées et/ou des retours. Voir les liens ci-dessus pour plus de détails sur ce qui est attendu comme entrée et retour.
API de gestion des études
|
Fonctions d'obtention d'informations
|
Manipuler les fonctions d'étude
|
Obtenez la liste des noms d'étude :
API JMPClinicalStudyManager:getStudyList
|
Ajouter une étude :
API JMPClinicalStudyManager:addStudy
|
Obtenez le chemin du dossier SDTM :
API JMPClinicalStudyManager:getSDTFolder
|
Actualiser les métadonnées de l'étude :
JMPClinicalStudyManagerAPI:refreshStudies
|
Obtenir le chemin du dossier ADaM :
API JMPClinicalStudyManager:getADaMFolder
|
Supprimer l'étude :
API JMPClinicalStudyManager:supprimer les études
|
Obtenir la date de l'étude a été ajouté :
API JMPClinicalStudyManager:getInitialDate
|
Mettre à jour l'étude avec un nouvel instantané :
API JMPClinicalStudyManager : mise à jour de l'instantané
|
Obtenir la date de la dernière mise à jour de l'étude :
API JMPClinicalStudyManager:getLastUpdatedDate
|
Changer les dossiers de données d'étude :
JMPClinicalStudyManagerAPI:changeFolders
|
Obtenir l'état d'activation de l'instantané :
API JMPClinicalStudyManager:getEnableSnapshot
|
Pré-calculer les données du profil du patient :
API JMPClinicalStudyManager:precalculerProfileData
|
Obtenir le numéro d'instantané :
API JMPClinicalStudyManager:getSnapshotNumber
|
|
Obtenez la liste des domaines reconnus :
API JMPClinicalStudyManager:getDomainList
|
|
Obtenir la taille du fichier sur le disque :
API JMPClinicalStudyManager:getSizeOnDisk
|
|
Obtenez l'ID utilisateur du système d'exploitation Windows qui a créé/ajouté l'étude :
API JMPClinicalStudyManager:getCreatedBy
|
|
Obtenez l'ID utilisateur du système d'exploitation Windows qui a mis à jour la dernière étude :
API JMPClinicalStudyManager:getLastUpdatedBy
|
|
Examinons maintenant la deuxième catégorie, les fonctions de révision. Celui-ci dispose également d'un ensemble de fonctions d'obtention et de manipulation, mais pour les revues et les rapports.
Passer en revue l'API
|
Fonctions d'obtention d'informations
|
Manipuler les fonctions de rapport/revue
|
Obtenez une référence à Review Builder :
JMPClinicalReviewAPI:getReviewBuilder
|
Fermer le générateur d'avis :
JMPClinicalReviewAPI:closeReviewBuilder
|
Obtenez l'ID et le titre de la visionneuse d'avis/générateur :
JMPClinicalReviewAPI:getReviewViewerIDsAndTitles
|
Ouvrir le modèle d'examen :
JMPClinicalReviewAPI:openReviewTemplate
|
Obtenez une référence à la visionneuse d'avis :
JMPClinicalReviewAPI:getReviewViewer
|
Ajouter un rapport à Review Builder :
JMPClinicalReviewAPI:addReport
|
Obtenir la table des matières de la visionneuse/constructeur d'avis :
JMPClinicalReviewAPI:getReviewTableOfContents
|
Supprimer le formulaire de rapport Review Builder par titre :
JMPClinicalReviewAPI:removeReportByReportTitle
|
Obtenez une liste des ID de rapport :
JMPClinicalReviewAPI:getReportIDList
|
Exécuter le rapport dans Review Builder par titre :
JMPClinicalReviewAPI:runReportByReportTitle
|
Obtenez une liste des titres de rapport :
JMPClinicalReviewAPI:getReportTitleList
|
Exécutez tous les rapports dans Review Builder :
JMPClinicalReviewAPI:runAllReports
|
Obtenir une référence à un rapport par ID :
JMPClinicalReviewAPI:getReportByID
|
Enregistrer le contenu de Review Builder en tant que révision :
JMPClinicalReviewAPI:saveReview
|
Obtenir une référence à un rapport par titre :
JMPClinicalReviewAPI:getReportByTitle
|
Ouvrez un avis dans la visionneuse d'avis :
JMPClinicalReviewAPI:openReview
|
Obtenez les détails du rapport par titre :
JMPClinicalReviewAPI:getReportDetailsByTitle
|
Insérer une section dans un rapport :
JMPClinicalReviewAPI:insertSectionIntoReportByTitleAndSectionName
|
Obtenez une référence aux résultats du rapport :
JMPClinicalReviewAPI:getReportResultsByTitle
|
Supprimer une section d'un rapport :
JMPClinicalReviewAPI:removeSectionFromReportByTitleAndSectionName
|
Obtenez une référence à la section Rapport :
JMPClinicalReviewAPI:getReportSectionByTitleAndSectionName
|
Ajouter à la fin de la section Rapport :
JMPClinicalReviewAPI:appendDisplayObjectToReportSectionByTitleAndSectionName
|
Obtenir la liste des tables de données utilisées dans le rapport :
JMPClinicalReviewAPI:getDataTablesForSectionByTitleAndSectionName
|
Ajouter au début de la section Rapport :
JMPClinicalReviewAPI:prependDisplayObjectToReportSectionByTitleAndSectionName
|
Alors maintenant, nous avons répertorié les différentes fonctions et ce qu'elles peuvent faire. Il est maintenant temps de montrer la syntaxe de base de leur utilisation. La forme de base est la suivante :
JMPClinical<CATEGORY>API:<FUNCTION> ({argument(s)}, {namespace}, completeListenerFunction());</FUNCTION></CATEGORY>
J'ai déjà présenté l'appel de base aux fonctions API liées à la gestion des études ci-dessus lorsque j'ai fait référence à JMPClinicalStudyManagerAPI. Donc, si je veux actualiser les métadonnées des études enregistrées, cela ressemblera à ceci :
JMPClinicalStudyManager:refreshStudies ({studyList},{},{});
Nous allons disséquer cela davantage et parler des utilisations courantes dans la prochaine série de messages. Pour l'instant, je voulais présenter ce qui est disponible et comment l'invoquer généralement dans un script JSL. Le prochain article traitera d'un exemple de l'API de gestion d'étude, parlera davantage de l'espace de noms et des parties completeListener de l'appel d'API et commencera à l'envelopper dans JSL ainsi qu'à utiliser JSL en son sein.
En attendant le prochain post, prenez soin de vous !
