La deuxième fois, nous échangerons des données avec EHRbase à l'aide de l'API REST. EHRbase possède de nombreuses API REST, y compris celles en cours de développement. Cette fois, je présenterai les API suivantes liées au modèle et à la composition.
Pour gérer l'API REST d'EHRbase, il est facile d'utiliser l'interface utilisateur Swagger du Web fournie par EHRbase. Cependant, je pense qu'il est préférable d'utiliser Postman pour le développement car il n'y a pas de restes.
Il existe de nombreux outils pour créer des modèles openEHR, dont certains peuvent être créés sur le Web, mais Ocean Template Designer a une longue histoire et de nombreux utilisateurs.
Au début des années 1990 et au début des années 2000, lorsque le développement d'openEHR a commencé, des interfaces ont été implémentées dans RPC et SOAP. En tant qu'interface externe, un langage d'appel appelé AQL (Archetype Query Language) est préparé, et il était courant dans openEHR de l'utiliser pour communiquer avec l'extérieur. Cependant, dans les années 2010, l'API REST est devenue courante et chaque entreprise qui a mis en œuvre openEHR, y compris en coopération avec FHIR, a mis en œuvre l'API REST.
En tant qu'openEHR, l'API REST est normalisée et publiée comme suit.
https://specifications.openehr.org/releases/ITS-REST/latest
Cependant, Marand a annoncé une API qui utilise le format JSON simplifié et, à la suite du suivi d'autres implémentations, car c'est pratique, il existe des variations dans les paramètres et les méthodes de simplification. À la suite des discussions au sein du comité de développement de spécification openEHR, le format de données simplifié a également été normalisé et est publié comme suit.
Norme de modèle de données simplifiée https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html
API Marand EHR Cape https://dev.ehrscape.com/api-explorer.html
EtherCIS, l'un des prédécesseurs de EHRbase, avait sa propre simplification, mais il a maintenant été supprimé et est mis en œuvre sur la base de la nouvelle norme de modèle de données simplifiée. (Sortie prévue vers décembre 2020)
Je n'expliquerai pas à nouveau l'API REST. Pour le simplifier énormément, accédez à une URL spécifique en utilisant la méthode HTTP et échangez des données, mais je pense qu'EHRbase est déployé dans chaque environnement, il n'est donc pas possible d'écrire une notation URL unifiée. .. Par conséquent, cette fois, omettez la partie de http: // à ehrbase / dans l'URL suivante et écrivez l'API REST comme suit (veuillez me faire savoir s'il existe un bon moyen de l'écrire).
Exemple: lorsque vous essayez d'incorporer des informations relatives à ehr_id avec des paramètres à l'aide de la méthode GET à l'adresse http: // localhost: 8080 / ehrbase / rest / openehr / v1 / ehr
GET /rest/openehr/v1/ehr/{{ehr_id}}
Paramètres
| key | value |
|---|---|
| subject_id | ins01 |
| subject_namespace | ehr_craft |
La demande réelle émise est la suivante. Le {{}} qui apparaît dans l'URL indique qu'il s'agit d'une partie variable.
curl -X GET "http://localhost:8080/ehrbase/rest/openehr/v1/ehr/f2e3ebf3-596b-4067-9f76-8f4f19c0c474?subject_id=ehr_craft&subject_namespace=ins01" -H "accept: application/xml"
EHR class openEHR gère les données patient par patient. Le DSE est l'unité qui stocke les données pour chaque patient. Imaginez faire une boîte pour stocker les données des patients, pas le système de DSE lui-même. Par conséquent, créer un DSE à l'aide de l'API REST ne signifie pas créer un système de DSE. Dans l'architecture openEHR, les informations d'attribut telles que le nom, l'adresse et le sexe du patient ne sont pas stockées directement dans le DSE, mais sont concaténées en appelant l'ID de classe de DSE à partir d'une base de données externe d'informations sur les patients.
Ceci est conçu avec l'hypothèse que le DSE sera utilisé comme base de données anonyme.
Si vous souhaitez simplement créer un nouvel enregistrement de DSE, effectuez simplement un POST sans paramètres comme ci-dessous.
POST /rest/openehr/v1/ehr
Veuillez lire la partie de localhost: 8080 dans l'URL de chaque environnement. Vous recevrez une réponse comme indiqué ci-dessous, vous devez donc enregistrer le ehr_id.
{
"system_id": {
"_type": "HIER_OBJECT_ID",
"value": "b1718dd8-a45a-4ebf-a1d6-9a9fd7ca36fb"
},
"ehr_id": {
"_type": "HIER_OBJECT_ID",
"value": "fa95a254-feb0-4b03-9fe3-193d7d485d45"
},
"ehr_status": {
"_type": "EHR_STATUS",
"subject": {
"_type": "PARTY_SELF",
"external_ref": {
"_type": "PARTY_REF",
"namespace": "default",
"id": {
"_type": "HIER_OBJECT_ID",
"value": "a258c07e-7b64-4062-b449-f96504e54a94"
}
}
},
"uid": {
"_type": "HIER_OBJECT_ID",
"value": "1220e446-b637-4c39-a62b-1e53f479ffea"
},
"is_queryable": true,
"is_modifiable": true
},
"time_created": "2020-09-26T02:11:21.214052"
}
L'ID de DSE est la partie suivante.
"ehr_id": {
"_type": "HIER_OBJECT_ID",
"value": "fa95a254-feb0-4b03-9fe3-193d7d485d45"
},
Enregistrez l'ID de DSE car vous en aurez besoin lors de la lecture des données de DSE. Si vous ne savez pas, EHRbase n'a pas d'API pour obtenir une liste des ID EHR, vous devez donc regarder à l'intérieur de PostgreSQL.
Si l'ID du patient existe déjà, tel que le numéro du ticket de consultation, joignez le message JSON suivant et POST à / rest / v1 / ehr pour enregistrer également l'ID externe.
POST /rest/openehr/v1/ehr
body
{
"_type": "EHR_STATUS",
"subject": {
"external_ref": {
"id": {
"_type": "GENERIC_ID",
"value": "ins11",
"scheme": "id_scheme"
},
"namespace": "ehr_craft",
"type": "PERSON"
}
},
"is_modifiable": "true",
"is_queryable": "true"
}
Veuillez noter que dans l'exemple EHRbase et l'interface utilisateur Swagger, ITEM contient d'autres_détails vides, ce qui génère une erreur.
Si l'ID externe est dupliqué, l'erreur suivante sera renvoyée, alors ne vous inquiétez pas trop et émettez de plus en plus de DSE.
{
"error": "Specified party has already an EHR set (partyId=ce8bf586-125d-4c28-9970-465eacbaa8c4)",
"status": "Conflict"
}
Appelons le DSE créé par POST par EHR ID. Au lieu de {{EHR ID}}, spécifiez l'ehr_id renvoyé précédemment.
GET /rest/openehr/v1/ehr/{{EHR ID}}
S'il a été créé, les mêmes données que le contenu enregistré seront renvoyées. La valeur par défaut est JSON, mais si vous spécifiez Accepter application / xml dans l'en-tête HTTP comme indiqué ci-dessous, les données seront renvoyées au format XML.
HTTP header
| key | value |
|---|---|
| Accept | application/xml |
GET /rest/openehr/v1/ehr/
Paramètres
| key | value |
|---|---|
| subject_id | 0001 |
| subject_namespace | NPO openEHR Japan |
Dans openEHR, l'unité de données enregistrée dans le DSE est la composition, et les enregistrements graphiques, divers rapports, les résultats d'inspection, etc. sont enregistrés en tant que composition. Diverses restrictions sont décrites dans Modèle basé sur la composition.
Par exemple, créez un modèle pour surveiller la température corporelle et les symptômes. L'archétype utilisé est le suivant.
Après avoir créé un modèle à l'aide de Ocean Template Designer, exportez-le en tant que «modèle disponible». Le fichier dont l'identifiant de fichier est sorti sous la forme opt est appelé modèle opérationnel (ci-après dénommé OPT). Toutes les données à traiter sont définies dans ce fichier et écrites en XML.
Si vous mettez un espace dans l'ID Tempate, des problèmes tels que l'impossibilité de lire avec EHRbase se sont produits, veuillez donc l'éviter pour le moment.
L'OPT utilisé cette fois est publié sous le nom symptom_screening.opt.
Enregistrons Template (OPT) dans EHRbase par POST.
POST /rest/openehr/v1/definition/template/adl1.4
Collez le contenu du fichier opt créé précédemment dans le corps. Le modèle est identifié par template_id et uid, donc si l'un ou l'autre est porté, une erreur sera renvoyée.
<uid>
<value>17bed299-2c1e-42cc-afb3-6d78002dcce3</value>
</uid>
<template_id>
<value>symptom_screening</value>
</template_id>
Utilisez la méthode GET pour vérifier si le modèle POSTed est enregistré dans EHRbase. Lisons-le en utilisant le template_id du modèle enregistré précédemment. Entrez symbol_screening à la place de {{template_id}}.
GET /rest/openehr/v1/definition/template/adl1.4/{{template_id}}
L'OPT enregistré sera renvoyé en réponse.
Obtenez et vérifiez la liste actuellement enregistrée.
GET /rest/openehr/v1/definition/template/adl1.4/
Une liste comme celle ci-dessous sera retournée
[
{
"concept": "symptom_screening",
"template_id": "symptom_screening",
"archetype_id": "openEHR-EHR-COMPOSITION.health_summary.v1",
"created_timestamp": "2020-09-25T03:17:54.134Z"
}
]
Créer une instance de JSON ou XML basée sur le contenu défini dans Template n'est pas si simple, donc je crée un outil automatique.
EHRbase fournit le openEHR-SDK, qui vous permet de générer un ensemble de classes pouvant accéder à EHRbase à partir d'OPT.
Je développais un groupe d'outils qui génèrent automatiquement des modèles pour l'instance JSON utilisée cette fois, mais il a fallu beaucoup de temps pour enquêter car l'instance JSON n'était pas tellement publiée en premier lieu. Enfin, j'ai créé une instance qui fonctionne il y a un jour, donc cette fois je vais effectuer un accès à la composition en fonction de celle-ci.
La procédure créée est la suivante.
L'instance créée est publiée sur GIST.
https://gist.github.com/skoba/cca9f69004a229e5922a0e3e73dca53e
Enregistrez l'instance de composition créée à l'aide de l'API REST. Il sera lié à l'ID de DSE qui a déjà été enregistré.
POST /rest/openehr/v1/ehr/{{EHR ID}}/composition
Collons le JSON de GIST dans le corps.
L'en-tête de réponse est important. L'ETag contient des données au format «89b114ea-59bd-4d98-b9b8-ad8f819a5aa3 :: local.ehrbase.org :: 1», qui est appelé l'UID de l'objet versionné. L'UUID affecté à l'enregistrement Composition et l'URL unique et le numéro de version enregistrés dans EHR sont écrits séparés par ::. Cet UUID sera l'ID de l'enregistrement de composition.
Lisez les données enregistrées à l'aide de l'ID EHR et de l'ID de composition.
GET /rest/openehr/v1/ehr/{{EHR ID}}/composition/{{Composition ID}}
Saisissez respectivement l'ID EHR et l'ID de composition enregistrés dans {{ID EHR}} et {{ID composition}}. Les mêmes données que le JSON enregistré seront renvoyées.
Utilisez PUT pour changer le contenu s'il y a une correction.
PUT /rest/openehr/v1/ehr/{{EHR ID}}/composition/{{Composition ID}}
Pour boody, utilisez une version modifiée de JSON.
L'important ici est l'UID d'objet de version de Coposition, qui était également dans Etag plus tôt. Spécifiez ce qui suit dans l'en-tête de la requête HTTP.
| key | value |
|---|---|
| If-Match | version_object_uid |
En cas de succès, un nouvel uid d'objet de version sera renvoyé dans l'ETag de l'en-tête de réponse.
Dans openEHR, toutes les COMPOSITION sont contrôlées par version. Si vous utilisez l'uid d'objet versionné plus tôt, vous pouvez récupérer les données avant et après la composition que vous avez mise à jour précédemment.
GET /rest/openehr/v1/ehr/{{EHR ID}}/composition/{versioned object uid}}
Modifiez la version à la fin pour voir la différence dans les données.
Dans openEHR, la suppression d'un enregistrement n'est qu'une suppression logique, elle devient tout simplement illisible et continue d'être enregistrée en tant que base de données. C'est une fonctionnalité rare, mais si vous souhaitez la supprimer, utilisez DELETE avec la dernière version de l'uid oject versionné.
DELETE /rest/openehr/v1/ehr/{{EHR ID}}/composition/{versioned object uid}}
Si vous spécifiez une version autre que la dernière version, cette version sera supprimée, mais vous pourrez toujours lire les autres versions. Si vous supprimez la dernière version, vous ne pourrez pas y accéder depuis l'API, y compris l'ancienne version.
Recommended Posts