Etapa 1; recopilación y análisis de información

El primer paso es contar con fuentes de información válidas y confiables. Esto resulta de mayor relevancia cuando la información que se representará en el grafo corresponde al dominio médico y de cuidado de la salud. Por lo anterior, lo primero que se realiza es la búsqueda de fuentes de información confiables acerca del coronavirus SARS-CoV-2, con la finalidad de conocer los términos o entidades conceptuales que son clave, así como las relaciones que pueden existir entre los conceptos.

Las fuentes de información que se consideraron son las siguientes:

Con base en esta información se realizó la identificación de los siguientes términos relevantes para la representación y gestión de datos de pacientes: Paciente, Diagnóstico, Enfermedad, Medicamento, Síntoma, Prueba de Laboratorio y Vacuna. Adicionalmente se consideró incluir el registro de información del municipio y estado donde reside y dónde nació el paciente.

Etapa 2; búsqueda y selección de grafos de conocimiento existentes

El objetivo de esta etapa es realizar la búsqueda de grafos de conocimiento para determinar si existen grafos que cuenten con los conceptos que se requieren en el grafo general que se va a integrar. Bioportal⁷ es uno de los repositorios más completos de bases de conocimiento biomédicas. Una vez que se han identificado los grafos que cuentan con representaciones relacionadas, éstos se deben revisar y estudiar para conocer más detalladamente su estructura, de tal forma que se pueda decidir si es conveniente el reutilizarlos total o parcialmente. Por ello, es importante conocer las clases y conceptos médicos relacionados con la enfermedad del COVID-19, así como las propiedades que éstos manejan, tal como menciona ^{Whetzel et al. (2011)}.

De acuerdo con los requerimientos conceptuales considerados, el modelo integral debería incluir grafos relacionados con los conceptos de: Enfermedad, Medicamento, Signo y Síntoma, Prueba de Laboratorio y Vacuna. El primer grafo que se consultó fue NDFRT (National Drug File - Reference Terminology), ya que este incluye conceptos relacionados con los medicamentos como son: los efectos fisiológicos, las categorías terapéuticas, la estructura química, las enfermedades que puede tratar, las enfermedades que puede prevenir, entre otros. NDFRT cuenta con 36,200 clases aproximadamente. Por otra parte, LOINC (Logical Observation Identifier Names and Codes), es un grafo que incluye conceptos de todo tipo de pruebas de laboratorio, incluyendo aquellas pruebas de laboratorio para descartar o confirmar casos positivos de COVID-19, cuenta con 281,878 clases aproximadamente. Otro grafo que se revisó es SYMP (Symptom), este grafo describe un conjunto amplio de síntomas de manera general, síntomas ocasionados por la enfermedad, cuenta con aproximadamente 1000 clases. Por último, se consultó el grafo NCIT (National Cancer Institute Thesaurus), este grafo incluye un amplio conjunto de conceptos biomédicos, desde la representación de procesos biológicos y los materiales biomédicos de los que se deriva el módulo de vacunas para COVID-19, cuenta con más de 174,278 clases.

La Tabla 1 muestra el nombre (o acrónimo), el significado y el Identificador de Recursos Internacionalizado (IRI) de cada uno de los grafos seleccionados para reutilización.

Etapa 3; diseño del modelo general del grafo de conocimiento general

El diseño que da soporte al Grafo de Conocimiento General se realizó tomando en consideración el resultado del análisis de la información relacionada con normas nacionales e internacionales para el manejo de información de pacientes con COVID-19. Mediante un proceso de elicitación de términos, se identificaron los conceptos principales que deben ser representados en el grafo de conocimiento general. En esta sección se describen los criterios del diseño cada uno de estos conceptos.

En la Figura 2 se muestran los cinco subgrafos o módulos integrados en el grafo de conocimiento, así como las meta-relaciones entre estos grafos.

Fuente: Propia de los autores.

Figura 2 Modelo general de los módulos que integran el grafo de conocimiento PatientElectronicRecord. 

Etapa 4; construcción del grafo de conocimiento general

El grafo PatientElectronicRecord, incluye los conceptos que se muestran en la Tabla 2.

Para cada uno de los conceptos de la Tabla 2 se definieron las propiedades de datos que caracterizan a los individuos que pertenece a cada concepto (ver Tabla 3).

En la Tabla 4 se muestran las propiedades entre conceptos (meta-relaciones) del grafo de conocimiento general PatientElectronicRecord.

Etapa 5; extracción de módulos de grafos existentes para su reutilización

La reutilización basada en módulos ha sido bien aceptada por la comunidad de la Web Semántica, ya que generar un modelo más simplificado al original es de gran ayuda. Como se señaló en la Etapa 3 de esta metodología, se identificaron un conjunto de grafos para ser reutilizados; por lo tanto, se definió un método de reutilización basado en la extracción de módulos a partir de los grafos que se listan en la Tabla 1. Este método consiste en la extracción de uno o varios módulos de un grafo de conocimiento, el diseño y generación automática de un modelo simplificado y la reutilización del modelo simplificado mediante su importación en el grafo general, tal como se muestra en la Figura 3.

Fuente: Propia de los autores.

Figura 3 Etapas de método para reutilización de grafos. 

Para ilustrar la ejecución de este método de reutilización se describe la construcción del módulo del grafo de conocimiento Symptom. Una de las terminologías médicas importantes que fueron requeridas para construir el grafo de conocimiento general PatientElectronicRecord es el de los síntomas de las enfermedades. Los síntomas son cruciales para el diagnóstico certero de la enfermedad por COVID-19.

Seleccionar el grafo a reutilizar

Se seleccionó y descargó el grafo SYMPT⁹, el cual define un síntoma como: “un cambio percibido en la función, sensación o apariencia, el cual es informado por el paciente y que puede ser indicativo de una enfermedad”. Esta grafo considera la relación que existe entre el concepto de signo y síntoma, por lo que se incluyen también los signos y se considera que algún término pueda ser un signo o un síntoma. En la parte izquierda de la Figura 4 se muestran las métricas de la ontología SYMPT, la cual cuenta con un total de 6271 axiomas y 993 clases de los tipos de síntomas, y un total de 889 subclases. De igual forma, en la parte derecha se puede visualizar la clase SYMP:0000613 la cual se refiere al síntoma de “fever” o fiebre, que a su vez es una subclase de la clase SYMP_0000410 “neurological and psychological symptom”. Todas las clases en este grafo cuentan con anotaciones y propiedades que son útiles para conocer los detalles específicos cuando se selecciona la parte del modelo a exportar.

Fuente: Propia de los autores.

Figura 4 Visualización de la ontología SYMPT (con Protégé). 

Una de las transformaciones importantes que se implementaron durante este proceso de modularización fue el de utilizar las subclases de síntomas como instancias (o individuos) en el nuevo modelo. Con el propósito de contar con un modelo donde se tenga una jerarquía de las clases principales de síntomas, dentro de las cuales se incluyan todos los síntomas específicos como individuos y no como subclases, facilitando de esta manera establecer relaciones entre enfermedades y sus signos o síntomas.

Identificación de los datos y atributos relevantes

En esta etapa se realiza un análisis sobre la ontología SYMPT para identificar los conceptos, atributos (propiedades) y tipos de datos que se requieren para ser importados y reutilizados en el grafo de conocimiento general PatientElectronicRecord. Para facilitar la lectura por parte del analista, se recomienda guardar la ontología SYMPT utilizando la sintaxis Turtle¹⁰. Para muestra de los datos y atributos de esta ontología, en la parte de abajo se muestra un extracto de la categoría de síntomas neurológicos y psicológicos, específicamente el concepto de SYMP:0000613, que se corresponde con el síntoma de la fiebre.

### http://purl.obolibrary.org/obo/SYMP_0000613

obo:SYMP_0000613 rdf:type owl:Class ;

rdfs:subClassOf obo:SYMP_0000410 ;

obo:IAO_0000115 "Fever is a neurological and physiological symptom

characterized by a rise of body temperature above the normal whether a natural response (as to infection) or artificially induced for therapeutic reasons."^^xsd:string ;

oboInOwl:hasDbXref

"ICD9CM_2005:780.6"^^xsd:string ,

"UMLS_CUI:C0015967"^^xsd:string ,

"UMLS_ICD9CM_2005_AUI:A0058972"^^xsd:string ;

oboInOwl:hasExactSynonym "pyrexia"^^xsd:string ;

oboInOwl:hasOBONamespace "symptoms"^^xsd:string ;

oboInOwl:id "SYMP:0000613"^^xsd:string ;

rdfs:label "fever"^^xsd:string .

[ rdf:type owl:Axiom ;

owl:annotatedSource obo:SYMP_0000613 ;

owl:annotatedProperty obo:IAO_0000115 ;

owl:annotatedTarget "Fever is a neurological and physiological

symptom characterized by a rise of body temperature above the normal whether a natural response (as to infection) or artificially induced for therapeutic reasons."^^xsd:string ;

oboInOwl:hasDbXref "url:http://www2.merriam-webster.com/cgi-

bin/mwmednlm?book=Medical&va=fever"^^xsd:string ]

Las propiedades que existen en dicho grafo son: auto-generated-by, created_by, creation_date, database_cross_reference, date, default, namespace, deprecated, description, has_alternative_id, has_obo_format_version, has_obo_namespace, id, label, license, notation, part_of, saved-by, term replaced by title. De las cuales se incluyeron y adaptaron como propiedades de dato: hasSymptomDefinition, hasSymptomID, hasSymptomName, además de la IRI de la clase.

Definir e implementar las estructuras de datos

Para la extracción y representación de síntomas se desarrolló un programa en Java basado en la librería OWL API. Este programa consiste en las clases Symptom, SymptomOntologyCreation y OntologyUtils, tal como se muestra en el diagrama de clases de la Figura 5.

Fuente: Propia de los autores.

Figura 5 Diagrama de clases del programa que extrae los síntomas y los registra en el nuevo módulo. 

Implementar un programa para consultar la ontología SYMPT

Durante esta etapa, se implementaron un conjunto de métodos en la clase OntologyUtils mediante el uso de la API RDF4J, con la finalidad de ejecutar consultas en el lenguaje SPARQL, de tal forma que se automatice la extracción de la información de los síntomas y se genere la lista de objetos de los síntomas, y posteriormente guardar esta información en un nuevo grafo llamado Symptom.owl. La consulta en SPARQL que se empleó se muestra a continuación:

PREFIX obo: <http://purl.obolibrary.org/obo/>

PREFIX oboInOwl: <http://www.geneontology.org/formats/oboInOwl#>

SELECT ?s ?label ?id ?description

WHERE { ?s rdf:type owl:Class .

?s rdfs:subClassOf obo:SYMP_0000462 .

?s obo:IAO_0000115 ?description .

?s rdfs:label ?label .

?s oboInOwl:id ?id .}

Definir y construir el modelo del T-Box del módulo del grafo

Se diseñó el nuevo modelo en el cual se registran las instancias de síntomas, la definición de la clase Symptom se apega al tipo de dato manejado por el programa que extrae la lista de síntomas. En este nuevo modelo de grafo se simplifican las propiedades de datos, los conceptos de los síntomas que se encuentran registrados como clases y subclases en la ontología original se registran como instancias o individuos en el nuevo grafo, con la finalidad que dicho módulo sea más ligero y fácil de integrar en el grafo de conocimiento general PatientElectronicRecord.

Desarrollar un programa que genere automáticamente el módulo de grafo de conocimiento

Finalmente, en la clase OntologyUtils, se integraron los métodos para la extracción de información de síntomas a partir del grafo (getSymptomsList), y para la generación automática del módulo del grafo que será reutilizado (populateSymptomOntology). Estos métodos son ejecutados desde una aplicación principal (SymptomOntologyCreation) como se muestra en el siguiente código en Java:

public class SymptomOntologyCreation {

public static void main(String[] args) {

OntologyUtils util = new OntologyUtils();

//Extracción de la lista de síntomas a través de SPARQL

List<Symtom> symptomList = util.getSymptomsList();

//Registro de la lista de síntomas en el nuevo módulo del grafo

util.populateSymptomsOntology("Ontologies/Symptom.owl",

symptomList); }}

Como resultado de la implementación del método para la reutilización, se obtiene un nuevo módulo del grafo de conocimiento llamado Symptom.owl, este consta de 1 clase, 3 propiedades de datos, 259 individuos y un total de 1292 axiomas, tal como se muestra en la Figura 6.

Fuente: Propia de los autores.

Figura 6 Métricas del módulo del grafo Symptom. 

El método de reutilización descrito anteriormente (tal como se muestra en la Figura 3) se implementó para la extracción de módulos de los siguientes grafos: NDFRT, National Drug File - Reference Terminology; LOINC, Logical Observation Identifier Names and Codes; NCIT, National Cancer Institute Thesaurus. Como resultado se obtuvieron los siguientes grafos de conocimiento (GCs):

Etapa 6; integración de módulos en el grafo de conocimiento principal

Una vez finalizada la etapa de extracción, se realiza el proceso de integración importando los módulos en el grafo de conocimiento general PatientElectronicRecord; y definiendo meta-relaciones entre los conceptos de los grafos importados de acuerdo con los requerimientos del modelo general. Como resultado de esta integración se cuenta con un modelo general que permitirá más adelante representar casos de pacientes mexicanos.

La definición de meta-relaciones es una tarea importante para la integración de los conceptos externos, estas meta-relaciones se pueden definir mediante propiedades entre objetos o instancias de las clases. Es importante recordar que las propiedades entre objetos establecen relaciones binarias, es decir, por cada propiedad se debe definir el dominio y el rango. Durante la integración del grafo general PatientElectronicRecord se definieron los nombres de las propiedades, sus dominios y rangos que se muestran en la Tabla 5.

Para visualizar el modelo general integrado (ver Figura 7). De igual forma en la Figura 8, se muestra un fragmento del código del grafo de conocimiento general PatientElectronicRecord notación Manchester¹². En el encabezado se pueden observar los prefijos de los grafos importados seguido de las propiedades de anotaciones y las propiedades de datos, entre otras.

Fuente: Propia de los autores.

Figura 7 Grafo de conocimiento integrado PatientElectronicRecord. 

Fuente: Propia de los autores.

Figura 8 Fragmento de código del grafo de conocimiento general PatientElectronicRecord. 

Etapa 7; definición de axiomas generales y reglas de inferencia

Los grafos de conocimiento se implementan mediante la definición de axiomas lógicos, en un sentido estricto un axioma es una verdad inobjetable acerca de un concepto o un hecho. Vistos desde un enfoque práctico los axiomas son definiciones formales de los conceptos, es decir, son el conjunto de definiciones formales que restringen la pertenencia de los individuos a las clases. Un axioma lógico visto como una restricción establece las condiciones necesarias y/o suficientes para que un individuo sea miembro o pertenezca a una clase. Por lo anterior, la definición de axiomas permite implementar la caracterización fina y detallada de los conceptos. Durante esta etapa del desarrollo del grafo de conocimiento se procedió a definir los axiomas que integran el modelo, así como un conjunto de reglas de inferencia que permiten generar automáticamente nuevas relaciones semánticas y nuevas definiciones.

Evaluación de la usabilidad del grafo de conocimiento

La usabilidad de un grafo de conocimiento tiene como propósito medir la facilidad que tiene el usuario para aprovechar el modelo mediante la instanciación de datos del mundo real. Mediante la usabilidad se conoce que “tan adecuado” es el diseño de un modelo para representar casos del mundo real. En esta sección se presenta el método implementado para la representación de un conjunto de datos “reales” de pacientes COVID-19, tal como se muestra en la Figura 9. La DGE del gobierno de México pone a disposición de la población en general los datos referentes a los casos asociados a COVID-19, con el propósito de facilitar a todos los usuarios que requieran el acceso, uso, reutilización y redistribución de los mismos.

Fuente: Propia de los autores.

Figura 9 Método para la representación de datos de pacientes COVID-19 usando el grafo PatientElectronicRecord. 

Búsqueda de conjunto de datos

En la etapa de evaluación de la usabilidad del modelo se buscaron conjuntos de datos de pacientes COVID-19 públicos para instanciarlos el grafo general y evaluar su usabilidad de acuerdo con las necesidades planteadas inicialmente. Los datos que se utilizaron se obtuvieron de la Dirección General de Epidemiología (DGE).

Preparación de datos

Se descargó el archivo en formato CSV con los datos de pacientes. Este archivo cuenta con más de 7,000,000 de registros de pacientes atendidos en las Unidades de Salud Monitoras de Enfermedad Respiratoria viral (USMER). Con el propósito de realizar una prueba de la usabilidad del modelo, se utilizaron 500 registros, seleccionando aquellos de nacionalidad mexicana. Para llevar a cabo el registro se seleccionaron los atributos de los registros de pacientes que coinciden con los atributos definidos en el grafo general. El archivo de origen se muestra en la Figura 10.

Fuente: Propia de los autores.

Figura 10 Fragmento de conjunto de datos sin procesar. 

Finalmente, se guardaron los datos de pacientes en un archivo patients.xlsx, para procesarlos a través de un programa para la lectura y registro automático de datos.

Programa para la automatización de la lectura y registro de datos

Para realizar el poblado automático de los registros de pacientes en el grafo general, se desarrolló un programa para leer los registros de forma secuencial y transformarlos en una estructura de datos, la cual es posteriormente almacenada en el grafo de conocimiento. En la Figura 11 se puede observar el diagrama de clases de este programa Se desarrollaron métodos que realizan la lectura de los datos desde el archivo en Excel utilizando la API Apache POI¹³. También se desarrolló una aplicación principal a partir de la cual se ejecutan las operaciones.

Fuente: Propia de los autores.

Figura 11 Diagrama de clases para la lectura y registro de datos de pacientes en el grafo general. 

En la Figura 12 se muestra un ejemplo de un paciente registrado en el grafo PatientElectronicRecord. Se trata de una paciente mexicana con el identificador pat01e35a, tiene 56 años, género femenino, originaria de la Ciudad de México de la alcaldía Coyoacán, atendida en la Ciudad de México en el Instituto de Seguridad y Servicios Sociales de los Trabajadores del Estado (ISSSTE), la fecha de inicio de síntomas es el 08 de enero del 2020 y la fecha de registro del caso es el 09 de enero del 2020. Su registro refiere que no fue necesaria la intubación, ni la hospitalización en la USMER, aunque los antecedentes médicos establecen que el paciente tiene comorbilidades de diabetes mellitus y obesidad, las cuales representan un elevado riesgo de complicaciones. En su registro se estableció que la paciente debería ser tratada con los medicamentos indicados por el médico.

Fuente: Propia de los autores.

Figura 12 Ejemplo del resultado del registro de los datos de una paciente mexicana con COVID-19. 

Evaluación basada en principios de diseño

De acuerdo con Tom ^{Gruber (1995)} los principios de diseño son guías que orientan el diseño y construcción de modelos ontológicos. En esta sección se revisan los principios de diseño aplicados en la evaluación del grafo PatientElectronicRecord.

Se seleccionaron los principios de diseño propuestos por ^{Gómez-Pérez (1996)}, ^{Duque-Ramos (2014)}, tal como mencionan ^{Bravo et al. (2019)}, la construcción de ontologías abarca métodos, técnicas y principios de diseño que son el soporte de un diseño y construcción de ontologías eficientes, de esta manera los principios de diseño y métodos se consideraron en el desarrollo de este proyecto del modelo ontológico integrado.

Principios de diseño aplicados en la evaluación del grafo de conocimiento

Fuente: Propia de los autores.

Figura 13 Verificación de consistencia lógica con el razonador. 

Evaluación de la competencia del grafo

La competencia de un grafo de conocimiento puede definirse como el conjunto de preguntas que el grafo es capaz de responder de acuerdo con el conocimiento incluido. En esta sección se presenta el conjunto de preguntas de competencia en lenguaje natural, las cuales son traducidas al lenguaje de consulta SQWRL con la finalidad de ejecutar dichas consultas.

Por lo anterior, se plantearon las siguientes preguntas de competencia:

En la Figura 14 se presenta un ejemplo de la ejecución de una consulta, así como el tiempo de ejecución. El resultado se muestra en formato de tabla con todos los registros encontrados en el grafo. Como ejemplo se muestra la ejecución de la pregunta 3: What is the gender and age of the intubated patients? Traducida al lenguaje SQWRL de la siguiente forma:

patientelectronicrecord:hasGender(?patient, ?gender) ^ patientelectronicrecord:isIntubated(?patient, "YES") ^ patientelectronicrecord:hasAge(?patient, ?age) ^ patientelectronicrecord:Patient(?patient) -> sqwrl:select(?patient, "YES", ?gender, ?age)

Fuente: Propia de los autores.

Figura 14 Tiempo de ejecución y tabla de resultado de 3ra consulta.