Receta Digital Interoperable Argentina
0.2.5 - ci-build
Receta Digital Interoperable Argentina - Local Development build (v0.2.5). See the Directory of published versions
Esta sección explica brevemente como leer los requerimientos que deben cumplir los actores (sistemas) que implementan recetas digitales o electrónicas de conformidad con esta guía.
Los requerimientos de conformidad describen las expectativas sobre la funcionalidad de aplicaciones servidor/cliente. Para cada actor, la guía identifica el conjunto de perfiles y las interacciones específicas que deben implementar.
Los perfiles identifican los requerimientos estructurales y terminológicos de los recursos FHIR que se van a generar o intercambiar. Las interacciones especifican cómo deben ser implementados estos recursos y se definen mediante parámetros de búsqueda y operaciones.
Los sistemas que implementen RDIar deberán soportar el conjunto de perfiles, parámetros de búsqueda y operaciones obligatorias definidas para cada actor, según el/los rol/es funcionales que tenga el sistema.
Los requerimientos de conformidad se especifican en esta guía de forma narrativa y con estructuras FHIR que permiten la representación de reglas computables y susceptibles de validación automática.
En los elementos narrativos de esta guía, el lenguaje de conformidad que se utiliza está definido en la especificación base FHIR reglas de conformidad:
Los recursos de dominio en la especificación FHIR son estructuras estándar que sirven para representar e intercambiar información clínica o administrativa en el ámbito de la salud. Por ejemplo el recurso Patient (paciente), tiene elementos estructurados para contener los identificadores de un paciente, nombres, apellidos, direcciones, etc.
Los perfiles son definiciones estructuradas de recursos. Son modelos que definen de manera formal y detallada los elementos que deben o pueden componer un recurso, y, para los elementos codificables, también determinan los vocabularios (terminología o semántica) que se deben o pueden utilizar y el conjunto válido de códigos. Además, los perfiles incluyen los parámetros de búsqueda que un servidor debería soportar para cada tipo de recurso.
El estándar FHIR permite generar un perfil en base a otro, restringiendo o ajustando el modelo de un recurso a un ámbito o caso de uso particular. También permite crear extensiones (agregar elementos que no están contemplados en el perfil tomado como base).
Los perfiles de la especificación internacional son poco restrictivos, contemplan muchos elementos para cada recurso y en general ninguno o muy pocos son obligatorios. La especificación FHIR CORE-AR está basada en la internacional, y define algunos perfiles base ajustados al ámbito argentino. Por ejemplo, el perfil de Paciente internacional admite identificadores de cualquier tipo y no especifica ninguno, mientras que el perfil Paciente Argentino define que al menos uno de estos identificadores debe ser el dni y siempre debe estar presente.
Esta guía está basada en la especificación FHIR CORE-AR y la internacional version R4. Incluye los perfiles de los recursos requeridos para los casos de uso definidos en RDIar. Se utilizan estos perfiles para definir los datos mínimos que deben contener las recetas y los registros de dispensa.
La sección artefactos contiene todos los perfiles definidos en la guía (Resource profiles). Tambien contiene:
Value sets: son los conjuntos de códigos válidos que se usan en uno más perfiles de esta guía.
Example Instances: ejemplos de recursos conformantes para cada uno de los perfiles definidos en esta guía.
Los perfiles se pueden descargar en distintos formatos y leerse desde su interfaz gráfica. La interfaz gráfica provee información contextual y descripciones de cada elemento. En este link se explica en detalle las distintas vistas y el significado de los símbolos utilizados.
La cardinalidad define la cantidad de veces que puede aparece un elemento dentro del recurso, se define cardinalidad mínima y máxima.
Elementos obligatorios: son los elementos que tienen cardinalidad mínima > 0. Estos elementos deben estar presentes y deben ser soportados por todos los sistemas que usen el recurso.
Elementos opcionales marcados como Must support (debe soportarse): Estos elementos pueden estar ausentes sin generar error, pero si están presentes deben ser soportados por todos los sistemas que usen el recurso.
Elementos opcionales: son los elementos sin marcas especiales, con cardinalidad mínima = 0 y máxima >=1. Los sistemas pueden soportar o ignorar estos elementos, no son requerimiento de conformidad para los casos de uso definidos en RDIar.