{"id":8475,"date":"2020-04-25T21:40:43","date_gmt":"2020-04-26T04:40:43","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=8475"},"modified":"2025-06-13T23:42:42","modified_gmt":"2025-06-14T06:42:42","slug":"fhir-data-model-with-couchbase-n1ql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/fhir-data-model-with-couchbase-n1ql\/","title":{"rendered":"Modelo de datos FHIR con Couchbase N1QL"},"content":{"rendered":"

Couchbase es una base de datos JSON que se ha convertido en una alternativa a los RDBMS tradicionales. Lo ha conseguido, no s\u00f3lo proporcionando el almac\u00e9n clave-valor l\u00edder del sector y las mismas capacidades de consulta y traducci\u00f3n ACID que las organizaciones esperan, sino tambi\u00e9n la flexibilidad de almacenar de forma nativa sus datos en formato JSON. Adem\u00e1s, Couchbase tambi\u00e9n incluye almacenamiento distribuido, escalabilidad multidimensional, alta disponibilidad y replicaci\u00f3n entre centros de datos (XDCR). Todo ello en una \u00fanica Plataforma de Datos Couchbase que se extiende al Edge con Couchbase Mobile.<\/span><\/p>\n

Couchbase tambi\u00e9n se ha comprometido a ampliar sus capacidades mucho m\u00e1s all\u00e1 de lo que se necesita en las aplicaciones RDBMS tradicionales. Con Couchbase Cloud, donde todo est\u00e1 totalmente gestionado y automatizado, proporcionando una segura base de datos como servicio (DBaaS) que simplifica la gesti\u00f3n del esquema de base de datos FHIR mediante el despliegue, la gesti\u00f3n y el funcionamiento de Couchbase Server en entornos multi-nube con s\u00f3lo unos clics. Couchbase Cloud es flexible, altamente disponible y ofrece una opci\u00f3n econ\u00f3mica diferenciada para las empresas que buscan reducir las tareas operativas al tiempo que aprovechan la tecnolog\u00eda NoSQL m\u00e1s potente. <\/span><\/p>\n

Tambi\u00e9n lo estamos haciendo colaborando con muchos de nuestros clientes de diferentes sectores para entender sus necesidades empresariales y c\u00f3mo Couchbase puede ayudarles con esos retos. Estos sectores van desde el comercio minorista y electr\u00f3nico, los viajes y la hosteler\u00eda, los servicios financieros, la energ\u00eda y los servicios p\u00fablicos, hasta la alta tecnolog\u00eda y los juegos.<\/span><\/p>\n

En este blog, me gustar\u00eda centrarme en c\u00f3mo la base de datos Couchbase se puede utilizar en la industria de la Salud. En concreto, me centrar\u00e9 en la especificaci\u00f3n Fast Healthcare Interoperability Resources (FHIR) definida por <\/span>HL7 FHIR<\/span><\/a>. El motivo de este blog es el nivel de inter\u00e9s de muchos de nuestros clientes que actualmente est\u00e1n planificando o implementando sus aplicaciones compatibles con FHIR utilizando la base de datos Couchbase.<\/span><\/p>\n

\u00bfPor qu\u00e9 le interesa FHIR con Couchbase?<\/h3>\n
    \n
  1. Las organizaciones buscan desarrollar aplicaciones FHIR, y\/o estudian la posibilidad de aprovechar las numerosas ventajas de las bases de datos NoSQL, como la escalabilidad distribuida, de alta disponibilidad, XDCR y multidimensional.<\/li>\n
  2. Los arquitectos o desarrolladores necesitan entender c\u00f3mo la base de datos JSON de Couchbase puede reducir enormemente la complejidad de sus aplicaciones, relegando la compleja b\u00fasqueda FHIR [https:\/\/www.hl7.org\/fhir\/searchparameter-registry.html<\/a>] a la capa del servidor de base de datos.<\/li>\n
  3. Los analistas de datos deben saber c\u00f3mo aprovechar sus conocimientos de SQL para consultar datos FHIR directamente con Couchbase N1Q<\/a>L y B\u00fasqueda de texto completo.<\/a><\/li>\n
  4. Usted est\u00e1 interesado en averiguar c\u00f3mo Couchbase N1QL, un SQL para JSON, puede proporcionar una manera eficiente de consultar un modelo de datos relacional, tal como se define por el protocolo FHIR, que es a la vez jer\u00e1rquico JSON y relacional en la naturaleza.<\/li>\n<\/ol>\n

    \u00bfQu\u00e9 es FHIR?<\/span><\/h3>\n

    FHIR\u00ae - Recursos de interoperabilidad sanitaria r\u00e1pida<\/a> - es un marco de est\u00e1ndares de nueva generaci\u00f3n creado por HL7. FHIR (pronunciado \"fire\") combina las mejores caracter\u00edsticas de HL7 y aprovecha los \u00faltimos est\u00e1ndares web, aplicando un estricto enfoque en la implementabilidad de los intercambios de informaci\u00f3n.<\/span><\/p>\n

    Las aplicaciones FHIR se basan en el concepto de \"Recursos\". Estos recursos se ensamblan en aplicaciones sanitarias espec\u00edficas, que abarcan desde las funciones administrativas y cl\u00ednicas hasta la atenci\u00f3n al paciente. <\/span>FHIR se puede utilizar en una amplia variedad de contextos: aplicaciones para tel\u00e9fonos m\u00f3viles, comunicaciones en la nube, intercambio de datos basados en HCE, comunicaci\u00f3n con servidores para proveedores sanitarios.<\/p>\n

    Uno de los objetivos clave de FHIR es especificar una norma que puedan adoptar distintas aplicaciones sanitarias, lo que permitir\u00e1 la interoperabilidad entre diferentes aplicaciones funcionales y, en \u00faltima instancia, reducir\u00e1 el coste de las implantaciones.<\/p>\n

    Consulte el Sitio web sobre FHIR<\/a> para m\u00e1s informaci\u00f3n.<\/span><\/p>\n

    El modelo de datos FHIR<\/span><\/h4>\n

    El n\u00facleo de FHIR es la definici\u00f3n com\u00fan de los distintos tipos de recursos que abarcan todos los aspectos de la asistencia sanitaria. Desde la funci\u00f3n administrativa de Paciente, Profesional, Equipo asistencial, Dispositivo, Organizaci\u00f3n, Ubicaci\u00f3n, Servicio sanitario, hasta la Cl\u00ednica, Diagn\u00f3stico, Medicamentos, as\u00ed como las funciones Financieras como la Cobertura del seguro.<\/span><\/p>\n

    Para el prop\u00f3sito de este art\u00edculo, estoy utilizando el conjunto de datos sint\u00e9ticos de muestra disponible en Synthetic Mass que ha sido generado por Synthea<\/a>una simulaci\u00f3n de poblaci\u00f3n de pacientes de c\u00f3digo abierto facilitada por The MITRE Corporation.<\/span><\/p>\n

    Los datos se pusieron a disposici\u00f3n como un paquete de recursos para cada paciente sint\u00e9tico, que luego se importan a una instancia de la base de datos Couchbase 6.5.<\/span><\/p>\n

    \"HL7<\/p>\n

    SELECT resourceType, COUNT(1) doc_count\r\n FROM fhir_admin\r\nWHERE resourceType IS NOT MISSING\r\n GROUP BY resourceType\r\n\r\ndoc_count\tresourceType\r\n567\t\"AllergyIntolerance\"\r\n3577\t\"CarePlan\"\r\n3577\t\"CareTeam\"\r\n52387\t\"Claim\"\r\n8714\t\"Condition\"\r\n57\t\"Device\"\r\n17069\t\"DiagnosticReport\"\r\n42019\t\"Encounter\"\r\n42019\t\"ExplanationOfBenefit\"\r\n2942\t\"Goal\"\r\n965\t\"ImagingStudy\"\r\n14982\t\"Immunization\"\r\n926\t\"MedicationAdministration\"\r\n10368\t\"MedicationRequest\"\r\n235332\t\"Observation\"\r\n1033\t\"Organization\"\r\n1177\t\"Patient\"\r\n1034\t\"Practitioner\"\r\n32454\t\"Procedure\"\r\n<\/pre>\n
    Algunos puntos destacables sobre el modelo de datos FHIR<\/span><\/h4>\n
      \n
    1. El modelo se centra en el objeto \"paciente<\/span><\/li>\n
    2. El tipo de objeto est\u00e1 representado por el campo \"resourceType\".<\/span><\/li>\n
    3. La estructura JSON admite un conjunto m\u00e1s rico de informaci\u00f3n sanitaria que puede conservarse sobre el paciente: nivel de salud, datos de contacto, direcciones, comunicaciones, etc.<\/span><\/li>\n
    4. Cada objeto tiene un campo \"id\" identificable de forma \u00fanica.<\/span><\/li>\n
    5. Los objetos se referencian entre s\u00ed. La mayor\u00eda hacen referencia al objeto \"paciente\".<\/span><\/li>\n<\/ol>\n
      Por qu\u00e9 Couchbase es adecuado para FHIR<\/span><\/h3>\n
      Como se mencion\u00f3 anteriormente, Couchbase almacena sus datos de forma nativa en JSON, que es un formato de documento legible. Las aplicaciones pueden utilizar las APIs de Clave-Valor, o aprovechar el Lenguaje de Consulta N1QL de Couchbase para manipular los documentos. La ventaja de almacenar los datos en formato JSON, en lugar de como un tipo de columna como en muchos RDBMS, es la facilidad con la que los usuarios pueden acceder a la informaci\u00f3n contenida. Se puede acceder a los elementos del documento JSON, como campo, objeto matriz y objeto jer\u00e1rquico, directamente desde el objeto padre sin necesidad de sintaxis adicional. <\/span><\/p>\n
      He aqu\u00ed un ejemplo del documento Paciente tal y como lo define el FHIR.<\/span><\/p>\n
      \"HL7<\/p>\n
      Lo que significa para la aplicaci\u00f3n FHIR es que los usuarios con experiencia en RDBMS que tengan conocimientos b\u00e1sicos de SQL pueden acceder al paciente FHIR y a los recursos asociados exactamente igual que con el RDBMS tradicional.\u00a0<\/span><\/p>\n
      Couchbase N1QL para buscar datos FHIR<\/h4>\n
      Consulta de pacientes por ID<\/strong><\/h5>\n
      SELECT *\r\nFROM fhir_admin res\r\nWHERE res.resourceType='Patient'\r\nAND\u00a0 res.id='e3ae7831-14c8-4d13-a8fb-dad68fa12bc9'<\/pre>\n
      Consulta de pacientes por grupos de edad<\/strong><\/h5>\n
      SELECT\u00a0 agegroup,count(*)\r\nFROM fhir_admin p\r\n\u00a0\u00a0\u00a0LET age=DATE_DIFF_STR(now_str(),p.birthDate,'year'),\r\n\u00a0\u00a0\u00a0\u00a0agegroup = CASE WHEN age <= 4 THEN 'A - 0-4'\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0WHEN age <= 17 THEN 'B - 5-17'\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0WHEN age <= 49 THEN 'C - 18-49'\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0WHEN age <= 64 THEN 'D - 50-64'\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ELSE 'E - > 65' END\u00a0\r\nWHERE p.resourceType='Patient'\r\nGROUP BY agegroup<\/pre>\n
        \n
      1. La edad del paciente debe calcularse a partir de la fecha actual - DOB.<\/li>\n
      2. La consulta utiliza la construcci\u00f3n N1QL LET para definir \"edad\" y agrupar la edad en \"grupo de edad\".<\/li>\n
      3. Un est\u00e1ndar ANSI GROUP BY y COUNT devuelve el n\u00famero de pacientes por grupo de edad.<\/li>\n<\/ol>\n
        Adem\u00e1s, la capacidad de JOIN y UNNEST de documentos con Couchbase N1QL permite a los usuarios consultar informaci\u00f3n relacionada del paciente.<\/p>\n
        Consultar a los pacientes y sus afecciones actuales no resueltas\u00a0<\/strong><\/h5>\n
        SELECT ARRAY v FOR v IN p.name WHEN v.`use`='official' END fullname ,\r\n       cc.display\r\nFROM fhir_admin c\r\nINNER JOIN fhir_admin p USE HASH(BUILD) ON split(c.subject.reference,':')[2] = p.id AND p.resourceType='Patient'\r\nUNNEST c.code.coding as cc\r\nWHERE c.resourceType='Condition'\r\nAND EVERY s in c.clinicalStatus.coding SATISFIES s.code != 'resolved' END\r\n<\/pre>\n
          \n
        1. Un paciente puede tener varios nombres, que se representan en la matriz \"name\". Esta consulta utiliza el operador ARRAY para filtrar \u00fanicamente el elemento oficial de la matriz 'name'.<\/li>\n
        2. La consulta une la \"condici\u00f3n\" con el objeto \"paciente\" utilizando parte del campo \"asunto.referencia\" del objeto \"condici\u00f3n\" con el \"id.paciente\".<\/li>\n
        3. Cada 'paciente' puede tener m\u00faltiples condiciones, de ah\u00ed la necesidad de aplanar (UNNEST) el array 'condition->code'.<\/li>\n
        4. Puede haber varios \"clinical.status\" para la \"condici\u00f3n\", pero la consulta s\u00f3lo debe devolver las condiciones que no se hayan resuelto.<\/li>\n<\/ol>\n
          Lista de todos los pacientes que estuvieron en el hospital de Beverley en la semana que comenz\u00f3 el 2011-08-18<\/strong><\/h5>\n
          SELECT ARRAY v FOR v IN p.name WHEN v.`use`='official' END fullname ,\r\n       p.telecom phonecontact,\r\n       p.address, \r\n       p.communication,\r\n       p.identifier\r\nFROM fhir_admin m\r\n INNER JOIN fhir_admin p ON split(m.subject.reference,':')[2] = p.id AND p.resourceType='Patient' \r\nWHERE m.resourceType='Encounter'\r\nAND DATE_FORMAT_STR(m.period.`start`, '1111-11-11') BETWEEN '2011-08-18' AND '2011-08-25'\r\nAND m.serviceProvider.display = 'BEVERLY HOSPITAL CORPORATION' \r\n<\/pre>\n
            \n
          1. La consulta examina el objeto \"encuentro\" para averiguar todos los tratamientos del \"paciente\" en este hospital concreto.<\/li>\n
          2. El operador ARRAY se utiliza para obtener el nombre oficial del \"paciente\".<\/li>\n<\/ol>\n
            Lista de pacientes con el detalle de su reclamaci\u00f3n al seguro: servicios y coste<\/strong><\/h5>\n
            SELECT  c.patient.reference, cis.display,SUM( c.total.`value`)\r\nFROM fhir_admin c\r\n INNER JOIN fhir_admin p ON split(c.patient.reference,':')[2] = p.id AND p.resourceType='Patient' \r\n UNNEST c.item as ci\r\n UNNEST ci.productOrService.coding as cis\r\nWHERE c.resourceType='Claim'\r\nGROUP by cis.display,c.patient.reference\r\n<\/pre>\n
              \n
            1. El objeto \"reclamaci\u00f3n\" se une al objeto \"paciente\" para acceder a los datos del paciente.<\/li>\n
            2. El objeto 'claim' tiene un array anidado para 'claim->item'.<\/li>\n
            3. El 'claim->item' est\u00e1 asociado a un 'productOrService' con una codificaci\u00f3n array que contiene la descripci\u00f3n del tratamiento.<\/li>\n
            4. El coste es a nivel de siniestro.<\/li>\n<\/ol>\n
              Clasificaci\u00f3n del recuento de procedimientos por hospitales<\/strong><\/h5>\n
              SELECT e.serviceProvider.display hospital,\r\n       p.code.text treatment,\r\n       RANK() OVER ( PARTITION BY e.serviceProvider.display ORDER BY COUNT(p.code.text) DESC ) serviceRank\r\nFROM fhir_admin p\r\n  INNER JOIN fhir_admin e USE HASH(PROBE) ON split(p.encounter.reference,':')[2] = e.id and e.resourceType='Encounter'\r\nWHERE p.resourceType='Procedure'\r\nGROUP by e.serviceProvider.display,p.code.text<\/pre>\n
                \n
              1. El objeto \"procedimiento\" se UNE al objeto \"encuentro\" para acceder al hospital donde se administr\u00f3 el procedimiento.<\/li>\n
              2. La funci\u00f3n N1QL Window RANK se utiliza para asignar un valor por el recuento del procedimiento.<\/li>\n
              3. La sugerencia Hash Join se utiliza para mejorar el rendimiento del documento JOIN.<\/li>\n<\/ol>\n
                Resumen<\/h3>\n
                Couchbase es muy adecuado para la implementaci\u00f3n de FHIR debido al enfoque que utiliza para almacenar los datos en formato JSON. Su potente lenguaje de consulta N1QL permite a los desarrolladores con experiencia en SQL navegar por el modelo de datos FHIR para realizar todas las operaciones CRUD que los usuarios esperar\u00edan ver en una base de datos.<\/p>\n
                Con su capacidad para realizar desde JOIN de documentos hasta el procesamiento avanzado de objetos array incrustados, el lenguaje de consulta N1QL relega todas las necesidades de procesamiento al Servicio de Consulta e Indexaci\u00f3n de Couchbase, reduciendo as\u00ed la carga de las aplicaciones FHIR a tener que realizar todas las asociaciones de objetos.<\/p>\n
                Como ocurre con cualquier aplicaci\u00f3n nueva, siempre ser\u00e1 necesario realizar ex\u00e1menes directos de los datos subyacentes, ya sea por parte de los administradores de la aplicaci\u00f3n o de los analistas de datos, que pueden tener la necesidad de realizar b\u00fasquedas m\u00e1s all\u00e1 de las capacidades b\u00e1sicas de b\u00fasqueda de FHIR.<\/p>\n
                En el pr\u00f3ximo blog, voy a examinar lo que se necesita para utilizar REST para un enfoque de la API FHIR que puede comunicarse con el servidor Couchbase para proporcionar la b\u00e1sica Requisitos de b\u00fasqueda de FHIR.<\/a><\/p>\n
                Recursos<\/h3>\n