Parámetros de Búsqueda Integrados en FHIR
La especificación FHIR define una interfaz HTTP para datos médicos complejos, incluyendo información «simple» del paciente como el historial de sus declaraciones, avales, observaciones, etc. Dichos datos se representan como un conjunto de recursos jerárquicos conectados (objetos JSON), que pueden contener: elementos opcionales, objetos, arrays, elementos polimórficos (con más de un tipo de dato, como los Tipos de Datos Algebraicos) y extensiones (elementos propios de FHIR que se explican más adelante).
Uno de los problemas: ¿cómo solicitar/buscar dichos datos? Por ejemplo, si necesitamos encontrar a todos los pacientes con una ocupación específica, ¿cómo encajar esas consultas en una URL? Escribir consultas complejas como FHIRPath o JSONPath directamente en la URL resulta poco legible.
Parámetros de Búsqueda Integrados en FHIR
La respuesta de FHIR a esto son los Search Parameters. Para simplificar, podemos considerarlos alias de consultas FHIRPath. Veamos algunos ejemplos para el recurso Patient; estos son los parámetros de búsqueda integrados:
active
Para encontrar registros de pacientes activos. En una URL tendría el siguiente aspecto: GET /fhir/Patient?active=true. Es algo más sencillo que el FHIRPath real:
FHIRPath: `Patient.active`.
email
Este ejemplo es algo más complejo, porque el correo electrónico puede encontrarse en distintas ubicaciones según el recurso.
FHIRPath:
Patient.telecom.where(system='email')
| Person.telecom.where(system='email')
| Practitioner.telecom.where(system='email')
| PractitionerRole.contact.telecom.where(system='email')
| RelatedPerson.telecom.where(system='email')
Lo que observamos aquí:
-
Puede aplicarse a muchos tipos de recursos.
-
La información sobre el correo electrónico se encuentra en distintas ubicaciones según el recurso (normalmente en el objeto
telecom, aunque puede estar dentro decontact). -
Por lo general, toda la información de contacto se almacena en un único array, por lo que es necesario filtrar únicamente la información de «email», lo cual se realiza mediante la expresión
where(...).
Más Allá de los Parámetros de Búsqueda Integrados
No resultaría demasiado útil si solo pudiéramos cubrir los casos estándar con los parámetros de búsqueda integrados.
En ocasiones es necesario almacenar información «personalizada», como por ejemplo la ocupación del paciente, que no forma parte del recurso Patient pero puede ser relevante para algunas aplicaciones. En ese caso, podemos adjuntar dicha información como una extension del recurso de la siguiente forma, siguiendo el Extension Element:
{
"resourceType": "Patient",
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/patient-citizenship",
"extension": [
{
"url": "code",
"valueCodeableConcept": {
"coding": [
{
"system": "urn:iso:std:iso:3166",
"code": "DE"
}
]
}
},
{
"url": "period",
"valuePeriod": {
"start": "2009-03-14"
}
}
]
}
]
}
Para buscar dichos objetos, podemos definir parámetros de búsqueda personalizados como:
{
"resourceType": "SearchParameter",
"id": "patient-citizenship",
"url": "http://example.org/fhir/SearchParameter/patient-citizenship",
"version": "1.0.0",
"name": "citizenship",
"status": "active",
"description": "Search patients by citizenship",
"code": "citizenship",
"base": [
"Patient"
],
"type": "string",
"expression": "Patient.extension.where(url='http://hl7.org/fhir/StructureDefinition/patient-citizenship').value.as(string)"
}
Y podemos utilizarlo en una URL como: GET /fhir/Patient?citizenship=GB
En conclusión, los Search Parameters de FHIR junto con FHIRPath son herramientas potentes y extensibles para buscar datos médicos complejos. Puede encontrar información sobre cómo trabajar con ellos en Aidbox, así como otros ejemplos, en la documentación.
Véase también: Resolve FHIR SearchParameters Conflicting y New Resource Browser.
