Guía de Implementación "cl core" FHIR R4, (Versión Evolutiva)
1.8.2 - ci-build
This page is part of the Chile Core (v1.8.2: STU2 Draft) based on FHIR R4. . For a full list of available versions, see the Directory of published versions
Las Operaciones que se pueden ejecutar como base en el manejo de recuros en FHIR se especifican desde el mismo estándar traves de Resumen de operaciones
Como nota que todos los requests pueden incluir un opcional Accept
como cabecera que indica el formato que se debe usar como respuesta (esto incluso se aplica a DELETE
dado que una OperationOutcome debe ser devuelta).
Interacción | Ruta | Request | ||||
---|---|---|---|---|---|---|
Método | Content-Type | Body | Prefer | Condcional (si aplica) | ||
`read` | `/[type]/[id]` | `GET` | N/A | N/A | N/A | O: `ETag`, `If-Modified-Since`, `If-None-Match` |
`vread` | `/[type]/[id]/_history/[vid]` | `GET` | N/A | N/A | N/A | N/A |
`update` | `/[type]/[id]` | `PUT` | R | Resource | O | O: `If-Match` |
`patch` | `/[type]/[id]` | `PATCH` | R (may be a patch type) | Patch | O | O: `If-Match` |
`delete` | `/[type]/[id]` | `DELETE` | N/A | N/A | N/A | N/A |
`create` | ``/[type]`` | POST | R | Resource | O | O: `If-None-Exist` |
`search` | `/[type]?` | `GET` | N/A | N/A | N/A | N/A |
`/[type]/_search?` | `POST` | `application/x-www-form-urlencoded` | form data | N/A | N/A | |
`search-all` | `?` | `GET` | N/A | N/A | N/A | N/A |
`capabilities` | `/metadata` | `GET` | N/A | N/A | N/A | N/A |
`transaction` | `/` | `POST` | R | `Bundle` | O | N/A |
`history` | `/[type]/[id]/_history` | `GET` | N/A | N/A | N/A | N/A |
`history-type` | `/[type]/_history` | `GET` | N/A | N/A | N/A | N/A |
`history-all` | `/_history` | `GET` | N/A | N/A | N/A | N/A |
(operation) | `/$[name]`, `/[type]/$[name]` or `/[type]/[id]/$[name]` | `POST` | R | Parameters | N/A | N/A |
`GET` | N/A | N/A | N/A | N/A | ||
`POST` | `application/x-www-form-urlencoded` | form data | N/A | N/A |
Notas:
La aplicación específica de cada parametro, para cada una de las operaciones, dependen de cada recurso, en en los cuales el estándar especifica cuales se encuentran definidos para cada operción.
Interacción | Respuesta | |||||
---|---|---|---|---|---|---|
Content-Type | Body | Location | Versionado | Status Codes | ||
`read` | R | R: Resource | N/A | R: `ETag`, `Last-Modified` | `200`, `404`, `410` | |
`vread` | R | R: Resource | N/A | R: `ETag`, `Last-Modified` | `200`, `404` | |
`update` | R if body | O: Resource (Prefer) | N/A | R: `ETag`, `Last-Modified` | `200`, `201`, `400`, `404`, `405`, `409`, `412`, `422` | |
`patch` | R if body | O: Resource (Prefer) | N/A | R: `ETag`, `Last-Modified` | `200`, `201`, `400`, `404`, `405`, `409`, `412`, `422` | |
`delete` | R if body | O: OperationOutcome | N/A | N/A | `200`, `202`, `204`, `404`, `405`, `409`, `412` | |
`create` | R if body | O : Resource (Prefer) | R | R: `ETag`, `Last-Modified` | `201`, `400`, `404`, `405`, `422` | |
`search` | R | R: Bundle | N/A | N/A | `200`, `401`? | |
`search-all` | R | R: Bundle | N/A | N/A | `200`, `401`? | |
`capabilities` | R | R: CapabilityStatement | N/A | N/A | `200`, `404` | |
`transaction` | R | R: Bundle | N/A | N/A | `200`, `400`, `404`, `405`, `409`, `412`, `422` | |
`history` | R | R: Bundle | N/A | N/A | `200` | |
`history-type` | R | R: Bundle | N/A | N/A | `200` | |
`history-all` | R | R: Bundle | N/A | N/A | `200` | |
(operation) | R | R: Parameters/Resource | N/A | N/A | `200` |
Nota: Esta Tabla lista los códigos de estado, pero otros mas pueden ser descrito por la especificación de HTTP. Códigos adicionales son comunmente errores de servidor y de protocolos de autentificación.
El listado de recursos se define en:
[sitio de recursos de FHIR] (https://hl7.org/FHIR/resourcelist.html)
Los Métodos y los parámetros para la consulta de recursos se describen a continuación y se basan en la busqueda sobre recurso Paciente:
En este caso los servidores DEBEN soportar buscar un recurso Patient usando el parametro de búsqueda **[_id
]:
GET [base]/Patient[id]
Ejemplos
Lo anterior es aplicable para un recurso ya creado el cual se alamacena con una identificación generada en ese momento
Los servidores DEBEN soportar buscar un recurso Patient por un identificador como el numero RUN de la Cédula de Identidad Nacional, utilizando el parámetro de búsqueda **[identifier
]:
GET [base]/Patient?identifier={system|}[code]
Ejemplo:
GET [base]/Patient?identifier=http://minsal.cl/API/Paciente | |99999999 |
Ejemplos de búsquedas por otros parámetros
Ejemplo:
POST [base]/Patient En el Body, un recurso paciente compatible con el/los perfiles definidos core definido en el clcore (para este caso sería el perfil Paciente-Cl)
Definición de Medicamentos: Se utiliza la Terminología de Farmacos Chilena (TFC), expuesta por medio de un servicio de terminolgía Local o desde MINSAL
Profesionales de la Salud: desplegados a travez de la Super Intendencia y el sistema Midas, este registro se expone por medio del recurso FHIR Practitioner, y la especialidad por medio dek recurso PractitionerRole.
Establecimientos de Salud: utiliza su identificación por medio de código DEIS, y su registro se expone a traves de los recursos FHIR Location y Organization, según corresponda.
Farmacias: utiliza el registro de farmacias Farmanet y se expone como como los recursos FHIR Location y Organization.
Pacientes: Se identifican por medio de su número identificador que pude ser cualquier tipo de documento especificado en las tablas de HL7 V3 relcionados con identificadores de personas.
Tablas Maestras específicas: se incluyen las de comunas, provincias y regiones, entre otras pertenecientes a la normativa Nacional que son expuestas en la GI y que deben ser en muchos casos levantadas a nivel local