Personal Health Records’ relevance during Covid-19 pandemic in México
Abstract
Education about health prevention represents a challenge in which Mexico, due to its social, cultural, geographical, economical and political diversity, is historically behind. Although it is true that this situation must be confronted from many sides: education, culture, economy, work conditions, health services and professionals availability – among others – it is unquestionable that technology must play an important role in each one. The experience from other countries that already use electronic clinical records for its population can prove that they meet the health status of their people and allow the government to make decisions with a positive impact for them. The main objective of this work is to evaluate the reactions of the social actors (doctors and patients) in regards to Personal Health Records. In order to do this, an android-based HL7v3-compatible PHR was developed and compared against its paper equivalent. The COVID-19 pandemic context was added because during the test phase, the country experienced the first wave of contagion. This affects the number of tests but also proves the importance of these tools in critical situations. The results allow us to make inferences about the characteristics that these kinds of tools must have in order to be functional in the Mexican market.
RELEVANCIA DE LOS SISTEMAS PERSONALES DE SALUD DURANTE LA PANDEMIA DE COVID-19 EN MÉXICO
La educación en materia de prevención de salud representa un reto en el que México, debido a su diversidad social, cultural, geográfica, económica y política; tiene una deuda histórica. Si bien es cierto que esta situación debe enfrentarse desde varios flancos: educación, economía, condiciones de trabajo, disponibilidad de los servicios y profesionales de salud – entre muchos otros – es indudable que la tecnología debe jugar un papel importante en todos. La experiencia de otros países de establecer expedientes clínicos electrónicos universales permite comprobar que conocer el estado de salud de su población permite a los gobiernos tomar decisiones que impacten de manera positiva en la población. El objetivo de este estudio es evaluar la reacción de los actores sociales (pacientes y médicos) a un sistema personal de salud. Con este fin se desarrolló un Sistema Personal de Salud basado en Android y compatible con el estándar HL7 v3 y se comparó contra su equivalente en papel. Se agrega el contexto de la pandemia causada por el Covid-19 debido a que durante la fase de pruebas el país comenzó con la primera ola de contagios; lo que afectó de cierta forma el número de pruebas, pero a la vez demostró la importancia de estas herramientas en situaciones críticas. Los resultados permiten hacer inferencias importantes sobre las características que debe tener este tipo de herramientas para funcionar en el mercado mexicano.
Keywords
Personal health record, clinical record, HL7, covid19
Palabas clave:
Sistema personal de salud, Expediente clínico, HL7, COVID-19.
INTRODUCTION
A Personal Health Record (also known as a PHR for Personal Health Record) is a set of IT-based tools that allow individuals to aggregate and manage their health information over the course of their lifetime, with the ability to share pieces of this information if required. (Kaelber, Jha, Johnston, Middleton, & Bates, 2008). The apparently simple concept has been implemented, however, with some difficulty in the different countries where such tools exist (United States, Germany, Australia, etc.), as the legislation, requirements (technical, privacy and security, reliability and user adherence) and functionalities that must be considered represent challenges that must be met at different levels. In the Mexican context, the closest approach towards such a tool, although it cannot be fully called a PHR, came in 2018 when the Ministry of Health published RadarCISalud (Secretaría de Salud, 2018), as a quick search tool for location-based health services that includes among its features a basic clinical record.
Functional description of a PHR
According to the concept, a PHR should offer at least: a) a temporary record (logbook/journal) where the user dynamically records, with the desired periodicity, the health events he/she considers important, covering all areas of health; b) a permanent record (file) of health information that includes both variant data (height, weight, blood pressure, etc.) and time-invariant data (blood group, congenital conditions, etc.), obtained automatically or manually. And c) The ability to share the desired amount of information with the actors selected by the user in different formats (text, image, electronic records, etc.).
The AHIMA (AHIMA e-HIM Personal Health Record Work Group., 2005) established the characteristics that a PHR must fulfil and groups them into 5 aspects: functionality, format and content, privacy and access control, maintenance and security and interoperability. In the case that the PHR is interconnected to an Electronic Medical Record (EMR), it must be able to handle at least the information requested by the EMR, but there is no upper limit. In the context of Mexico, the lack of a universal Electronic Medical Record means that there is also no minimum information threshold for PHRs intended for general use. However, Leal and his team (Leal, Campos, Domínguez, & Sheissa, 2011) note, with respect to the Electronic Health Record, that the information must comply with the data set out in the Norma Oficial Mexicana del Expediente Clínico.
The evolution of the national clinical record
Article 4 of the Political Constitution of the United Mexican States guarantees the right to health and equality before the law for all Mexicans. (Political Constitution of the United Mexican States, 1917). Consequently, it is the obligation of the Mexican State to guarantee the functioning of the National Health System, figure 1 shows its current conformation.
Source : Own update based on (Dantés, Sesma, & Becerril, 2011)
Social security institutions that provide services to workers in the formal sector of the economy, together with the armed forces and their families, the oil sector and bureaucrats make up the public sector. (Dantés et al., 2011). In addition, there are other bodies in this same sector that focus on citizens who do not have social security, such as the Ministry of Health (SSA), INSABI, the State Health Services (SESA) and the IMSS-BIENESTAR programme (formerly IMSS-Oportunidades) that targets rural and indigenous communities that do not have social security (Instituto Mexicano del Seguro Social, 2019). Funding for this sector comes from the federal and state governments, although they may charge recovery fees for services provided.
The private sector is regularly used by the higher-income population. This is made up of clinics, hospitals, laboratories and private practices that are financed mainly by patient fees per event and external revenues that may come from private health insurance premiums and subcontracting of services between sectors. These services also include independent medical professionals.
Currently, the choice of which sectors to use for health care depends entirely on the patient: the lower income population is served in public institutions, which results in overcrowding and long waiting times. Higher income groups see the public sector as the option for emergency treatment or long-term degenerative diseases, but for general health events they opt to use the private sector. Finally, the higher-income population considers public institutions to be deficient and opts for private care in all cases. The contingency caused by the SARS-COV2 virus has been useful to demonstrate the benefits and areas of opportunity of both sectors; but it is evident that the degenerative diseases that are the leading causes of death of Mexicans place them in a situation of vulnerability compared to other countries (Navarro, 2020).
Private sector institutions have been spearheading the use and implementation of HIS (Health Information Systems) internally or acquired from specialised companies with adaptable generic HIS. Faced with the emergence of systems with varied characteristics in terms of format and content, the Ministry of Health was instructed to establish recommendations that would allow institutions to better choose the systems to be implemented through the characteristics that adhere to the Health Information Exchange Guide (GIIS) (Dirección General de Información en Salud, 2011). The regulatory framework of these recommendations covers the content, format and security of the information and is based on current legislation and several official norms established to standardise procedures related to the health of Mexicans, which are mandatory at the national level. Among these norms, the one that establishes the functional objectives and functionalities that the Electronic Health Record Systems products must observe to guarantee the interoperability, processing, interpretation, confidentiality, security, use of standards and information catalogues of electronic health records (Secretaría de Salud, 2012) stands out; it establishes the Secretaría de Salud, based on the applicable legal provisions, as the governing body of the regulations to which the Units that make up the National Health System must conform with regard to the Electronic Health Record Systems. This system must guarantee the integrity and reliability of clinical information, the confidentiality and identity of patients, as well as establish the relevant and adequate security mechanisms in order to prevent illicit or illegitimate use that could affect the legal sphere of the owner of the information; in addition to complying with the elements mentioned as required and suggested. The handling of the ECE must be carried out with discretion and confidentiality and the information contained therein may only be disclosed to the patient or to the person who has the legal power to decide for him/her and, where appropriate, to third parties by means of a competent judicial or administrative order. Although this regulation undoubtedly represents an advance that favours the establishment of a universal electronic health record (EHR), it is clear that the EHR is not yet the property of the patient and that the patient has unrestricted access to it.
The penetration of information and communication technologies in all areas of daily work has also been reflected in the management of health information. Currently, paper-based clinical records can only be found in public institutions and in areas where their advantage over electronic media is evident. However, private hospitals have shown that they are ahead in the implementation and management of Health Information Systems (HIS), which obliged the authorities to establish recommendations and regulations governing the content, format and security of health information under a nationally binding legal framework. The most important are the Health Information Exchange Guide (GIIS) (Dirección General de Información en Salud, 2011), the Official Mexican Standard NOM-024-SSA3-2012 (Secretaría de Salud, 2012) and the Information Exchange Guide for the exchange of clinical summaries in electronic format (Dirección General de Información en Salud, 2016), which establishes that the information exchange standard will be Health Level 7 version 3 (HL7 v3) and standardises the interoperability of the different SIRES (Electronic Health Record Information Systems). This guide also establishes the final template of the document with the associated values for Mexico; this allows inferring other required data as the clinical summary can be understood as an extract of the clinical record.
The Health Level 7 standard
According to HL7 International, Health Level 7 (HL7) is "an international standard for the exchange, integration, sharing and retrieval of electronic health information, including clinical practice, and the management, delivery and evaluation of health services" (International, 2019). It was proposed in 1987 and is currently used in 50 countries. It offers tools and frameworks that facilitate its use and integration into information systems free of charge and free to use.
Version 3 of the standard can be understood as an exchange of elements called messages, which are containers of subsections that depend on the type of message and the actors involved. The structured specification of information within a specific domain of interest is called an information model, which expresses the required classes of information and the properties of those classes, including attributes, relationships, constraints and states. (HL7 Organisation, 2019, p. 7)
According to the documentation of the standard, an information model is composed of the classes, their attributes and relationships, the data types of the attributes and the domain of the required vocabulary and state transition models. The information models provided by HL7v3 can be classified into three types that differ in the information contained, the scope and use of the information. These models are:
• RIM (Reference Information Model): It is a shared, coherent and abstract model that functions as the origin of all the data that make up the different messages used. It represents in an abstract form the wealth of content of the topics that can be shared through a HIS. The harmonisation of the model is done by the technical committees and the groups involved.
• DMIM (Domain Message Information Model): Contains copies of the classes, attributes and relationships to be used in a given domain (health area), which are obtained from the RIM. It functions as the initial model of the RMIMS to be used within a specific domain.
• RMIMS (Refined Message Information Model): represents a subset of a DMIM used to express the specific content, annotations and refinements of a message or set of messages.
The process of designing a PHR according to the standard does not require the mandatory use of the entire RIM, but only the delimitation of the work domain by means of a DMIM and, based on this, the construction of the RMIM according to the exchange of messages required.
This research evaluates the degree of acceptance of a PHR among the actors involved: patients and physicians. On the patients' side, the PHR evaluated offers the replacement of paper records, adding elements such as security, privacy and ease of sharing the stored information with the health professional they trust. On the other hand, it offers health professionals a tool that allows them to know the patient's complete history (if the PHR is properly fed). In addition, it aims to identify the causes that may interfere with the success of a PHR in the national context. The methodology used with both actors is presented in the following section.
METHODOLOGY
Prior to the development and testing of the PHR that is the subject of this research, two descriptive-exploratory studies were carried out. For the first, an online survey was used as an instrument, the categories of which were sociodemographic data, health habits and willingness to use a PHR in people over 18 years of age. For the second, the instrument used was interviews with doctors from different specialties. The categories considered in this instrument were the personal assessment of the PHRs and the characteristics that, from their speciality, they would consider essential for these tools to be considered functional.
It is important to mention that, due to the nature of the responses in both studies, the results are dependent on the sampling technique used. For the first study, a simple random probability sample was used, with the only restriction being the age of majority. For the second study, a non-probability convenience sample of doctors with different specialties who accepted the interview was used.
The first study showed that 56.3% of the respondents had visited a doctor in the last six months. However, 77.9% of the respondents answered that their visits to the doctor were every time they had a complaint, and only 15.7% had scheduled preventive visits, the results were similar to the question on the sector used. This survey also found that the majority of users, 86.4% of respondents, were interested in using a PHR on their mobile phone.
The second study found that 82% of respondents would use the application if it allowed them to generate the documentation required by supervisory authorities, although a large percentage, 70%, were also concerned about the degree of relevance of the data provided by patients. The wide variety of information required between the different branches of medicine was also noted. This made it necessary to define the limits of the app in its first version. This led to the implementation of two components: The personal medical logbook and the personal medical record. Table 1 shows the purpose of each component.
|
Personal medical log |
Personal medical record |
|
Statistics based on information stored by the user, e.g. graphs of blood pressure behaviour, blood sugar level, or analysis of reported conditions. |
Emergency medical information and multi-format contact. |
|
Through the use of validated knowledge bases, offer knowledge-based recommendations based on the analysis of stored data. |
Medical history: surgical interventions, medical appointments, completed and ongoing treatments. |
|
|
Immunisation history according to the user's age. |
Source: Own elaboration.
For the testing phase, it was proposed to work with different specialists to propose the use of the application to a group of patients selected by them. In addition, the application was offered to people unknown to the doctors to test whether the information received would allow them to make a health diagnosis. As it was considered privileged information, all those involved had to sign a consent form in order to be able to work with their information and have it reviewed by a doctor they did not trust. This phase consists of two stages: the first is a paper-based follow-up and the second includes a digital follow-up via an app.
Schematic model of the app is shown in figure 2
Database architecture
For the storage of information, a comparison was made between a relational DBMS and a NoSQL DBMS. Analysing their advantages and disadvantages, it was found that a relational DBMS is easy to implement on Android using existing options (SQLite, Room). SQLlite offers a Software Development Kit (SDK) ready to work with various development environments; which simplifies information retrieval. The main disadvantage of this model is that, due to the dispersion effect, tables will increase in storage requirements over time without an increase in relevant information.
On the other hand, noSQL DBMS models solve the storage requirement because their structures can only increase in size as information is added. Analysing different tools, Realm (Realm, 2019) was chosen. This is an open source NoSQL implementation that uses a par:value item approach organised in documents, similar to those used by MongoDB; it is object-oriented and includes a native query language. Additionally, it offers AES-256 encryption that provides data security and supports synchronous and asynchronous transactions.
Among the implementation considerations, the type of relationships that can be established between objects can lead to duplicity of values if the embedded reference mode is used, in this model, a related object is inside another object that contains it; this can be solved if a reference relationship is used, which allows the reuse of objects; however, with this reference model there may be performance problems as the query may require multiple transactions in order to obtain all the information of the related objects. In addition, it should be remembered that it is important to explicitly close transactions to the database as these are not closed automatically, which can lead to increased memory usage.
Because of Room's architecture, it is necessary to create classes that are directly Realm objects. The data they can contain includes values, documents, arrays and arrays of arrays. Each log entry was determined to be a separate object that will only be included in the record if the user determines it to be so; this helps to meet the requirement of information control. The physical limitation that a character string cannot exceed 16 Mb in size means that certain types of medical formats such as DICOMM or images must be handled as external elements to the database.
Integration of the standard
The ultimate goal of the app is the construction of the personal health record. In accordance with the HL7v3 standard, the record was considered as a message composed of other sub-messages of different types, operations and structure, but which use XML as a common language. The implementation proposed by HL7 for the exchange of information from PHR to PHR (International, 2011) was used, making the adjustments required by GIIS-A001-01-05 and NOM-024-SSA3-2012. The structure of the document is shown in figure 3.
Source: Own elaboration based on (International, 2011)
Based on the above, a clinical document contains two elements: a header and a structured body (structuredBody). The XML templates that define how the different sections are organised are structured according to the CDA2 standard and are distinguished by a templateId. The readability of the information by human and non-human actors is an essential requirement. Table 2 presents the required sections, the templateIDs and the content of the templateIDs.
|
Section |
TemplateId |
Content |
|
Advanced directives section |
2.16.840.1.113883.10.20.1.1 |
Patient indications and references. |
|
Alerts and allergies section |
2.16.840.1.113883.10.20.1.2 |
Known allergies. |
|
Encounters section |
2.16.840.1.113883.10.20.1.3 |
Medical visits. |
|
Family history section |
2.16.84.1.113883.10.20.1.4 |
Family history contained in an organiser structure. |
|
Immunization section |
2.16.840.1.113883.10.20.1.6 |
Vaccination history. |
|
Medication section |
2.16.840.1.113883.10.20.1.8 |
Medications consumed. Self-medications and homeopathies. |
|
Plan of care section |
2.16.840.1.113883.10.20.1.10 |
Current encounters, procedures, treatments or indications. |
|
Problems section |
2.16.840.1.113883.10.20.1.1 |
Problems encountered when creating the document. |
|
Procedures section |
2.16.840.1.113883.10.20.1.12 |
History of interventions or procedures. |
|
Results section |
2.16.840.1.113883.10.20.1.14 |
Laboratory results. |
|
Social history section |
2.16.840.1.113883.10.20.8.1.1 |
Personal and social information and risk habits |
|
Vital signs section |
2.16.840.1.113883.10.20.1.16 |
Measurements and vital signs. |
Source: (International, 2011)
Adaptations to the templates were necessary to make the XML document compliant with the NOM-004-SSA3-20 standard, so that, by meeting the requirements of a clinical record, this document would be useful for doctors and thus promote acceptance. It was also verified that the requirements of NOM-024-SSA3-2010, which regulates the interoperability of electronic clinical record systems, and GIIS-A001-01-05 were met, taking into consideration the differences that exist between clinical records and clinical summaries. Important adjustments include the inclusion of the OID (Object Identifier) for the CURP as it is a mandatory element in the national regulations; the same applies to age, which does not appear in the international standard, and the way of capturing addresses, for the latter the considerations of both standards were included.
The use of the XSD file format included in GIIS-A001-01-05 and marked as recommended was also considered for the deployment of XML in compatible browsers. Both XML and XSD files are shared in plain text, however, it is important to establish some information security strategies, which are described in the following section.
Information protection strategy
Due to the nature of the information, it is important to mention that all data requested are part of the data protected by applicable laws. These laws vary from country to country and in some cases even from state to state. The HL7 standard states that the information contained in the XML representation must contain information understandable to human and non-human actors, and does not establish any encryption element for its documents. For the application, a user and password system was established in a set of tables independent of the structure where the user data is stored. The database is protected with the 512-bit encryption offered by Realm, whose session is initiated only upon successful credential entry.
Although XML is not encrypted in any way, it is sent from the application to the e-mail address associated with the health professional, so all responsibility for the information lies with the person who generates it.
Results
To obtain the results, thirty people were grouped as follows: ten of them with chronic degenerative diseases under the supervision of the treating physician, so they already had a clinical record; ten of them who had commented that they considered themselves to be in good health and the rest considered themselves to be "unhealthy", but without medical follow-up. Each of them was assigned a number to maintain anonymity of information and signed a consent form to have their information reviewed by a physician and the intention to participate in the two phases of the assessment. A purposive sampling approach was used where the selection criteria were that participants could read and write for the first phase and that they had a smartphone for the second phase. The first stage lasted for one month during which people recorded their health events on a monthly paper diary form.
The pandemic and quarantine situation caused by the SARS-COV2 virus limited the number of people participating in the testing phase, as well as the health professionals involved. The ages of the selected persons ranged from 18 to 55 years. The minimum age was considered because minors cannot give consent to share their health information; the maximum age was considered because of the technological illiteracy that some participants might have for the second stage of the experiment. As for the medical professionals, the support of only one was obtained: Dr. Iván Agustín Mendoza Olguín, with a speciality in emergency medicine and professional speciality card 6249568.
The following indicators were obtained in the first phase of the study:
• Fully completed forms by age group.
• Reasons for not filling it out (through an open question).
• Quality of the information obtained as assessed by the health professional.
For analysis, 4 age groups were defined according to the range of values of this data and the formats were classified. The initial classification (healthy, unhealthy, degenerative) of each patient was not considered. According to graph 1, the highest incidence of incomplete forms was among participants aged 18-27 years. They mentioned as main causes of noncompletion the difficulty of filling out the form and the lack of important events to add to the form (although two people who did not fill out the form had a chronic degenerative condition). In contrast, people aged 48-55 years showed the lowest number of incomplete forms. The reasons given by non-completers were forgetfulness and excessive daily activities.
The completed forms were provided to the health professional, who evaluated them and provided feedback. The health professional classified the information received according to its usefulness for making a diagnosis: irrelevant or incomplete information, relevant but insufficient information, information from people who do not require medical attention, and information from people who require medical attention. This is intended as a qualitative assessment of the quality of the information provided by patients. The evaluation received is presented in graph 2.
To obtain the results of the second stage, an app was designed that allowed users to record family history, risk factors, allergies, personal notes, health encounters and measurements. It was installed on the volunteers' mobile phones and they were asked to use and feed it for the same period of time. At the end of the period, the XML obtained was sent to the doctor for assessment.
The results showed that younger people had fewer problems using the app and recording their events, while older adults had more problems, which was an expected result. However, the opinions of these people were the most valuable in terms of the usability of the app. The results obtained are shown in graph 3.
The health professional's assessment and opinions are presented in graph 4.
An increase in the accuracy of the assessments can be observed due to a greater amount of relevant information. Additionally, there was a reduction in the number of files with irrelevant information. In cases where an assessment could not be established, the reasons were a lack of information in some sections or a limited number of events reported. The use of open sections for the user increased the amount of irrelevant or incomplete information, e.g. too general a description of an ailment. The most relevant information was located in the records submitted by patients who had had a previous encounter with the doctor. An important case was the diagnosis of a condition by a person who had not had a previous encounter with the practitioner based on his notes alone.
The tool proved to be useful also for assessment and follow-up of people infected with COVID-19. The application provided the patient with a space to record and maintain the follow-ups requested by the professional and to send the information when requested. Although two-way communication is not implemented in this part of the development, it is a possibility offered by some products of this type. However, these require the information to be centralised and not distributed, which can be analysed as future work.
The advantages that the application offered to the actors are summarised in Table 3.
|
Patients |
Doctors |
|
The user is the owner of his or her health information, and is responsible for maintaining and sharing it with the professional of his or her choice. |
The doctor receives only the sections of the report that he or she requires in the case of follow-up or can receive all of the patient's historical information if required. |
|
The information shared complies with applicable national and international standards and guidelines. |
If the system is properly fed, the practitioner can take into account all the symptomatology and pharmacology involved in the history and not just rely on the patient's memory, which can result in a more accurate diagnosis. |
|
The system allows each section to be captured according to the user's needs. |
The doctor can obtain the evolution of each procedure in the time frame in which it is required. |
|
The patient can capture in the health log the events he/she considers important, from which new patterns can be obtained. |
The doctor can receive the PHR report prior to the patient's consultation, which speeds up visit times. |
|
The patient is empowered and committed as an actor in the maintenance and care of their health. |
The doctor can store the different versions of the reports received and use them as clinical records, as they contain all the mandatory information. |
Source: Own elaboration.
It is important to note that the purpose of this app is to improve doctor-patient communication and to involve patients in their healthcare; it is not intended to replace the doctor in his or her expert role. The purpose of the app is to make it easier for the professional to make a diagnosis in a more accurate and informed way, also offering a document that can serve as a clinical record. The efficiency of the paper version is undeniable, but it is known that it tends to be unwieldy, difficult to store and easily forgotten. Incorporating technology proved to engage young people more easily; and the need to consider recommendations for greater usability among the less technologically literate.
CONCLUSIONS AND FUTURE WORK
In Mexican society, mistrust of sharing personal information by any means reigns. This was evident in the course of this project as both actors were initially reluctant; participants were suspicious of how their health information would be handled and stored. In this sense, this distrust was minimised when they realised that they were the guardians of their own information. On the side of the doctors, two main causes of distrust towards the use of a PHR were identified: the first was the idea that the application was designed for the purpose of making medical diagnoses. On the other hand, there was the fact that they relied on information collected by their own patients and not by them.
In this sense, the pandemic situation that is still present in the world forced the inclusion of technology in all aspects of daily life and made doctors learn to rely on other ways to do their work. As the actors involved in the provision of health services set about the task of educating informed and engaged patients in the prevention and maintenance of optimal health, versus corrective and recuperative health, this will lead to a more robust National Health System, which will translate into an increase in the economic status of families and a reduction in chronic degenerative disease statistics and their associated costs. The goal of establishing a culture of prevention as the ideal behaviour for all Mexicans requires joint efforts by the government, education and health sectors, and equipping users with the right tools to do so.
User annotations are an element that is left out of the standards. This was an expected situation as the standards are designed from the point of view of exchange between professionals or service providers and therefore the user is not considered as one of the authors. To remedy this situation, the schema was adapted and an OID was requested from the corresponding authorities, without obtaining a satisfactory response. Therefore, during this stage we only worked with the modified schema.
The incorporation of technological tools such as wearables so that biometric measurements are automatically added to health events, as well as standardised tools and questionnaires that allow the detection of other risk factors such as obesity and heart disease, and the involvement of health institutions and health professionals are some of the future work for this research.
REFERENCES
AUTHOR CONTRIBUTIONS, FUNDING AND ACKNOWLEDGEMENTS
Authors ' contributions : Conceptualisation, Mendoza Olguín Gustavo Emilio and Pérez de Celis Herrero Concepción; methodology, Mendoza Olguín Gustavo Emilio, Pérez de Celis Herrero Concepción, Somodevilla García María Josefa and Mendoza Olguín Iván Agustín; software, Mendoza Olguín Gustavo Emilio; validation, Mendoza Olguín Iván Agustín, Pérez De Celis Herrero Concepción and Somodevilla García María Josefa; formal analysis, Mendoza Olguín Gustavo Emilio, Pérez De Celis Herrero Concepción and Somodevilla García María Josefa; research, Mendoza Olguín Gustavo Emilio; memories, Mendoza Olguín Gustavo Emilio; data curation, Mendoza Olguín Gustavo Emilio and Mendoza Olguín Iván Agustín; writing-preparation of the original draft, Mendoza Olguín Gustavo Emilio; writing-revision and editing, Mendoza Olguín Gustavo Emilio, Pérez de Celis Herrero Concepción, Somodevilla García María Josefa and Mendoza Olguín Iván Agustín; visualisation, Mendoza Olguín Gustavo Emilio, Pérez de Celis Herrero Concepción, Somodevilla García María Josefa and Mendoza Olguín Iván Agustín; supervision, Pérez de Celis Herrero Concepción and Somodevilla García María Josefa project management, Mendoza Olguín Gustavo Emilio. All authors have read and accepted the published version of the manuscript.