Beim zweiten Mal werden wir mithilfe der REST-API Daten mit EHRbase austauschen. EHRbase verfügt über viele REST-APIs, einschließlich der in der Entwicklung befindlichen. Dieses Mal werde ich die folgenden APIs in Bezug auf Vorlage und Komposition vorstellen.
Um die REST-API von EHRbase zu handhaben, ist es einfach, die von EHRbase bereitgestellte Swagger-Benutzeroberfläche des Webs zu verwenden. Ich denke jedoch, dass es besser ist, Postman für die Entwicklung zu verwenden, da es keine Reste gibt.
Es gibt viele Tools zum Erstellen von openEHR-Vorlagen, von denen einige im Web erstellt werden können. Ocean Template Designer hat jedoch eine lange Geschichte und viele Benutzer.
In den frühen 1990er und frühen 2000er Jahren, als die Entwicklung von openEHR begann, wurden Schnittstellen in RPC und SOAP implementiert. Als externe Schnittstelle wurde eine aufrufende Sprache namens AQL (Archetype Query Language) vorbereitet, die in openEHR häufig für die Kommunikation mit der Außenwelt verwendet wurde. In den 2010er Jahren wurde die REST-API jedoch zum Mainstream, und jedes Unternehmen, das openEHR implementierte, einschließlich der Zusammenarbeit mit FHIR, implementierte die REST-API.
Als openEHR wird die REST-API wie folgt standardisiert und freigegeben.
https://specifications.openehr.org/releases/ITS-REST/latest
Marand kündigte jedoch eine API an, die das vereinfachte JSON-Format verwendet. Aufgrund der Befolgung anderer Implementierungen gibt es Variationen bei den Parametern und Vereinfachungsmethoden, da dies zweckmäßig ist. Infolge der Diskussionen im openEHR-Spezifikationsentwicklungsausschuss wurde auch das vereinfachte Datenformat standardisiert und wie folgt veröffentlicht.
Vereinfachter Datenvorlagenstandard https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html
Marand EHR Cape API https://dev.ehrscape.com/api-explorer.html
EtherCIS, einer der Vorgänger von EHRbase, hatte eine eigene Vereinfachung, wurde jedoch jetzt entfernt und wird basierend auf dem neuen vereinfachten Datenvorlagenstandard implementiert. (Wird voraussichtlich im Dezember 2020 veröffentlicht.)
Ich werde die REST-API nicht noch einmal erklären. Um dies erheblich zu vereinfachen, greifen Sie mithilfe der HTTP-Methode auf eine bestimmte URL zu und tauschen Sie Daten aus. Ich denke jedoch, dass EHRbase in jeder Umgebung bereitgestellt wird, sodass es nicht möglich ist, eine einheitliche URL-Notation zu schreiben. .. Lassen Sie daher dieses Mal den Teil von http: // bis ehrbase / in der folgenden URL weg und schreiben Sie die REST-API wie folgt (bitte lassen Sie mich wissen, ob es eine gute Möglichkeit gibt, sie zu schreiben).
Beispiel: Wenn Sie versuchen, Informationen zu ehr_id mit Parametern mithilfe der GET-Methode unter http: // localhost: 8080 / ehrbase / rest / openehr / v1 / ehr zu integrieren
GET /rest/openehr/v1/ehr/{{ehr_id}}
Parameter
| key | value |
|---|---|
| subject_id | ins01 |
| subject_namespace | ehr_craft |
Die tatsächlich ausgegebene Anfrage lautet wie folgt. Das {{}} in der URL zeigt an, dass es sich um einen variablen Teil handelt.
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 verwaltet Daten von Patient zu Patient. EHR ist die Einheit, die Daten für jeden Patienten speichert. Stellen Sie sich vor, Sie erstellen eine Box zum Speichern von Patientendaten, nicht das EHR-System selbst. Das Erstellen einer EHR mithilfe der REST-API bedeutet daher nicht das Erstellen eines EHR-Systems. In der openEHR-Architektur werden Attributinformationen wie Patientenname, Adresse und Geschlecht nicht direkt in EHR gespeichert, sondern durch Aufrufen der EHR-Klassen-ID aus einer externen Patienteninformationsdatenbank verknüpft.
Dies basiert auf der Annahme, dass EHR als anonyme Datenbank verwendet wird.
Wenn Sie nur einen neuen EHR-Datensatz erstellen möchten, POST ohne die folgenden Parameter.
POST /rest/openehr/v1/ehr
Bitte lesen Sie den Teil von localhost: 8080 in der URL in jeder Umgebung. Sie erhalten eine Antwort wie unten gezeigt, daher müssen Sie die ehr_id speichern.
{
"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"
}
Die EHR-ID ist der folgende Teil.
"ehr_id": {
"_type": "HIER_OBJECT_ID",
"value": "fa95a254-feb0-4b03-9fe3-193d7d485d45"
},
Speichern Sie die EHR-ID so, wie Sie sie beim Lesen der EHR-Daten benötigen. Wenn Sie es nicht wissen, verfügt EHRbase nicht über eine API, um eine Liste der EHR-IDs abzurufen. Sie müssen also in PostgreSQL nachsehen.
Wenn die Patienten-ID wie die Nummer des Konsultationstickets bereits vorhanden ist, hängen Sie die folgende JSON-Nachricht und den POST an / rest / v1 / ehr an, um auch die externe ID zu speichern.
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"
}
Bitte beachten Sie, dass ITEM im EHRbase-Beispiel und in der Swagger-Benutzeroberfläche leere other_details enthält, was zu einem Fehler führt.
Wenn die externe ID dupliziert wird, wird der folgende Fehler zurückgegeben. Machen Sie sich also keine Sorgen und geben Sie immer mehr EHR aus.
{
"error": "Specified party has already an EHR set (partyId=ce8bf586-125d-4c28-9970-465eacbaa8c4)",
"status": "Conflict"
}
Nennen wir die von POST erstellte EHR anhand der EHR-ID. Geben Sie anstelle von {{EHR ID}} die zuvor zurückgegebene ehr_id an.
GET /rest/openehr/v1/ehr/{{EHR ID}}
Wenn es erstellt wurde, werden die gleichen Daten wie der registrierte Inhalt zurückgegeben. Der Standardwert ist JSON. Wenn Sie jedoch im HTTP-Header die Option Anwendung / XML akzeptieren wie unten gezeigt angeben, werden die Daten im XML-Format zurückgegeben.
HTTP header
| key | value |
|---|---|
| Accept | application/xml |
GET /rest/openehr/v1/ehr/
Parameter
| key | value |
|---|---|
| subject_id | 0001 |
| subject_namespace | NPO openEHR Japan |
In openEHR ist die in EHR registrierte Dateneinheit Zusammensetzung, und Diagrammaufzeichnungen, verschiedene Berichte, Prüfergebnisse usw. werden als Zusammensetzung aufgezeichnet. Verschiedene Einschränkungen werden in Vorlage basierend auf Zusammensetzung beschrieben.
Erstellen Sie beispielsweise eine Vorlage zur Überwachung der Körpertemperatur und der Symptome. Der verwendete Archetyp ist wie folgt.
Exportieren Sie eine Vorlage nach dem Erstellen mit Ocean Template Designer als "Verfügbare Vorlage". Die Datei, deren Dateikennung als opt ausgegeben wird, wird als Betriebsvorlage bezeichnet (im Folgenden als OPT bezeichnet). Alle zu verarbeitenden Daten werden in dieser Datei definiert und in XML geschrieben.
Wenn Sie ein Leerzeichen in die Tempate-ID einfügen, haben Sie möglicherweise Probleme, es mit EHRbase zu lesen. Vermeiden Sie es daher zu diesem Zeitpunkt.
Das diesmal verwendete OPT wird als symptom_screening.opt veröffentlicht.
Registrieren wir Template (OPT) in EHRbase per POST.
POST /rest/openehr/v1/definition/template/adl1.4
Fügen Sie den Inhalt der zuvor erstellten opt-Datei in den Body ein. Die Vorlage wird durch template_id und uid identifiziert. Wenn also eine der beiden abgenutzt ist, wird ein Fehler zurückgegeben.
<uid>
<value>17bed299-2c1e-42cc-afb3-6d78002dcce3</value>
</uid>
<template_id>
<value>symptom_screening</value>
</template_id>
Verwenden Sie die GET-Methode, um zu überprüfen, ob die POST-Vorlage in EHRbase registriert ist. Lesen wir es mit der template_id der zuvor registrierten Vorlage. Geben Sie symbol_screening anstelle von {{template_id}} ein.
GET /rest/openehr/v1/definition/template/adl1.4/{{template_id}}
Das registrierte OPT wird als Antwort zurückgegeben.
Holen Sie sich die aktuell registrierte Liste und überprüfen Sie sie.
GET /rest/openehr/v1/definition/template/adl1.4/
Eine Liste wie die folgende wird zurückgegeben
[
{
"concept": "symptom_screening",
"template_id": "symptom_screening",
"archetype_id": "openEHR-EHR-COMPOSITION.health_summary.v1",
"created_timestamp": "2020-09-25T03:17:54.134Z"
}
]
Das Erstellen einer Instanz von JSON oder XML basierend auf den in der Vorlage definierten Inhalten ist nicht so einfach, daher erstelle ich ein automatisches Tool.
EHRbase bietet das openEHR-SDK, mit dem Sie eine Reihe von Klassen generieren können, die über OPT auf EHRbase zugreifen können.
Ich habe eine Gruppe von Tools entwickelt, die automatisch Vorlagen für die diesmal verwendete JSON-Instanz generieren. Die Untersuchung hat jedoch lange gedauert, da die JSON-Instanz überhaupt nicht so häufig veröffentlicht wurde. Schließlich habe ich eine Instanz erstellt, die vor einem Tag funktioniert, und dieses Mal werde ich darauf basierend einen Kompositionszugriff durchführen.
Die erstellte Prozedur ist wie folgt.
Die erstellte Instanz wird in GIST veröffentlicht.
https://gist.github.com/skoba/cca9f69004a229e5922a0e3e73dca53e
Registrieren Sie die erstellte Composition-Instanz mithilfe der REST-API. Es wird mit der bereits registrierten EHR-ID verknüpft.
POST /rest/openehr/v1/ehr/{{EHR ID}}/composition
Fügen wir den JSON von GIST in den Körper ein.
Der Respose-Header ist wichtig. Das ETag enthält Daten im Format "89b114ea-59bd-4d98-b9b8-ad8f819a5aa3 :: local.ehrbase.org :: 1", das als Versioned Object UID bezeichnet wird. Die dem Kompositionsdatensatz zugewiesene UUID sowie die in EHR registrierte eindeutige URL und Versionsnummer werden getrennt durch :: geschrieben. Diese UUID ist die ID des Kompositionsdatensatzes.
Lesen Sie die mit EHR ID und Composition ID registrierten Daten.
GET /rest/openehr/v1/ehr/{{EHR ID}}/composition/{{Composition ID}}
Geben Sie die registrierte EHR-ID und die Kompositions-ID in {{EHR-ID}} bzw. {{Kompositions-ID}} ein. Die gleichen Daten wie der registrierte JSON werden zurückgegeben.
Verwenden Sie PUT, um den Inhalt zu ändern, wenn eine Korrektur vorliegt.
PUT /rest/openehr/v1/ehr/{{EHR ID}}/composition/{{Composition ID}}
Verwenden Sie für Boody eine modifizierte Version von JSON.
Das Wichtigste dabei ist die Versionsobjekt-UID der Koposition, die auch früher in Etag enthalten war. Geben Sie im HTTP-Anforderungsheader Folgendes an.
| key | value |
|---|---|
| If-Match | version_object_uid |
Bei Erfolg wird eine neue Versionsobjekt-UID im ETag des Antwortheaders zurückgegeben.
In openEHR sind alle COMPOSITIONs versioniert. Wenn Sie die zuvor erwähnte versionierte Objekt-UID verwenden, können Sie die Daten vor und nach der Komposition abrufen, die Sie zuvor aktualisiert haben.
GET /rest/openehr/v1/ehr/{{EHR ID}}/composition/{versioned object uid}}
Ändern Sie die Version am Ende, um den Unterschied in den Daten zu sehen.
In openEHR ist das Löschen eines Datensatzes nur eine logische Löschung, es wird nur unlesbar und wird weiterhin als Datenbank gespeichert. Es ist eine seltene Funktion, aber wenn Sie sie löschen möchten, verwenden Sie DELETE mit der neuesten Version der versionierten Objekt-UID.
DELETE /rest/openehr/v1/ehr/{{EHR ID}}/composition/{versioned object uid}}
Wenn Sie eine andere Version als die neueste Version angeben, wird diese Version gelöscht, Sie können jedoch weiterhin andere Versionen lesen. Wenn Sie die neueste Version löschen, können Sie nicht über die API einschließlich der alten Version darauf zugreifen.
Recommended Posts