El presente documento explica cómo consumir el Web Service de suap (de ahora en más WS). Para ello es importante exponer algunos conceptos antes de proseguir ya que la problemática que se pretende resolver no es simple.

El objetivo es lidiar con la variabilidad que presentan los diferentes convenios a lo largo del tiempo y poder incorporar los convenios por venir sin la necesidad de que se modifique la presente especificación y por consiguiente las implementaciones de los consumidores.

A partir de la puesta en marcha del WS podemos decir que suap pasa a tener innumerables frontends. Uno es el sitio WEB habitual y el otro es la interfaz que implemente cada consumidor. El frontend de suap es clave para poder acompañar las decisiones que desean ejecutar las Comisiones Directivas de los colegios/instituciones que utilizan los servicios de suap. Es por esto que una mala implementación del WS podría disminuir las posibilidades de ejecución de decisiones sobre los convenios. Para lidiar con este problema hemos decidido que el WS además de ser una especificación de intercambio de información entre sistemas también sea una política de cómo proceder en determinadas situaciones muy bien definidas y cuáles son las responsabilidades tanto de suap como del consumidor.

De este modo suap entrega una especificación completa que permite afrontar la totalidad del problema y a la vez que se desliga de cualquier responsabilidad frente a falencias de operación producidas por implementaciones incompletas por parte de los consumidores.

Explicaremos brevemente como hacerse de las credenciales y definir la dirección (URL) del WS usando la interfaz web de suap. Si estás leyendo este manual sin contar con usuarios de prueba podés requerirlo a [email protected].

La URL de suap está conformada por las siglas de la instalación, que siempre coinciden con la abreviatura de la Institución de profesionales. A modo de ejemplo damos siglas reales para algunas de ellas:

• CBPRN. Corresponde al Colegio Bioquímico de la Provincia de Río Negro
• CBN. Corresponde al Colegio de Bioquímicos de Neuquén
• CBLP. Corresponde al Colegio de Bioquímicos de la Pampa
• ABNECH. Corresponde a Asociación de Bioquímicos del Nor Este de Chubut.
• CMN. Corresponde al Colegio Medico de Neuquén.
• CKN. Corresponde al Circulo de Kinesiólogos de Neuquén
• CPN. Corresponde al Circulo de Psicólogs de Neuquén
• CBPM. Corresponde al Colegio de Bioquimicos de Puerto Madryn
• ABCZSCH. Corresponde a la Asociación Bioquímica Clinica Zona Sur Chubut
• CIBOCH. Corresponde al Circulo Bioquimico Oeste de Chubut.

Quedando así la URL para el acceso WEB (página) de cada instalación del siguiente modo:

• cbprn.suap.com.ar o www.cbprn.suap.com.ar
• cbn.suap.com.ar o www.cbn.suap.com.ar
• cblp.suap.com.ar o www.cblp.suap.com.ar
• abnech.suap.com.ar o www.abnech.suap.com.ar
• cmn.suap.com.ar o www.cmn.suap.com.ar
• ckn.suap.com

Para conformar la uri del WS de suap debe seguirse la siguiente regla:

• Definir las siglas de la instalación donde opera el prestador. Llamaremos INST a estas siglas, en el ejemplo serían (cbprn, abnech, cbn, cblp o cmn)
• conformar la url del siguiente modo: https://ws.INST.suap.com.ar/procesador/doV2/

En los ejemplos reales a la fecha los accesos a cada ws serían entonces:

• CBPRN → https://ws.cbprn.suap.com.ar/procesador/doV2/
• CBN → https://ws.cbn.suap.com.ar/procesador/doV2/
• CBLP → https://ws.cblp.suap.com.ar/procesador/doV2/
• ABNECH → https://ws.abnech.suap.com.ar/procesador/doV2/
• CMN → https://ws.cmn.suap.com.ar/procesador/doV2/

En una primera etapa el desarrollador cuenta con un entorno de pruebas. El mismo tiene las siguientes direcciones:

• www.test.suap.com.ar es la url base
• www.test.suap.com.ar/prestador.php es la url del prestador, para realizar gestiones web
• https://ws.test.suap.com.ar/procesador/doV2 es la dirección del WS.

Para operar se debe realizar todo como en cualquier versión de producción.

En el caso de utilizar el WS de suap es necesario generar y obtener las credenciales. Dichas credenciales están ligadas a un usuario real de suap. Se puede crear un usuario específico para todo el laboratorio o a un usuario existente gestionarle una credencial para el WS. De ahora en mas a dicha credencial la llamaremos TOKEN.

Pasos para conseguir un TOKEN para WS de suap:

1. En la aplicación del prestador ir a la opción integrantes del laboratorio.
2. En la lista de usuarios que tienen permitida tareas en el laboratorio se podrá observar una serie de columnas nuevas que se relacionan con el ws y los TOKENs de acceso. La lista completa de columnas para cada usuario es, entonces:

1. Nro. Simplemente el número de usuario. Identificador único dentro de suap
2. Usuario. Es el nombre del usuario y acceso al perfil del mismo.
3. Ultimo acceso. La fecha y hora de la ultima vez que se logeó en suap web.
4. Un botón para agregar un nuevo usuario. Debajo el acceso al registro de actividad de cada usuario
5. Acceso a un chat con el usuarios
6. Botón para inactivar o activar el usuario
7. Botón para blanquearle la contraseña generando una nueva
8. Botón para crear o renovar el TOKEN de WS
9. Token de WS si es que lo tiene mas un botón para copiarlo al portapapeles

El TOKEN consta de dos cadenas de caracteres separadas por un carácter : (dos puntos). La porción izquierda es el usuario y la porción derecha es el password. Por ejemplo, si el TOKEN es:

izquierda_AAABHJKiywz:derecha_ccDDFfFGG

El TOKEN se decompone en:

• USUARIO: izquierda_AAABHJKiywz
• PASSWORD: derecha_ccDDFfFGG

Una vez obtenido el TOKEN precionando la opción “crear token” se puede copiar al portapapeles usando el botón a tal fin. De este modo ya puede transportarlo a su sistema.

El o los usuarios a los que se les genera un TOKEN de ws deben, además, tener asignado el permiso para usar el WS. Dicho permiso se llama webService y se asigna en la lista de permisos del usuario.

En este punto usted ya debe haber podido generar el token para el usuario dentro de la web de suap y cuenta con una url de prueba para comenzar su implementación.

En el WS cada request que realice debe contener en el header tipo de autenticación basic y el usuario y contraseña generados para el WS.

El Web Service de suap está basado en REST y el estandar adoptado para flujo de datos es JSON.

Es importante entender que el WS es, en el fondo, una especificación para crear y obtener recursos. Un recurso se identifica con una URI (uniform resource identifier).

La totalidad de los recursos del WS están envueltos en una estructura JSON. Es decir, una imagen o un pdf primero es traducido a base64 y es devuelto como valor de una clave en la estructura JSON del response.

La creación de los recursos se realiza mediante un request con el método POST.

La obtención de recursos se hace mediante un request con el método GET a la URI. En los capítulos siguientes se elaboran detalladamente estos conceptos.

La URI del recurso es la forma de accederlo como ya lo dijimos. Está conformada por la URL BASE o dirección del WS + el nombre del recurso + su token. Supongamos que en la página de suap de testing vemos la orden número 654321. Su token es O654321 (regla para órdenes). La URI para acceder esa orden mediante el WS es entonces:

https://ws.test.suap.com.ar/procesador/doV2/orden/O654321

Los recursos, en su mayoría, contienen atributos. Los nombres de los atributos pueden ser un grupo de palabras. Por ejemplo la fecha de realización de una orden es “FechaRealizacion”. Las palabras que componen el nombre de los atributos van capitalizadas y pegadas sin ningún carácter en general. Eventualmente podrían separarse por un guión bajo.

FALTA DOCUMENTAR

Lo mejor para comenzar es hacer una serie de ejemplos. En este punto usted debería contar con:

• URL de un sitio de test para prestador. www.test.suap.com.ar/prestador.php
• Credenciales para acceder que requirió por mail a [email protected]
• Un token de usuarios que gestionó en el sitio para prestadores de ejemplo
• URI base del WS de test: https://ws.test.suap.com.ar/procesador/doV2

Para proceder con este capítulo es necesario contar con ordenes creadas desde la página web. Puede consultar al personal administrativo del punto de atención que desea conectar a su software de consumo de WS como se realiza esta operación en la web de testing.

Es el método utilizado para obtener un recurso mediante su URI. Para avanzar con el ejemplo en la página de suap puede mirar la lista de ordenes. Verá que las mismas tienen un número. Ese número con el agregado de una O delante es el token de la orden en tanto recurso para el WS. Con eso podremos armar la URI de un recurso orden para hacer un GET y comenzar a analizar el response.

Un response producto de un GET es un Json que contiene las siguientes secciones principales:

• REST. Es el o los recursos en términos REST. Los atributos del recurso base más las URIs de los recursos relacionados. Aquí encontraremos los “links” de los recursos relacionados y nada mas. Consumir la información desde esta sección es mas trabajoso ya que requiere de mayor cantidad de consultas al WS, pero permite resolver cualquier situación no prevista ya que literalmente se puede navegar por toda la información.
• RENDER. Es la misma información de la sección REST pero ya preparada (renderizada) para que el consumidor la disponga sin tener que acceder a los recursos relacionados. El objetivo de esta sección es bajar la taza de uso del WS, facilitando toda la información necesaria para el consumidor en la menor cantidad posible de transacciones.
• STATUS. Sección que indica estados de las transacciones. Por ejemplo los errores en la sección interna ERROR
• VIEW. Es información que debe ser presentada al usuario y una especificación de como se debe requerir información faltante para cumplir con los requisitos mínimos

Para ejemplificar veamos como se obtiene un atributo y un recuros en la sección REST y RENDER. Por caso la fecha de realización como atributo y el afiliado como recurso.

En el fragmento inferior vemos que la fecha de realización es el valor de la fecha, es decir, es un atributo. En cambio el recurso afiliado es una URI. Si hiciermos GET a esa URI obtendríamos toda la infomación del recurso.

El mismo response pero en la sección RENDERpresenta la información mas apropiada para consumir sin realizar mas consultas. Con respecto a los atributos vemos que no hay diferencia, en cambio con los recursos asociados sí. Del afiliado observamos que tenemos información mas completa y útil sin la necesidad de hacer mas requests al WS.

La sección VIEW es una pequeña “vista” o formulario con opciones que debe ser presentada al usuario. El consumidor tiene la libertad de realizar GET para mantener sincronizado su sistema con suap sin la intervención del usuario, pero debe ofrecer al menos una forma de acceder al GET de los recursos procesando la sección VIEW del response.

En el caso del método que nos ocupa el VIEW en la mayoría de los casos contendrá acciones.

FALTA DOCUMENTAR

Otro modo de obtener recursos es mediante la accion search. Se crean mediante el método POST y devuelven como response una lista de recursos que coinciden en los criterios de búsqueda especificados.

Se debe especificar en la URI del POST el “recursoABuscar” + “.” + “search” . Es decir, supongamos que buscamos un afiliado, la URI en testing sería:

En el content debemos especificar los atributos y/o recursos relacionados mas sus atributos separados por puntos “.” y finalmente la operación de comparación. Veamos por ejemplo el caso de buscar todos los afiliados que contienen el nombre “Santiago”:

Si seguimos el ejemplo veremos que nos devuelvo un response que contiene 4 secciones:

• REST. Será una lista de las n primeras URIs de los recursos que satisfacen esta condición.
• STATUS. Información sobre el resultado de la transacción. En el caso de la acción search se incorpora una sección además de ERROR. La sección NOTICE permite saber tres cosas, si queda una página mas, cuantos se muestran por página y que página se está mostrando.
• RENDER. Es la misma información que en REST pero ya procesada para consumir sin la necesidad de recorrer las URIs.
• VIEW

|REQUEST https://ws.test.suap.com.ar/procesador/doV2/afiliado.search
{
“REST”:{
“0”:“https:ws….V2/afiliados/YMABXGMrPMo0iDFs1lVeGSvhLEWwPq”,
- - -
“10”: “https://ws….V2/afiliados/ges37O3Ne007vZyM4OnGIpj0cEzm4N”,
“STATUS”: {
“ERROR”: [],
“NOTICE”: {
“More”: true,
“ActualPage”: 1,
“PageSize”: 100
}
}
,
“RENDER”:{
“0”:{
“NombreCompuesto”: “MUÑOZ SANTIAGO SEGUNDO ”,
“DocNumero”:”
- - -
}
} | En la sección STATUS aparece la clave NOTICE que contiene información del paginado: * More: Es booleano e indica si hay mas páginas (true) o si ya estamos en la útilma página (false) * ActualPage: Es el número de la página actual, la que se pidió con el método POST. La primer página es la 0 * PageSize: Es la cantidad máxima de elementos que se muestra por página. No es la cantidad de elementos que se muestran. Para ver una página diferente a la actual debemos incorporarla a la URI del POST. Por ejemplo “…afiliado.search/1” nos daría la segunda página de resultados de la misma búsqueda. |POST https://ws.test.suap.com.ar/procesador/doV2/search.afiliado/1]]]]]]]]
[ {“NombreCompuesto.contenga”:”Santiago”} ] | El resultado del POST del ejemplo superior será el de la página siguiente.

=== Mantenerse al día. === La obtención de recursos mediante search sirve para actualizar datos de convenios en el LIS. Supongamos un POST al recurso search.obrasSociales con el siguiente content: |https://ws.test.suap.com.ar/procesador/doV2/obraSocial.search]]
{
“Nombre.contenga”:””
} | Tendremos como response la lista de los convenios que están siendo gestionados por suap en este momento. Además esa lista, como siempre, contendrá las URIs de cada uno para poder recorrerlos y obtener información relevante para el sistema del consumidor. Por ejemplo valores de unidades, nomencladores, etc. |
{
“REST”: {
“1”: “https://ws.test.../28EiEf2G0gP49RtFighfflHBZXk1tu]]]]]]”,
“2”: “https://ws.test.../mAJU8wAVBgU4GgLQGhX9JTXUO6wDrX]]]]]]”,
“3”: “https://ws.test.../Gy226GrRazQ8yNjYXawYB7ikv3C6xI]]]]]]”
},
“STATUS”: {
“ERROR”: [],
“pagina”: 1,
“cantidadTotal”: 3,
“cantidadPorPagina”: “10”
},
“RENDER”: {
“1”: {
“Nombre”: “PAMI”,
- - -
},
“2”: {
“Nombre”: “ACA SALUD”,
- - -
},
“3”: {
“Nombre”: “Sancor Salud”,
- - -
}
}
} | ===== ===== ===== Creando recursos. ===== La creación de recursos es mediante el método POST. La dirección a la que hay que realizar el post es como una URI pero sin el token puesto que no lo tendremos. Por ejemplo si deseamos crear una orden para autorizar, la dirección del post sería URI BASE + ordenes. En el entorno de testing nos queda: |https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]] | Un request mediante POST mas un contenido en esa dirección puede terminar en una orden autorizada. En términos generales un POST a una dirección de recurso puede instanciar un recurso en suap. Existe la posibilidad de que no ocurra esto ya que puede haber errores o datos incompletos. | * Política de persistencia. Si la respuesta del POST contiene una sección REST con una clave token y un valor diferente de null, entonces el recurso se persistió. Su URI será exactamente la misma del POST + el token. ==== Contenido (content) del POST ==== En términos formales el contenido del POST es un JSON con los atributos del recurso que el consumidor desea crear. Dicho JSON está estructurado en dos grandes secciones que representan dos políticas diferentes de como se referencia la información dentro de suap. Una sección es REST y la otra sección es SEARCH.

|
Contenido de un POST a un recurso ordenes
https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]
{ “REST”: {…},
“SEARCH”: {…}
} | === Sección REST === En esta sección se indican los atributos con su valor y los recursos relacionados mediante su URI. Por ejemplo, en una orden, la fecha de realización es un atributo cuyo nombre es “FechaRealizacion” que debe contener una fecha en formato: yyyy-mm-dd hh:mm:ss. Un afiliado es un recurso relacionado que debe ser especificado por su URI. Supongamos que deseamos instanciar un recurso orden con: * Fecha de realización 23/06/2018 * Afiliado Marta Laura Corbalán del ejemplo anterior, cuyo recurso tiene como URI
https://ws.test.suap.com.ar/procesador/doV2/afiliados/7C9tIPdWMNTt99Zn1afALxroGVuQMt

Para pedirle al WS que cree el recurso orden con esos datos especificados en la sección REST debemos armar el siguiente JSON: |POST a ordenes (testing)
https://ws.test.suap.com.ar/procesador/do/V1.0/ordenes]]]]]]
{ “REST”:{ “FechaRealizacion”:”2018-06-23 00:00:00”, “afiliados”:
“https://ws.test.suap.com.ar/procesador/doV2/afiliados/7C9tIPdWMNTt99Zn1afALxroGVuQMt]]]]]]”
},
… }} | En general es poco probable que se cuente con la URI de los recursos y mas que nada al principio. Por lo que si el consumidor fuera por este camino tendría que implementar primero una serie de herramientas para poder buscar afiliados para poder incorporarlos en la sección REST, y lo mismo con los prescriptores y así con todos los recursos relacionados a una orden en este ejemplo. Recién entonces podría armar un contenido completo para realizar el POST y obtener finalmente el recurso instanciado en suap. Si bien el WS no impide estas prácticas tampoco la alienta. Es por eso que ofrecemos la sección SEARCH que hace exactamente lo ante dicho pero en una cantidad menor de pasos. === Sección SEARCH === En esta sección se le indica a suap que se van a identificar los recursos mediante busquedas por sus atributos. Es decir, por ejemplo si es el POST a una orden y no tenemos el token del afiliado que deseamos, podemos indicar que se lo busque por su nombre, DNI, o cualquier dato parcial o completo que tengamos del mismo. Suap aplicará una política simple en esta condición, si encuentra un único recurso con esos criterios de búsqueda, entonces lo utilizará, si encuentra mas de uno requerirá que sea seleccionado uno por parte del usuario mediante la sección VIEW del response. Cabe destacar que los atributos deben seguir siendo especificados en la sección REST. A modo de ejemplo un uso de la sección SEARCH del WS identificando al afiliado por su DNI y un conjunto de practicas identificados por sus ultimos 4 digitos del NBU. |
POST a un recurso ordenes
https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]
{
“REST”:{
“FechaRealizacion”:“2019-03-09”,
“FechaPrescripcion”:“2019-03-02”,
“DiagnosticoTexto”:“Texto diagnostico”
},
“SEARCH”:{
“afiliado”:[
{“DocTipo.igual”:“DNI”},
{“DocNumero.igual”:“10044895”}
],
“prestador”:[
{“NombreCompuesto.contenga”:“….”}
],
“prescriptor”:[
{“NombreCompuesto.contenga”:“Abenda”}
],
“items”:[
[{“CodigoConvenio.igual”:“660711”}
],
[{“CodigoConvenio.igual”:“660413”}
]]
}
} | Este ejemplo crea una orden de PAMI, simplemente creando un ejemplo con otro afiliado de otra OS debería generarse otra orden FALTA DOCUMENTAR | ==== Interpretación del VIEW ====

El view es una lista de requerimientos y ofertas que hay que hacerle al usuario. Cada requerimiento u oferta indica exactamente donde debe ir el resultado de lo que el usuario responda.
Un requerimiento es algo que faltó o que es necesario resolver por parte del usuario. Por ejemplo un requerimiento puede ser definir un profesional ya que con la matrícula brindada hay dos o mas opciones posibles. Los requerimientos están siempre presentes como un error en la sub sección ERROR de la sección STATUS.
Una oferta es algo que le puede ser de utilidad al usuario. Por ejemplo un comprobante para imprimir es algo que el usuario puede necesitar o no para terminar un proceso externo a suap y necesario para el colegio. Pero no es algo necesario para instanciar un recurso.
Si se realiza un procesador de la sección VIEW practicamente no haría falta nada mas para instanciar recursos en suap (por ejemplo ordenes), mas allá de que sería quizás torpe y se realizarían muchisimas mas llamadas de las necesarias. Comencemos con un ejemplo considerando que operamos en la instalación de test. |POST a un recurso ordenes
https://ws.test.suap.com.ar/procesador/doV2/orden]]]]]]
{
“REST”: {},
“SEARCH”: {
“afiliado”: [
{
“NombreCompuesto.contenga”: “Juan”
}
]
}
} | Como es esperable es imposible obtener un recurso ordenes con ese content. Por lo que el response del WS contendrá un VIEW requiriendo todo lo que haga falta indicado en ERROR de STATUS cada atributo y recurso faltante. Si no está en {“STATUS”:{“ERROR”:{..}}} entonces no es algo necesario es una simple oferta. |Fracción de response
“REST”: [],
“STATUS”: {
“ERROR”: {
“FechaRealizacion”: {
“CODE”: 10060,
“MESSAGE”: “El atributo es requerido”
}, - - -“VIEW”: {
“FechaRealizacion”: {
“type”: “timestamp”,
“label”: “FechaRealizacion”,
“path”: “REST/FechaRealizacion”
} ,

- - - | Del response tomamos 3 fragmentos mínimos a modo de ejemplo y vemos que: - {“REST”:[]…} Es una lista vacía por lo que token no está definido. Condición de persistencia no se cumple, ya es condición suficiente para procesar el VIEW. - En {“STATUS”:{“ERROR”:{..}}} se nos indica que FechaRealización es un atributo requerido mediante un código para que tome decisiones el consumidor y un mensaje para que tome decisiones el usuario en caso de ser necesario. Por eso es una buena práctica mostrar ese texto. - Por otra parte el {“VIEW”:{“FechaRealizacion”:{..}}} le indica al consumidor como procesar este atributo o recurso. En este caso se indica que:

1. El tipo es fecha, por lo que el consumidor puede ofrecerle un formato apropiado o incluso un widget de calendario. El resultado debe ser si o si en el formato especificado por el WS
2. El resultado de lo que el usuario ingrese debe ser colocado en el JSON de request nuevo en la posición que se indica. Las “/” separan claves. Es decir, en el ejemplo al “REST” debe agregarse una clave “FechaRealizacion” que contiene una clave “value” que vale la fecha que ingrese el usuario.
3. Información de asistencia al usuario como el label del campo para ingresar la fecha. El error que ocacionó que el WS requiera este dato, etc. | === Tipo string y timestamp. === Una propuesta para presentarle al usuario bien podría ser: tipo_string_y_timestamp.png === Tipo list. === En lineas generales este criterio sirve para los tipos texto y fecha. Otro ejemplo interesante es el tipo lista. Siguiendo con el ejemplo podemos ver que hay un atributo contexto en el response de un post vacío a ordenes: |
Fracción de response
“REST”: [],
“STATUS”: {
“ERROR”: {
“afiliado”: [
{
“code”: 10010,
“message”: “Sea mas especifico en la busqueda, se encontraron mas resultados de los permitidos”
},
{
“code”: 10060,
“message”: “El atributo es requerido”
}
], - - -“VIEW”: {
“afiliado”: {
“type”: “list”,
“label”: “Seleccione un afiliado de la lista”,
“path”: “REST/afiliado”,
“options”: {
“lelWBHU685gZOTAWSh3OrO5XAT0XEa”: “GUERRERO JUAN ANTONI|40506285720700|PAMI|”,
“EduJfFqI1BOBgcYL8G4TXEd34MbGBd”: “MINERVINI….
}
},
- - - | Los criterios a aplicar sobre el atributo afiliado son similares a los de FechaRealizacion vistos en el ejemplo anterior, aquí la diferencia es que el input o el entry que se le provee al afiliado es sobre una lista de opciones en las que se detalla en la sección “opciones” que mostrarle al afiliado para que elija y que devolver en la ruta especificada. Siempre se devuelve la clave y se muestra el valor

tipo_list.png Al igual que en el caso de FechaRealizacion quedará en la ruta especificada el valor que seleccione el usuario en este caso. Ya podemos apreciar que es el usuario quien mediante estos mecanismos simples puede ir construyendo el próximo request ya que se van completando las secciones del mismo. === Tipo recurso. === ===== ===== Otro caso interesante para ver con ejemplos es el del tipo recurso. Veamos un ejemplo mas para poder formalizar una política. |
Fracción de response
“REST”: [],
“STATUS”: {
“ERROR”: {
- - -
“afiliados”: {
“CODE”: 10070,
“MESSAGE”: “El recurso es requerido”
}, - - -“VIEW”: {
- - -
“prescriptor”: {
“type”: “resource”,
“label”: ””,
“resource”: {
“MatriculaNacional”: {
“path”: “SEARCH/prescriptor/2/MatriculaNacional.contenga”,
“type”: “string”,
“label”: “Buscar con MatriculaNacional”
},
“NombreCompuesto”: {
“path”: “SEARCH/prescriptor/3/NombreCompuesto.contenga”,
“type”: “string”,
“label”: “Buscar con NombreCompuesto”
}, - - -
},
- - - | El tipo recurso es ni mas ni menos que una serie de atributos que definen un recurso cuando es imposible ofrecerlo en una lista. Por ejemplo, supongamos el ejemplo concreto del response que estamos analizando. El afiliado bien podría ser elegido de una lista, pero sería una lista con miles de opciones. Por lo que al no haber dato alguno y ser un dato necesario para instanciar la orden entonces se ofrece completar datos que buscarán un recurso afiliado adecuado. Si miramos la porción del response de afiliados dentro de VIEW veremos que está como siempre la clave “tipo” y una clave “resource” que a simple vista parece como una sección VIEW mas pequeña!. La realidad es que no parece, es. VIEW es una estructura recursiva.
La primer entidad de VIEW está implícita y es de tipo recurso.
tipo_recurso.png A diferencia de los atributos anteriores (FechaRealizacion y Contexto) acá podemos observar que el destino es dentro de la clave “SEARCH”:{..} en vez de “REST”:{..}. El WS está ofreciendo herramientas de búsqueda. Repasemos como iría quedando conformado el nuevo request que pudimos armar en función de un response al realizar un request vacío. |
Nuevo POST a ws.test.suap.com.ar/procesador/do/V1.0/ordenes
“REST”: {
“FechaRealizacion”:{“value”:”2018-07-02 00:00:00”},
“Contexto”:{“value”:”Ambulatorio”},
},
“SEARCH”: {
“prescriptor”:{
“NombreCompuesto.contenga”:”Juan Perez”,
“DocNumero.contenga”:”123..”,
},
} | Podemos ir observando que el WS nos indicó: * Qué falta. * Cómo requerirlo al usuario. * Cómo enviarlo al WS nuevamente. Es decir, mediante una política sencilla, nos está ayudando a requerirle al usuario la información y a construir el request para enviar nuevamente el POST. === Tipo transpuesta/mucho a muchos. === Este tipo de widget representa relaciones entre recursos como el título lo indica. Mucho a muchos. Pensemos un poco como sería la incorporación de un conjunto de practicas a una orden en una especificación RESTfull. Por un lado para poder vincular una orden con un conjunto de items practica tendríamos que crear * El recurso orden * los recursos item * vincular los recurso items con el recurso orden. Esto sería asi porque para poder vincular el recurso orden con los items necesito los tokens. Es un problema de orden de creación. El WS no permite crear items de forma aislada. FALTA DOCUMENTAR ===== Políticas ===== ===== =====
Como ya expusimos el WS de suap no es solamente una especificación de intercambio de datos, es además una serie de políticas. Dichas políticas se van guiando mediante las secciones STATUS y VIEW que responde el WS de suap. ==== Política de persistencia. ==== Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método POST. Si el contenido del response contiene una sección REST con un atributo token diferente a null, entonces el recurso se persistió. |Persistencia en el sentido de que se instanció un recurso en la base de datos de suap. La política es simple. Un recurso solo puede ser instanciado a requerimiento del consumidor mediante un método POST. Si el contenido del response contiene una sección REST con un atributo token diferente a null, entonces el recurso se persistió. En cualquier caso si no hay token entonces se puede desestimar la transacción previa puesto que no tuvo repercusión en suap. | ==== Política de acceso a un recurso. ==== Para poder acceder a un recurso es necesario contar con la URI del mismo (Uniform Resource Identifier. Uniform en el sentido de constante). En el caso del WS de suap si se cuenta con el Token de un recurso se puede construir la URI del siguiente modo.

URI Base + ‘/’ + recurso en plural + ‘/’ + Token.

A modo de ejemplo tomemos por caso una orden cuyo token es 1234. En el entorno de test la URI de la misma sería:

Uri Base = https://ws.test.suap.com.ar/procesador/doV2
recurso = orden
token = O1234.

URI: https://ws.test.suap.com.ar/procesador/doV2/orden/O1234
Mediante el método GETa dicha URI se obtendrán todos los datos del recurso. ==== Responsabilidad del WS de suap. ==== Suap garantiza la información del recurso de la forma mas completa posible y mediante dos modalidades que se expresan en dos secciones del Json de respuesta. * REST: Es la sección donde el recurso está detallado en terminos REST. Tomemos por ejemplo una orden cualquiera. En esta sección los atributos (fechas, estados de autorización, etc) estarán con sus valores, por el contrario los recursos relacionados (afiliado, prestador, prescriptor, etc) estarán representados por su URI. * RENDER: En esta sección se representa un recurso en un formato resuelto para el consumidor. A diferencia de REST los recursos relacionados están representados por una nueva clave que contiene información ya ==== Responsabilidad del consumidor ==== El consumidor del ws debe cumplir las siguientes responsabilidades: * Procesar la sección VIEW en cualquier POST (creación de un recurso) * En la generación de un recurso siempre debe existir un atributo que puede escribir el usuario libremente. (campo mágico) * Permitir al usuario hacer un GET de un recurso determinado con el procesamiento de la sección VIEW. Es decir, el consumidor podrá realizar los GETs que desee para administrar la sincronización entre su sistema y suap prescindiendo del procesamiento del view si lo deseara. Pero en algún lugar debe inlcuir un procesamiento de VIEW para el usuario. ===== APÉNDICE ===== ==== Descripción de Recursos ==== * recursos desde punto atencion * :desarrolladores:recursos desde colegio ===== Tipos de atributo ===== ==== timestamp ==== El tipo fecha es en realidad una fecha y una hora. El formato completo es:

AAAA-MM-DD HH:mm:SS

Por ejemplo el día 28 de julio de 2018 se escribe 2018-06-28 00:00:00. Las horas van de 0 a 23. No hay am y pm. ==== string ==== ===== ===== ==== token ==== ===== Estado autorización ORDEN: ===== |EstadoAutorizacion |Texto |Explicación | |0 |SIN_PROCESAR |La orden no pasó por ningún proceso de validación de forma completa | |1 |AUTORIZADA |Todas las prestaciones contenidas en la orden están autorizadas. | |2 |PARCIALMENTE_AUTORIZADA |Hay por lo menos una prestación de la orden autorizada y el resto de las prestaciones rechazadas. Esta orden contiene estrictamente prestaciones que están autorizadas o rechazadas. | |3 |REMITIDA_AUDITORIA |La orden en su totalidad está remitida a auditoría a pesar de que contenga prestaciones autorizadas. No es una orden consumible, está sujeta a la observación de un médico auditor la resolución. | |4 |RECHAZADA |Todas las prestaciones de la orden están rechazadas. | |5 |PARCIALMENTE_REMITIDA_AUDITORIA |La orden presenta al menos una prestación autorizada y una prestación remitida a auditoría. El resto de las practicas pueden estar rechazadas, autorizadas o remitidas a auditoría. Las practicas autorizadas de la orden se pueden consumir, pero las practicas pendientes pueden decantar en un rechazo o autorización luego de que el médico auditor observe la situación. | |6 |AUTORIZADA_EXTRA_SISTEMA |La orden puede ser facturada a pesar de no contar con una autorización por sistema informático. Está autorizada por un aval en papel. Puede requerir la carga de algún número de expediente o no. | |7 |REMITIDA_AUDITORIA_ADM |Idem el estado 3 pero será revisada por un auditor que no es médico. Esta situación es para aplicar controles que no requieren criterios médicos pero si debe ser revisado por un ser humano | |8 |PARCIALMENTE_REMITIDA_AUDITORIA_ADM |Idem el estado 5 pero será revisada por un auditor que no es médico. | ===== Operadores de SEARCH ===== Los operadores van sobre el final de la ruta del atributo del recurso y siempre en minúscula. Si se agregan de un mismo recurso varios criterios en diferentes atributos debe considerarse que se aplican todos unidos por el operador lógico Y (AND). ==== Igual ==== El atributo debe ser igual al valor que se indica. Es como el operador == o = de algunos lenguajes. Por ejemplo: |{
…
“practicas.NBU.igual”:”660475”, …
} | Aquí el recurso practicas debe ser uno o varios tal que su atributo NBU sea exactamente igual al valor 660475 ==== mayor / menor ==== El atributo debe ser mayor o menor que el valor que se indica. En el caso de fechas y números es claro y en el caso de textos se respeta el orden alfabético.
Son como el operador > (mayor) y < (menor) de algunos lenguajes. |{
…
“fechaRealizacion.mayor”:”23062018”, …
} | ==== mayor_o_Igual / menor_o_Igual ==== ===== ===== Son lo mismo que el operador mayor o menor en cada caso, pero además el valor puede ser igual.
Son como el operador >= (mayor o igual) y ⇐ (menor o igual) de algunos lenguajes. |{
…
“fechaRealizacion.mayor_o_Igual”:”23062018”, …
} | ==== contenga ==== La condición de coincidencia se satisface si el texto dado está presente en alguna posición del atributo. Es como el operador LIKE de algunos lenguajes. |POST a una búsqueda de afiliados
https://uriBase/search.afiliados]]]]]]
{
…
“Nombre.contenga”:”Guillermo”, …
} | En el ejemplo se buscan todos los afilidos que contengan la cadena “Guillermo” dentro del atributo Nombre. ==== in ==== |POST a una búsqueda de afiliados
https://uriBase/search.afiliados]]]]]]
{
…
“Nombre.in”:”Guillermo”, …
} |