API REST Minsal para informe y seguimiento de muestras PCR para SARS-Cov-2

Como sabemos todos quienes trabajamos en establecimientos donde se toman o procesan muestras para exámenes de SARS-CoV-2, el Ministerio de Salud de Chile solicita el envío diario de información relacionada con dichas muestras, lo que resulta absolutamente necesario para poder llevar las estadísticas nacionales y el seguimiento y trazabilidad de los pacientes a quienes se les ha tomado muestras para detección de Coronavirus, particularmente por la técnica PCR. El envío de esta información se realiza por medio de dos archivos Excel, generados y enviados diariamente, a direcciones de correo del Minsal; si bien es posible automatizar algo este proceso, el envío de archivos por correo electrónico presenta importantes dificultades para contar con un proceso realmente automático de recolección y envío de la información.

También esto hace que no sea posible separar realmente, para propósitos de seguimiento, los eventos de toma de la muestra, recepción de la misma, e informe del resultado final: bajo el esquema actual, todas las muestras se envían únicamente cuando ya cuentan con un resultado final informado, en circunstancias de que es de interés epidemiológico el saber también del hecho mismo de que una muestra ha sido tomada. Y finalmente, en muchos casos, la construcción de estos archivos en Excel implica el asignar recursos humanos de laboratorio a dicha tarea, restando a esas personas de realizar su valiosa labor propia de los procesos de laboratorio en cuanto se encuentran abocados a la elaboración de estos informes diarios.

Por lo anterior, el Minsal se encuentra impulsando una iniciativa sumamente valiosa y que sin duda ayudará a la real automatización informática de este proceso: la construcción de APIs REST para recibir la información relativa al ciclo de vida de las muestras de PCR para Coronavirus directamente desde los sistemas informáticos de laboratorio de las diferentes instituciones. Esta aproximación tiene ventajas indiscutibles: representa una forma estandarizada de comunicar los diferentes hitos por los que pasan estas muestras (básicamente, creación o “toma” de la muestra; recepción por parte del laboratorio que la procesa; e informe de resultados de la misma). Pero, al mismo tiempo, presenta algunos desafíos para lograr la implementación de la conexión a dichas APIs.

La documentación de las APIs en cuestión se puede encontrar aquí. El Minsal ha estado entrando en contacto con las diferentes instituciones de salud que intervienen en el proceso de toma de muestras, con el propósito de ir sumando actores que puedan empezar a utilizar estas APIs. Nosotros en Clínica Alemana hemos estado en contacto con el Minsal para integrarnos de esta manera, con éxito, y quisiéramos poner a disposición algunos recursos de ayuda para que otras que quisieran hacer lo mismo no tengan que partir de cero.

Estamos trabajando en una implementación de referencia de conectividad a estas APIs; esta implementación, escrita en Python y distribuida bajo la licencia libre Apache 2.0, está disponible en este repositorio en GitHub. Por favor tener en cuenta que esto es un trabajo en progreso, y que irá cambiando a medida que avanzamos con la implementación. Básicamente, el repositorio contiene un programa de prueba, de línea de comando, para probar los diferentes “endpoints” de la API, y lo más importante, contiene clases (todos los archivos terminados en _class.py) que “encapsulan” o hacen una abstracción de cada uno de los endpoints a utilizar. El programa de prueba (api-covid-minsal.py) muestra cómo invocar cada uno de los endpoints.

Aspectos importantes a tener en cuenta para empezar a utilizar los servicios del Minsal:

  1. Para empezar a trabajar, es necesario contar con un “usuario institucional” para acceder a la plataforma web de pruebas del sistema de seguimiento y trazabilidad de muestras. Dicha plataforma web (el entorno de pruebas, la URL es distinta para producción) se puede acceder desde https://tomademuestras.openagora.org/ . Este usuario institucional es otorgado por el mismo Minsal a cada institución, por lo que el representante de cada laboratorio debe contactar al nivel central para la obtención de estas credenciales (hace algunas semanas, el Minsal solicitó un “contacto TI” de cada institución para estos efectos).

  2. Una vez que se tienen las credenciales, es posible ingresar a la plataforma web. En ella, tendremos que llevar a cabo una tarea sumamente importante: es necesario generar una clave de acceso (ACCESS KEY) que será nuestra identificación para el uso de la API REST. Para esto, debemos ir al nombre de nuestra institución, en la parte superior de la página, y luego, en la ventana modal que se abre, presionar el botón “Crear clave de acceso para Web Service”. Una vez hecho lo anterior, se mostrará en pantalla una cadena de texto con nuestra ACCESS KEY. Debemos copiar este texto para su uso posterior en los servicios Web expuestos por la API. Los pasos necesarios se muestran en la siguiente captura:

  1. Con lo anterior, ya tenemos uno de los aspectos necesarios para empezar a consumir los servicios. Sin embargo, para poder empezar a hacer pruebas, debemos realizar otra tarea: debemos endosar al menos un profesional de salud (no médico, según entiendo) como responsable de la toma de muestras para nuestro establecimiento. Lo anterior se realiza de la siguiente manera: en el mismo portal web, debemos cerrar la sesión institucional, y hacer login con las credenciales de una enfermera, por ejemplo, de nuestro establecimiento. Estas credenciales son el RUT, sin puntos, sin guión y sin dígito verificador como nombre de usuario; y como contraseña, el número de registro de ese mismo profesional en la Superintendencia de Salud (estos datos se pueden consultar en el Registro Nacional de Prestadores Individuales de Salud). Al ingresar por primera vez, el sistema solicitará cambiar la contraseña para este profesional; la podemos cambiar a una contraseña personal cualquiera.
    Para “endosar” al profesional, una vez hecho lo anterior, debemos hacer clic en la pestaña “Mis establecimientos”, en la parte superior. Se desplegará una pantalla como la que mostramos en la siguiente captura de pantalla; en ella, debemos hacer clic en la fila en blanco del listado central (estará en blanco al principio, se señala con el marcador “2” en la captura de pantalla); al hacerlo, aparecerá un buscador de establecimientos de salud. En él debemos ubicar el establecimiento donde se toma la muestra, que puede o no corresponder también al laboratorio donde se procesa la muestra. Elegimos el establecimiento, nos aseguramos que quede registrado correctamente en la página, y estamos listos para seguir.

  1. Con lo anterior, ¡estamos listos para empezar a probar! Podemos hacer una primera prueba con nuestro cliente REST favorito, como Postman, Insomnia (y, para los realmente hardcore, hasta con curl - los ejemplos en la documentación oficial están hechos con curl). El endpoint para crear una muestra, en entorno de pruebas, está en https://tomademuestras.api.openagora.org/crearMuestras . Agregamos nuestra ACCESSKEY obtenida previamente en el header, de esta manera:

Y luego, podemos usar el cuerpo JSON de prueba en al documentación. Importante a tener en cuenta:

a) se debe usar el RUT del profesional “endosado” en el campo “rut_responsable”, esta vez sin puntos, con guión y con DV, ejemplo: “12345678-9”;
b) Se debe usar un RUT de un médico acreditado en la Superintendencia de Salud en el campo “rut_medico”, en el mismo formato anterior. OJO, no es necesario “endosar” al médico! Este campo representa al médico que solicitó el examen.
c) Los campos “id_laboratorio” y “cod_deis” corresponden a los códigos DEIS que identifican tanto al laboratorio como al establecimiento donde se toma la muestra, respectivamente. En algunos casos, de instituciones que tienen su propio laboratorio, este código puede ser el mismo para ambos.
d) El resto de los campos son más o menos autoexplicativos, y los datos aceptados para cada uno se encuentran descritos en la documentación, en el apartado “schema” de cada endpoint. El código de la comuna también es el código DEIS, según lo indicado en la norma 820 de Estándares de Información del Minsal.

Si tenemos todo OK, deberíamos poder crear una muestra sin problemas:

El servicio web nos devuelve un objeto JSON en que nos confirma el identificador del Minsal para esta muestra, junto con el identificador de nuestro propio sistema de laboratorio para la misma (que le pasamos en el JSON anterior, cuando llamamos al servicio).

Hay varios endpoints que conforman esta API, de los que los más importantes son /crearMuestras (creación inicial de la muestra), /recepcionarMuestra (que indica que la muestra tomada ha sido recepcionada por el laboratorio), y /entregaResultado (que informa el resultado final de una muestra). Es muy importante tener claro que los llamados para recepcionar y para informar deben referenciar el ID que Minsal le asigna a la muestra, que no será igual al identificador interno propio que nosotros tengamos.

Les dejo en el repositorio vinculado arriba (que, insisto, es un trabajo en progreso) la implementación de varias clases que permiten gestionar el ciclo de vida de nuestras muestras, así como también consultar datos de muestras que ya hemos enviado. La idea es que podamos, en este mismo hilo de discusión, ir interactuando para, entre todos, lograr dar buenos insumos para que esta iniciativa, muy necesaria, tenga el mejor de los éxitos. Discutamos dudas, experiencias, código eventualmente, etc. que creamos que pueda ayudar a que otros se suban al tren ya corriendo sin tanto problema.


DESCARGAS

  1. Maestro de variables del sistema - actualizado 27-07-2020
  2. Si necesitas el código DEIS del establecimiento puedes buscarlo en https://quehayensalud.cl
  3. Instructivo de uso de la Plataforma Toma de Muestras (actualizado 13-07-2020)
  4. Proceso de toma de muestra (laboratorio)
  5. Proceso de toma de muestra (profesional)
3 Me gusta

Que buen aporte Jaime! Muchas gracias. :smile:

1 me gusta

Excelente aporte. Me gusta el desarrollo de APIs y el tema no podría ser más relevante así que voy a darle un vistazo!

Respecto de la API en sí, me parece que no cumple con los requisitos para decir que es una API Rest ya que no sigue el patrón Rest en cuanto a uso de verbos HTTP y URLs. Creo que si fuera Rest podría ser más fácil de entender y utilizar por parte de muchos desarrolladores que ya están (estamos) acostumbrados a la arquitectura Rest.

Saludos y felicitaciones por el trabajo realizado!

1 me gusta

Pienso que tienes razón en esto, Fernando; efectivamente, la API en cuestión no sería completamente “RESTful”, de acuerdo al modelo de madurez de Richardson para APIs REST. Dicho lo anterior, para el caso de uso en cuestión… funciona. Desconozco las limitaciones que pueden haber moldeado las decisiones de diseño para este conjunto de endpoints que se están presentando hoy, pero efectivamente en su estado actual pueden ayudar para la problemática que se tiene en este momento de manera razonable. Sin perjuicio de que se puede (y se debiera) siempre, en lo posible, apuntar al uso de las mejores prácticas técnicas al contemplar este tipo de desarrollos.

1 me gusta

Hola Jaime, sin duda que funciona. Mi comentario era sólo eso, un comentario. Lo importante, como dices tú, es el aporte que puede significar en la problemática actual.

¡Mucho éxito!

1 me gusta

Gracias Fernando, y así se recibió tu comentario, precisamente como un aporte :slight_smile: La idea para esta discusión es que se pueda conversar abiertamente acerca de nuestras observaciones, aprensiones, dudas, etc. acerca de estas APIs, y muy especialmente, poder prestar apoyo a aquellos que quieran implementar esta integración.

Estoy de acuerdo con tu observación, por lo demás. Es llamativo, por ejemplo, que no se usen los verbos que harían realmente “RESTful” esta implementación: los endpoints que recuperan un dato (/datosMuestraID, /datosMuestraRUT, /datosMuestraFECHA) deberían técnicamente consumirse con GET, pero todos usan POST. Eso entre otras cosas. Pero también entendemos que esto es un proceso en evolución aún, por lo que puede ser que sigamos viendo cambios hasta su puesta en producción de manera más amplia.

A todo esto, ¡bienvenido al Foro! :wink:

Hola Jaime,
nosotros podemos colaborar con las pruebas para la aplicación y los diferentes cambios que realicen sobre ella.
Participamos del proyecto Covid que hizo Agesic en Uruguay junto con otras empresas, creo que sería un buen aporte desde Abstracta Chile.
Saludos y me comentas.

1 me gusta

Desde esta semana, estamos ya completamente conectados en Clínica Alemana! Hemos estado monitoreando el proceso, y corre muy bien. Ya hemos cargado con éxito los resultados de más de 800 muestras.

El programa que tiene la lógica para conectarse a nuestra base de datos del sistema de laboratorio de la Clínica no es público, por supuesto, pero utiliza las mismas clases disponibles en el repositorio público del posteo original para la validación de datos y llamado a los endpoints de la API Minsal. Técnicamente hablando, nuestros conectores no van directo a la base de datos del LIS, sino que tenemos un proceso ETL que va poblando una base de datos de “staging”, de donde este conector obtiene la información y la envía a la API.

El sitio de producción está en https://tomademuestras.minsal.cl para acceder por medio de la interfaz web; el dominio para la API de producción está en https://tomademuestras.api.openagora.cl . Las rutas para los endpoints son exactamente los mismos que para el sitio de pruebas.

Para acceder a producción, deberán loguearse primero en el sitio web para generar una API key para este entorno (no es la misma que para el entorno de pruebas). De la misma manera, deberán hacer el endosamiento de profesional responsable en el entorno de producción. Para acceder al sitio web en producción, las credenciales son las mismas credenciales iniciales que recibieron para el sitio de pruebas/preproducción.

¡Si se van conectando o avanzando en las pruebas, compartan sus experiencias! De la misma manera, si en algo podemos ayudar a quienes quieran llevar adelante su integración, no duden en consultar acá.

mucho ánimo y espero que siga adelante bien

1 me gusta

Buenas Tardes, agradezco mucho el aporte. En estos momentos, en el holding Banmedica estamos trabajando en el consumo de la API REST y en este contexto tengo varias Dudas.

  1. Seguí los pasos para obtener el accessKey pero no me sale la opción.
  2. Uno de los campos del WS de creación de muestras es Paciente_tipodoc , el cual puede contener los valores RUN o PASAPORTE. La pregunta es cuando el pacientes es extranjero, corresponde PASAPORTE, cual es el campo que se debe utilizar para guardar el Número del documento del pasaporte.
  3. No tengo claridad cuales datos no son obligatorios.
  4. Mirando el código fuente compartido, veo campos que no están declarados en https://tomademuestras.apidocs.openagora.org/#/Laboratorios/post_crearMuestras y que por otra parte me aclararan las dudas del punto 2 y en este contexto mi pregunta es ¿cambio la API?
  5. En los campos que son estructurados, significa que a la API se debe pasar un código y no la descripción. Como ejemplo el Sexo, es campo Entero, por lo tanto de debe pasar 1 cuando es Masculino y así con el resto de los campos estructura?
  6. Respecto la previsión, son solo esas las opciones?
  7. Lo descrito en el codigo fuente difiere respecto https://tomademuestras.apidocs.openagora.org/#/Laboratorios/post_crearMuestras. Mi pregunta en este punto es: Esto es lo definitivo que el Minsal tiene en Producción? Lo pregunto, porque lo que está en https://tomademuestras.apidocs.openagora.org/#/Laboratorios/post_crearMuestras, como ambiente de pruebas, no está actualizado.
  8. Respecto el envío de Resultados, es obligatorio el envío de PDF
  9. Respecto el envío de resultado, es método de la API ¿es una lista de resultados?

Muchas gracias por su ayuda.

{
“codigo_muestra_cliente”: (str),
“id_laboratorio”: (str) (parece referirse al código DEIS),
“rut_responsable”: (str) (formato: sin puntos, con guión y con DV),
“cod_deis”: (int),
“rut_medico”: (str) (formato: sin puntos, con guión y con DV),
“paciente_run”: (int) (sin puntos, guión ni DV); sólo si tipo de documento es RUN,
“paciente_dv”: (int) (sólo el DV); sólo si tipo de documento es RUN
“paciente_pasaporte”: (str); sólo si tipo de documento es Pasaporte
“paciente_ext_paisorigen”: (int) (código DEIS); sólo si tipo de documento es Pasaporte
“paciente_nombres”: (str),
“paciente_ap_pat”: (str),
“paciente_ap_mat”: (str),
“paciente_fecha_nac”: (str) (dd-mm-aaaa),
“paciente_comuna”: (int) (código DEIS),
“paciente_direccion”: (str),
“paciente_telefono”: (str),
“paciente_tipodoc”: (int) (ESTRUCTURADO; Opciones: 1=“RUN”, 2=“PASAPORTE”, 3=“SIN DOCUMENTACION”),
“paciente_sexo”: (int) (ESTRUCTURADO; Opciones: 1=“M”, 2=“F”, 3=“Intersex”, 4=“Desconocido”),
“paciente_prevision”: (int) (ESTRUCTURADO; Opciones: 1=“FONASA”, 2=“ISAPRE”, 3=“CAPREDENA”, 4=“SISAN”, 5=“SISAE”, 6=“DIPRECA”, 7=“SIN PREVISIÓN”),
“fecha_muestra”: (str) (dd-mm-aaaa),
“tecnica_muestra”: (int) (ESTRUCTURADO; Opciones: 1=“RT-PCR”, 2=“Test Pack”),
“tipo_muestra”: (int) (ESTRUCTURADO; Opciones: 1=“Lavado Broncoalveolar”, 2=“Esputo”, 3=“Aspirado Traqueal”, 4=“Aspirado Nasofaríngeo”, 5=“Tórulas Nasofaríngeas”, 6=“Muestra sanguínea”, 7=“Tejido pulmonar”, 8=“Saliva”, 9=“Otro”)
}

1 me gusta

Estimado Cristian, en primer lugar, bienvenido al foro!

Abordo las consultas. Recordar que, por supuesto, la información “oficial” la tiene el Minsal, nosotros podemos ir ayudando de acuerdo a nuestra percepción y nivel de avance en esta implementación, pero también tenemos la visión desde el lado de los “prestadores”.

Vamos a las consultas:

  1. La creación de la ACCESS KEY se hace desde la interfaz web, accediendo con las credenciales “institucionales” del prestador (no con las claves de un usuario personal). Ahí, se debe hacer clic en el nombre de la institución (arriba a la derecha), y luego en el modal que se despliega, el botón “Crear clave de acceso para Web Service”:

  2. Efectivamente, esto no es claro de la documentación. Si el campo paciente_tipodoc es RUN, entonces son obligatorios los campos paciente_run y paciente_dv. Por el contrario, si el campo paciente_tipodoc es PASAPORTE, entonces los campos anteriores no aplican y sí se debe pasar obligatoriamente los campos paciente_pasaporte (string) y paciente_ext_paisorigen (int, código DEIS de país).

  3. No es claro de la documentación qué campos son obligatorios… Pero, salvo lo indicado arriba, me da la impresión que para crear muestras, todos lo son.

  4. Hasta donde sabemos, no ha cambiado la interfaz de la API desde la última publicación. Puede ser que quieras obtener de nuevo el código desde el repositorio, he ido incorporando algunas mejoras y correcciones al mismo; por ejemplo, ahora valida y contempla el caso de uso de RUT vs. Pasaporte.

  5. Depende de cada campo. Las clases que yo subí tratan de “encapsular” y estandarizar el consumo de las APIs, y así, por ejemplo, para construir el objeto para crear muestras, te pide un entero para el sexo, que luego la clase misma “traduce” al string que espera la API misma del Minsal. Lo hice de esa manera porque me es más fácil si, por ejemplo, a futuro cambiaran los strings de opciones para cada campo, pero por supuesto se podría implementar de otra manera. Los diccionarios para cada campo están en los comentarios de mi clase en el repo, y en la documentación del Minsal (en los “schemas” para cada endpoint).

  6. Hasta donde sabemos, sí: “paciente_prevision”: (int) (ESTRUCTURADO; Opciones: 1=“FONASA”, 2=“ISAPRE”, 3=“CAPREDENA”, 4=“SISAN”, 5=“SISAE”, 6=“DIPRECA”, 7=“SIN PREVISIÓN”)

  7. En este momento, la clase para crearMuestras debiera estar completamente ajustada con la API misma (la estoy usando en producción sin problemas). Tiene abstracciones, como indicaba en el punto 5 (por ejemplo, para las variables estructuradas, la clase pide que se le pase un entero que después es “traducido” a un string según corresponda), pero está funcionando. Podría eso sí haber divergencias con algunas partes que no estén tan bien documentadas, como el caso del comportamiento de la API según se tenga RUT o Pasaporte, por ejemplo). Pero el código mismo, así como está, me está permitiendo alimentar sistemáticamente la API con data real nuestra.

Espero que esto haya sido de ayuda, y de todas maneras quedo atento a cualquier nueva solicitud! Nuevamente, bienvenido al foro!! :slight_smile:

muchas gracias, Jaime.
Aquí te dejo otras 2 preguntas

  1. Respecto el envío de Resultados, es obligatorio el envío un archivo adjunto (PDF)
  2. Respecto el envío de resultado, el método de la API ¿es una lista de resultados?

Hola Cristian! Van mis respuestas:

  1. Actualmente, la API sí exige obligatoriamente adjuntar un archivo… Pero no necesariamente debe ser un PDF. Nosotros expusimos al Minsal que no generamos y persistimos un PDF individual para cada resultado de Covid, por lo que acordamos que podíamos enviar otro adjunto para satisfacer el requerimiento de la API por el momento. Entonces, lo que estoy haciendo, es que adjunto un archivo de texto, que contiene la descripción textual del resultado (Positivo, Negativo, Indeterminado)… Y nada más. De hecho ese mismo comportamiento es lo que implementa mi clase entregaResultado actualmente en el repo.

  2. No, me da la impresión que la API espera un único resultado de muestra por llamado a la API de entregaResultado:

En el valor de ejemplo en la documentación, aparece un único objeto, no un array.

Muchas gracias, Jaime.-

Buenos días, Jaime.
el campo “paciente_dv”: (int) (sólo el DV); sólo si tipo de documento es RUN
¿No debería un STR, para que acepte los DV igual a K ?

1 me gusta

Oh rayos. Buen “catch”. Efectivamente, en los comentarios del código, lo puse incorrectamente como (int):


"paciente_dv": (int) (sólo el DV); sólo si tipo de documento es RUN

Cuando en realidad es un str. El validador, en la misma clase, lo tiene bien:


        # Validaciones dependientes del tipo de documento
        if datos_muestra['paciente_tipodoc'] == 1:
            self.validacion += self.valida_campo(datos_muestra, "paciente_run", int)
            self.validacion += self.valida_campo(datos_muestra, "paciente_dv", str, patron="^[0-9kK]$")

¡Muchas gracias por la observación! En el fondo, el código mismo estaba bien, pero la documentación del mismo no. Estoy empujando el fix ahora al repo.

muchas gracias. Jaime. Saludos.

Jaime, disculpa mis multiples consultas.
Respecto el campo “rut_responsable”: (str) (formato: sin puntos, con guión y con DV), dices que es el rut del profesional.
¿Es el rut medico del que solicitó el examen o puede ser Rut del Director técnico del Laboratorio?. Lo pregunto, ya que existe otro campo para el rut del médico.
muchas gracias.

¡No hay problema Cristian! La idea es precisamente poder aportar entre todos resolviendo estas dudas operativas.

Efectivamente, se requieren dos RUT de profesionales para crear la muestra. Uno de ellos, rut_responsable, corresponde a la persona responsable de la creación de la muestra en el sistema. Típicamente será el profesional de la salud que tomó la muestra; para los usuarios que no utilicen las APIs y accedan a la plataforma web para crear ahí las muestras, correspondería al usuario clínico que se loguee para hacer en el sistema dicha acción. Este RUT debe pertenecer a la persona “endosada” al centro asistencial, como se indica en la publicación original de este hilo.

El campo rut_medico corresponde al médico que solicitó la realización del examen al paciente. DEBE ser un RUT de un médico inscrito en la Superintendencia de Salud, en el registro de prestadores individuales.

Ambos campos, aparentemente, están más pensados en el ingreso manual de datos, por digitación, que en la carga por APIs automatizadas. Nosotros consultamos estas mismas dudas en nuestras conversaciones con el Minsal, y acordamos que, para el envío por API, se acepta que sean los mismos RUT para ambos campos, para todas las muestras; estamos enviando el RUT de la enfermera jefe del laboratorio como rut_responsable, y el RUT de la médico jefe del laboratorio como rut_medico.

Muchas gracias, gracias. Jaime.
Estuve realizando una prueba de concepto, con estos parámetros. sin embargo me devuelve error.
Asumo que debo pedir un Rut de Responsable, valido para esta clínica.

{
“error”: " El establecimiento establecido no es gestionado por este usuario\n"
}

[
{
“codigo_muestra_cliente”: “123456789123456789”,
“id_laboratorio”: 509,
“rut_responsable”: “8329235-0”,
“cod_deis”: 109201,
“rut_medico”: “16239873-3”,
“paciente_run”: [rut],
“paciente_dv”: [digito verificador],
“paciente_nombres”: “CRISTIAN”,
“paciente_ap_pat”: “SALAS”,
“paciente_ap_mat”: “CHANDIA”,
“paciente_fecha_nac”: “17-12-1973”,
“paciente_comuna”: 13201,
“paciente_direccion”: “[dirección]”,
“paciente_telefono”: “[teléfono]”,
“paciente_tipodoc”: 1,
“paciente_sexo”: 1,
“paciente_prevision”: 1,
“fecha_muestra”: “04-08-2020”,
“tecnica_muestra”: 1,
“tipo_muestra”: 1
}
]