FHIR_CORE_AR - Local Development build (v0.5.0). See the Directory of published versions

Recomendaciones

Validaciones generales

Tipos de Datos

Se validarán, obviamente, los tipos de datos para que coincidan con lo definido con el standard FHIR R4.

Elementos Mínimos Obligatorios

Se validarán los atributos mínimos obligatorios definidos por el standard, en adición a los atributos definidos obligatorios por el perfil argentino de estos recursos.

Elementos Mínimos Contingentes (MUST-SUPPORT)

Se validarán los atributos mínimos obligatorios definidos por el standard, en adición a los atributos definidos obligatorios por el perfil argentino de estos recursos.

Otros elementos

Cualquier otro elemento no mencionado (sin restricciones en el standard ni en este documento) se considerará válido.

Validaciones de recurso / DocumentReference

Subject / Referencia a Paciente

Debe ser una referencia lógica (identifier.system/identifier.value) El system de subject debe ser el identificador de dominio (http://dummy.com.ar). El value de subject debe ser el identificador local de paciente (1).

Custodian / Referencia a Organización a Cargo

El custodian debe ser una referencia lógica. El system de custodian debe ser “https://federador.msal.gob.ar/uri” El value de custodian debe ser el identificador de dominio (http://dummy.com.ar).

Type / Tipo de Documento

El type debe tener un coding cuyo system sea “http://loinc.org” y que el value sea código de loinc “60591-5”

Content / Contenido del Documento

El content attachment debe tener una url que corresponda con un recurso “Bundle” del mismo endpoint (“/Bundle/” o “http://api.dummy.com.ar/fhir/Bundle/”).

Validaciones de recurso IPS (Bundle de Tipo Document IPS-AR)

Entries del Bundle

Las entries del Bundle deben referenciarse según lo especifica el estandard, mediante fullUrls y referencias absolutas o relativas (resolubles en el bundle). Para evitar dificultades, se recomienda fuertemente que las fullUrl tengan la siguiente estructura: Url del dominio + “/” + tipo de recurso (camel case) + “/” + identificador de recurso. Ejemplo “http://dummy.com.ar/Condition/3”. Los identificadores deben ser unívocos por recurso. Es invalido tener “Condition/2” y “Condition/2” Es valido tener “Patient/1” y “Condition/1. Los identificadores pueden no ser unívocos entre distintos IPS. La “Condition/1” de un ips puede no corresponderse con la “Condition/1” de otro ips de otro paciente (o del mismo paciente pero generada en un momento distinto). Obviamente, es recomendable que si se correspondan. Asumiendo que los problemas tendran id unico en un software de historia clinica, se recomienda usar dicho id para evitar problemas.

Primera Entry -> Composition

La primer entry debe ser un Composition (Argentina) El status requiere un valor “final”. El type debe tener un coding cuyo system sea “http://loinc.org” y que el value sea código de loinc “60591-5” El author debe ser una referencia lógica (Organization). El author debe tener system “https://refes.msal.gob.ar”. El custodian debe ser una referencia lógica. El system de custodian debe ser “https://federador.msal.gob.ar/uri” El value de custodian debe ser el identificador de dominio (http://dummy.com.ar). Se deben contar con 4 secciones (códigos loinc) Lista de problemas (“http://loinc.org|11450-4”) Lista de alergias (“http://loinc.org|48765-2”) Lista de medicamentos (“http://loinc.org|10160-0”) Lista de vacunas (“http://loinc.org|60484-3”) Todas las secciones tendrán lista de entries con referencias a recursos Condition, AllergyIntollerance, MedicationStatement e Immunization (incluidos en el Bundle). Todas las secciones deben tener una narrativa en html simplificado, que permita a otros dominios (con menor poder de desarrollo) a interpretar el IPS.

Entry: Patient

La entry de Patient Deberá cumplir con las validaciones ya definidas para el proceso de federación de pacientes del federador nacional. (GOTO)

Entry: Condition -> Lista de Problemas Activos

El clinicalStatus debe ser “active” o “inactive”. El code debe tener system “http://snomed.info/sct”.

Entry: AllergyIntollerance -> Alergias

El code debe tener system “http://snomed.info/sct”.

Entry : MedicationStatement -> Medicación Actual

El atributo medication[x] es válido para ambos subtipos de datos (CodeableConcept o Reference). En caso de tratarse de medicationCodeableConcept el code debe tener system “http://snomed.info/sct”. Si no se cuentan con demasiados datos de medicación, se recomienda usar este tipo de dato. En caso de tratarse de medicationReference debe referenciar un recurso Medication (incluido en el Bundle). Dicho recurso Medication debe cumplir con la restricción de coding definida en el ítem anterior. El effective[x] es válido para ambos subtipos de datos (DateTime o Period).

Entry : Immunization -> Registros de Vacunación

Deberán cumplir con las validaciones ya definidas para el proceso de registro de vacunas en Nomivac