Mapping from openEHR to FHIR and OMOP CDM to support interoperability for infection control

mibe000221 10.3205/mibe000221 urn:nbn:de:0183-mibe0002216 Research Article Mapping from openEHR to FHIR and OMOP CDM to support interoperability for infection control Mapping von openEHR zu FHIR und OMOP CDM zur Unterstützung der Interoperabilität für die Infektionskontrolle Rinaldi Rinaldi Eugenia E

Charité – Universitätsmedizin, Charitéplatz 1, 10117 Berlin, GermanyCharité – Universitätsmedizin, Berlin, Germany

eugenia.rinaldi@charite.de author Thun Thun Sylvia S

Berlin Institute of Health at Charité – Universitätsmedizin Berlin, Germany Hochschule Niederrhein, Informations- und Kommunikationstechnologien im Gesundheitswesen, Krefeld, Germany

author German Medical Science GMS Publishing House

Düsseldorf

610 interoperability standard mapping data exchange infection control FHIR OMOP CDM openEHR Interoperabilität Standard Mapping Datenaustausch Infektionsschutz FHIR OMOP CDM openEHR 20210426 engl This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License. Dieser Artikel ist ein Open-Access-Artikel und steht unter den Lizenzbedingungen der Creative Commons Attribution 4.0 License (Namensnennung). 1860-9171 17 2 GMS Medizinische Informatik, Biometrie und Epidemiologie GMS Med Inform Biom Epidemiol FHIR - Fast Healthcare Interoperability Resources 07 Die Gesundheitsversorgung und die gesundheitlichen Ergebnisse für Patienten könnten erheblich verbessert werden, wenn die verschiedenen elektronischen Gesundheitssysteme medizinischer Einrichtungen interoperabel wären, das heißt, wenn sie ihre Daten sinnvoll austauschen und kombinieren könnten. Darüber hinaus werden Patienten mit der steigenden Verbreitung von Gesundheits-Apps zunehmend selbst zu aktiven Datenquellen. Diese wertvollen Informationen sollten nicht verloren gehen, sondern in einem offenen Plattformansatz, bei dem die Distanz zwischen Leistungserbringer und Patient verringert wird, mit den Patientendaten integriert werden. Die Charité Universitätsmedizin Berlin und das Berlin Institute of Health (BIH) sind Mitglieder von HiGHmed, einem deutschen Konsortium, in dem sich acht Universitätskliniken auf den institutsübergreifenden Datenaustausch durch neuartige medizinische Informatiklösungen verständigt haben. In diesem Beitrag beschreiben wir unseren Ansatz zur Verbesserung der Interoperabilität für den Anwendungsfall Infektionsschutz des HiGHmed-Konsortiums. Ausgehend vom openEHR- Standard führten wir ein syntaktisches Mapping zum empfohlenen Standard Fast Healthcare Interoperability Resources (FHIR) und zum Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) durch. FHIR ermöglicht einen schnellen Datenaustausch dank der diskreten Datenelemente, in denen Informationen organisiert sind; OMOP CDM bietet ein Datenmodell, das speziell für Analysen auf Populationsebene geeignet ist. Das Mapping ist unerlässlich, um festzustellen, welche Daten ihre korrespondierenden Elemente in einem anderen Datenmodell haben und somit ohne Informationsverlust in einen anderen Standard umgewandelt werden können. Wie erwartet konnten nicht alle openEHR- und FHIR-Informationen auf OMOP CDM abgebildet werden, da viele Daten auf Patientenebene für Analysen auf Populationsebene nicht notwendig sind. Insgesamt jedoch wurde das Mapping für den analysierten Datensatz ohne größere Probleme durchgeführt. Der Anwendungsfall kann daher voraussichtlich die Vorteile der ausgewählten Standards nutzen. Healthcare delivery and health outcomes of patients could significantly improve if the different electronic health systems of medical institutions were interoperable, that is if they could exchange and combine their data in a meaningful way. In addition, patients are increasingly becoming active sources of data with the growing use of health apps. This valuable information should not be lost, but rather be integrated with the patients’ data in an open platform approach where the distance between caregiver and patient is reduced. Charité Universitätsmedizin Berlin and Berlin Institute of Health (BIH) are members of HiGHmed, a German consortium where eight university hospitals have agreed to the cross-institutional data exchange through novel medical informatics solutions. In this paper, we describe our approach to improve interoperability for the use case Infection Control of the HiGHmed project. Starting from the openEHR standard, we performed a syntactic mapping to the recommended standard Fast Healthcare Interoperability Resources (FHIR) and to the Observational Medical Outcomes Partnership Common Data Model (OMOP CDM). FHIR enables fast exchange of data thanks to the discrete data elements into which information is organized, and OMOP CDM offers a data model specific for population-level analyses. Mapping is essential to identify which data have their correspondent elements in a different data model and can thus be converted into another standard without loss of information. As expected, not all openEHR and FHIR information could be mapped to OMOP CDM as many patient-level data are not important for population-level analysis. However, overall, mapping for the analyzed dataset was performed without major issues and we believe the use case will be able to exploit the advantages of the selected standards. IntroductionUnder the umbrella of the Medical Informatics (MI) Initiative (https://www.medizininformatik-initiative.de), the German Ministry of Education and Research has funded the HiGHmed consortium with the aim of enhancing the efficiency of clinical research and improve patient care through novel medical informatics solutions and cross-institutional data exchange . In particular, Charité and Berlin Institute of Health (BIH), together with seven other German universities that are members of HiGHmed, will be involved in the use case Infection Control whose primary aim is to merge all necessary pathogen-related data and information to establish a smart infection control system (SmICS).While infection surveillance is already in place in hospitals and at national scale, it frequently suffers from a lack of data standardization and, consequently, from limited data integration, and limited availability of relevant data . Research on multidrug-resistant organisms and their routes of transmission is based on analysis of information. The more information is available, the more precise analyses can be, and thus the more can clinical research benefit. For this reason, it is of extreme importance that hospitals and medical centers are enabled to combine and exchange their data.To merge information coming from the different medical institutions of the HiGHmed consortium, standards for interoperability need to be adopted. Information has to be structured according to a common information model, and standard terminologies systems need to be employed. This enables smooth exchange of information and meaningful analysis of data. Regardless of the local systems used to store patient information in hospitals, standards ensure a level of interoperability that all hospitals can interface with. openEHR and FHIR are the most robust and complete healthcare data persistence and exchange specifications that support full semantic interoperability . Both standards model the clinical and administrative data based on reusable patterns that describe the medical information. These patterns are called “Archetypes” in openEHR and “Resources” in FHIR. Archetypes are maximal data sets for a given single clinical concept and are expected to contain all the clinical information . Archetypes are designed to be used in “Templates” that define specific use cases. In FHIR, resources only contain the most commonly used clinical information but can be extended with new data fields to support specific requirements. The HiGHmed platform consists of an IHE XDS Affinity domain combined with an openEHR clinical repository. Consequently, also the information structure for SmICS will be based on openEHR. Archetypes and templates are accordingly being developed to model the infection control information. In comparison to FHIR resources, the extent and depth of information covered by archetypes brings a much higher level of complexity. The reason is that in openEHR, information is organized in a hierarchical structure where archetypes are processed together even when the target information is only in “child” Archetype. In FHIR, information is deconstructed into discrete data elements (resources) that can be processed individually; this approach makes it easier to transmit only the needed pieces of information without processing other unnecessary data. The tree-like structure of FHIR resources, with many recursive references, ensures a fast data exchange of independent resources. These features also make FHIR a particularly suitable standard to support the adoption of personal health record (PHR) model, with the patients’ health records under their own control through the use of health mobile apps . The government body of the Medical Informatics Initiative (MII) has recommended the use of the standard FHIR to all its participating consortia. As a MII consortium, HiGHmed needs to comply with its recommendations and thus be in the position to exchange data via FHIR with the other MII members. FHIR provides efficiency in information exchange, allowing access to granular patient health data along with cross references to other related information. As a consequence of the optimization for data exchange, the data format is not designed for storage and analysis like in traditional relational databases. In fact, FHIR resources are highly denormalized, with information grouped together, so that granular exchanges are fairly stand-alone . On the other hand, such structure, optimized for data exchange, can be challenging when it comes to its use for data analytics purposes. The nested structure of information in openEHR is also denormalized and not optimized for exploration and analysis of data.The OMOP common data model on the contrary offers optimized access to information for the sharing of health research data using relational databases . OMOP is adopted by the Observational Health Data Sciences and Informatics OHDSI, a worldwide non-profit research alliance that focuses on open-source solutions for medical big data analysis.Within MIRACUM, a consortium of the MI Initiative, a combination of OMOP CDM, FHIR and standardized vocabularies was used to develop a successful prototypical platform to perform statistical analysis and deploy resulting clinical decision models . For their analyses, most institutions are used to relational databases which do not use tree-like formats with nested information. Therefore, to explore the possibilities for research analysis for our use case, we have considered the use of OMOP CDM. Within the activities of the HiGHmed Interoperability Work Package, we have mapped archetypes to resources, and resources to OMOP tables. OMOP CDM facilitates research using data organization optimized for data analysis and predictive modeling. Moreover, OMOP provides a data model that uses standard terminology systems such as the Systematized Nomenclature of Medicine (SNOMED) and the Logical Observation Identifiers Names and Codes (LOINC) . The use of standard vocabularies is also supported by FHIR and openEHR, and is very important for achieving semantic interoperability. Finally, we performed an internal quality assessment of our work using the principles of mapping provided by the International Organization for Standardization (ISO) as reference . MethodsFor the use case “Infection Control”, the HiGHmed consortium members have agreed upon a minimal dataset. The dataset contains the most relevant information that should be exchanged among institutions concerning a case of infection. It contains a selection of administrative, movement and microbiology data of patients.The openEHR modelling group within the consortium has modelled the data using existing and new archetypes. Local modifications of international archetypes were required to adapt the archetypes to the health care culture and the definition of health-related concepts in Germany . Additionally, the microbiology-related archetypes were combined in an openEHR Microbiology Finding Template. The template was made available to the Berlin working group via the Clinical Knowledge Manager, the web platform for collaborative development, management and publishing of openEHR assets.Starting from the agreed infection control minimum data set and the selected microbiology archetypes, we decided to proceed by steps in order to map the information of the use case to FHIR resources.At first, we modelled the dataset in ART DECOR, an open-source tool and methodology that is commonly used to design and publish HL7 V3 templates of national (e.g. the Austrian electronic health record ELGA) and international EHR initiatives . ART DECOR was useful for understanding the data model, for structuring the information and organizing it in a hierarchical view and associate pertinent terminologies (Figure 1 ). Once we had a clear overview of the data structure, the dataset was mapped to the HL7 v2 messaging standard. HL7 v2 is the most widely implemented standard for healthcare for electronic data exchange in the clinical domain and it is currently used at Charité to exchange laboratory data . Every element of the dataset was mapped to HL7 v2 using the support of Caristix (http://caristix.com/), a free web tool that supports HL7 interfacing. The HL7 theoretical mapping was then reviewed in comparison to its application in a real environment like Charité. It was helpful to interact with colleagues from Charité’s communication server working group who were able to tell us how the HL7 v2 specifications had been implemented locally. They provided us with the information on how specific HL7 v2 segments were being received from the laboratory and used by the Charité Institute of Hygiene and Environmental Medicine. This step was important because it allowed us to have a close understanding of how information about laboratory findings is received and managed at Charité. HL7 v2 being a precursor of FHIR, this mapping activity was useful also to steer the information model in the desired direction. From HL7 v2 to FHIR v4 the mapping was supported by the FHIR specifications that provide starting points for consideration . All the openEHR and HL7 v2 items were matched with the resource elements using the information available on the FHIR website pages (https://www.hl7.org/fhir/resourcelist.html) that also offer mapping suggestions between HL7 v2 and FHIR. Mapping was performed between openEHR archetypes and FHIR resources down to the data entry level to facilitate seamless use of both standards. Table 1 shows an example of the mapping performed on the pathogenic organism data.Mapping from FHIR v4 to OMOP CDM v6 can be challenging because FHIR resources usually contain more information. We decided to ignore those elements that could not be mapped, mainly laboratory workflow details. However, almost all information concerning FHIR observation and specimen resources could be mapped to the elements of the OMOP tables Measurement, Observation and Specimen. For example, in FHIR all the laboratory test codes to investigate the microorganisms are defined in the element Observation. Code which can be mapped to the field Measurement_concept_id of the OMOP Measurement table. The code/id itself is provided by the selected terminology system, for example LOINC, which both standards support. Our OMOP mapping was based on the Data Access Framework (DAF) FHIR Implementation Guide which describes</PlainText></TextGroup> the cross mapping of the two standards (<Hyperlink href="https://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:mappings_between_ohdsi_cdm_and_fhir">https://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:mappings_between_ohdsi_cdm_and_fhir</Hyperlink>). Figure 2 <ImgLink imgNo="2" imgType="figure"/> shows the different mapping steps with the main tools used.</Pgraph><Pgraph>Based on the Technical Report ISO TR 12300, which establishes measures to assess the quality and utility of a map, we performed an internal assessment of the quality of our mapping. This assessment is generally applied to terminology resources, but most of the principles stated there can also apply to syntactic mapping. This task was performed internally using the instructions and assessment scores provided by the ISO Report.</Pgraph></TextBlock> <TextBlock linked="yes" name="Results"> <MainHeadline>Results</MainHeadline><Pgraph>For the use case infection control, we mapped the microbiology data from openEHR to FHIR. The data included information on the laboratory examination performed and the findings with pathogenic organisms and antibiogram details.</Pgraph><Pgraph>The openEHR archetypes </Pgraph><Pgraph><UnorderedList><ListItem level="1"><Mark2>COMPOSITION.report-result</Mark2>, </ListItem><ListItem level="1"><Mark2>OBSERVATION.laboratory_test_ result</Mark2>, </ListItem><ListItem level="1"><Mark2>CLUSTER.specimen</Mark2>, </ListItem><ListItem level="1"><Mark2>CLUSTER.anatomical_location</Mark2>, </ListItem><ListItem level="1"><Mark2>CLUSTER.laboratory_test_analyte</Mark2>, </ListItem><ListItem level="1"><Mark2>CLUSTER.erregerdetails</Mark2> </ListItem></UnorderedList></Pgraph><Pgraph>were mapped to the FHIR resources </Pgraph><Pgraph><UnorderedList><ListItem level="1"><Mark2>ServiceRequest</Mark2>, </ListItem><ListItem level="1"><Mark2>Observation</Mark2>, </ListItem><ListItem level="1"><Mark2>Specimen</Mark2>, </ListItem><ListItem level="1"><Mark2>DiagnosticReport</Mark2> </ListItem></UnorderedList></Pgraph><Pgraph>(Figure 3 <ImgLink imgNo="3" imgType="figure"/>).</Pgraph><Pgraph>In particular, openEHR archetypes related to the laboratory results were mapped to the FHIR resource <Mark2>Observation</Mark2>. The archetypes concerning the specimen and the anatomical location were mapped to the FHIR resource <Mark2>Specimen</Mark2>. </Pgraph><Pgraph>As stated before, the archetypes are maximal data sets covering all aspects of a clinical concept. FHIR offers a minimum data set which could be extended to include more information in case of need. However, for the dataset analyzed, extensions were not necessary, the correspondence of elements between openEHR archetypes and FHIR resources for the microbiology data analyzed had a coverage of 100%. This was a very important result as inconsistencies between the models could pose a significant challenge for data interoperability <TextLink reference="15"></TextLink>. </Pgraph><Pgraph>Table 2 <ImgLink imgNo="2" imgType="table"/> shows our own evaluation of the mapping performed according to the criteria of map quality included in the technical report ISO TR 12300. The first column of Table 2 <ImgLink imgNo="2" imgType="table"/> shows the determinants of the map quality included in the ISO report; the second and the third columns show which score we assigned for each category to our mappings, openEHR to FHIR and FHIR to OMOP, respectively. The third column is shown as reference: it represents the suggested quality level for a clinical use case according to the ISO report. The numerical scale is from 0 to 4, where 0 represents the perfect match or the highest score. The ISO report offers instructions on how to assign the score in each category. The determinants cover different aspects of the process of mapping, also including some organizational ones. “Equivalence assessment” is a particularly relevant parameter for our purpose as it represents a measure of the actual match between the mapped elements in two different standards. We assigned the value 0 to the mapping openEHR-FHIR where we had perfect correspondence. We assigned a value of 0.9 to the mapping FHIR-openEHR as this was the average that resulted after scoring the equivalence to every single data element. Concerning the OMOP mapping, a good match (rated 2 and better) with FHIR resource elements was found for about 78% of the microbiology data set analyzed. The FHIR <Mark2>Specimen</Mark2> resource could be mapped to the OMOP table <Mark2>Specimen</Mark2>, and via the table <Mark2>Fact_Relationship</Mark2> to other tables, while the <Mark2>Observation</Mark2> resource could be mapped to the tables <Mark2>Measurement</Mark2> and <Mark2>Observation</Mark2>. All commentary fields are in OMOP stored in a separate <Mark2>Note</Mark2> table. <Mark2>DiagnosticReport</Mark2> and <Mark2>ServiceRequest</Mark2> elements which contain laboratory report and more organizational information did not have an actual correspondence in OMOP. This was expected, as OMOP focuses on research and population level analysis and is not designed to describe laboratory workflow details. </Pgraph><Pgraph>Lower scores, such as “method of validation” or “decision making documentation” that were both rated ‘2’, indicate that the map would benefit from having more people validating its content and from well documenting all the decisions and rules involved in the mapping process.</Pgraph><Pgraph>Overall, the mapping of the analyzed dataset from openEHR to FHIR and OMOP was satisfactory to pursue syntactic interoperability while supporting efficient health data exchange and research capabilities.</Pgraph><Pgraph>The full map between openEHR, FHIR and OMOP CDM elements can be found in Attachment 1 <AttachmentLink attachmentNo="1"/> together with the assigned equivalence scores for each data element. The map offers several points of consideration for other working groups intending to use FHIR and OMOP CDM starting from openEHR or HL7v2. It is however important to remark that different contexts, specific implementations or other standard versions can greatly influence the results of the mapping.</Pgraph></TextBlock> <TextBlock linked="yes" name="Discussion"> <MainHeadline>Discussion</MainHeadline><Pgraph>For the use case “Infection Control” of the HiGHmed project, the syntactic mapping of the data between the standards openEHR, FHIR and OMOP proved to be feasible without particular issues. All the above standards support the use of standard terminologies to also enable semantic interoperability. Our use case can thus benefit from fast data exchange without data loss and still enjoy adequate analysis capabilities. However, the dataset analyzed was limited to the microbiology data of the use case, and there might be new challenges should we consider bigger datasets. When mapping to FHIR, it is always possible to create profiles or extensions to best fit the requirements. In the case of OMOP, data which is not included in the data model is lost or has to be managed separately. This also reflects the focus of the two standards. FHIR concentrates on the patient level and on the simplicity of the queries to fetch specific data, OMOP focuses on the population level and therefore its CDM does not include all the information available in FHIR. In the quality map assessment, this gap finds evidence in the equivalence score “0.9” as opposed to “0” of the openEHR-FHIR mapping and in the percentage of outlier values (element<TextGroup><PlainText>s with</PlainText></TextGroup> equivalence rated 3 and 4). The assessmen<TextGroup><PlainText>t of</PlainText></TextGroup> the quality of the map helps to understand mapping weaknesses and also where it can possibly be improved; however, despite the scoring instructions, it remains a subjective assessment. There are increasing efforts to cross-reference standards and also to try to make the mapping process automatic. LinkEHR (<Hyperlink href="https://linkehr.veratech.es/">https://linkehr.veratech.es/</Hyperlink>) for example, is described as a tool with the functionality to transform openEHR archetypes to FHIR R4 Observation resources; however, not enough literature is available yet to prove its validity. Also within the consortium MIRACUM, a mapping converter tool has been developed to transform FHIR to OMOP. However, relying completely on automatic tools is not advisable and further reviewing is always recommended. Such tools are also usually bound to specific versions and might become obsolete as standards evolve. Additionally, the diversity of implementation of standards in different contexts or in different institutions remains indeed a big challenge when mapping. Our “handcrafted” approach was focused on a deep understanding of the standards, their elements and their general main purposes.</Pgraph></TextBlock> <TextBlock linked="yes" name="Notes"> <MainHeadline>Notes</MainHeadline><SubHeadline>Competing interests</SubHeadline><Pgraph>The authors declare that they have no competing interests.</Pgraph></TextBlock> <References linked="yes"> <Reference refNo="1"> <RefAuthor>Medical Informatics Initiative Germany</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>HiGHmed Consortium</RefBookTitle> <RefPage></RefPage> <RefTotal>Medical Informatics Initiative Germany. HiGHmed Consortium. [last accessed 2019 Nov 15]. Available from: https://www.medizininformatik-initiative.de/en/konsortien/highmed</RefTotal> <RefLink>https://www.medizininformatik-initiative.de/en/konsortien/highmed</RefLink> </Reference> <Reference refNo="2"> <RefAuthor>Haarbrandt B</RefAuthor> <RefAuthor>Schreiweis B</RefAuthor> <RefAuthor>Rey S</RefAuthor> <RefAuthor>Sax U</RefAuthor> <RefAuthor>Scheithauer S</RefAuthor> <RefAuthor>Rienhoff O</RefAuthor> <RefAuthor>Knaup-Gregori P</RefAuthor> <RefAuthor>Bavendiek U</RefAuthor> <RefAuthor>Dieterich C</RefAuthor> <RefAuthor>Brors B</RefAuthor> <RefAuthor>Kraus I</RefAuthor> <RefAuthor>Thoms CM</RefAuthor> <RefAuthor>Jäger D</RefAuthor> <RefAuthor>Ellenrieder V</RefAuthor> <RefAuthor>Bergh B</RefAuthor> <RefAuthor>Yahyapour R</RefAuthor> <RefAuthor>Eils R</RefAuthor> <RefAuthor>Consortium H</RefAuthor> <RefAuthor>Marschollek M</RefAuthor> <RefTitle>HiGHmed – An Open Platform Approach to Enhance Care and Research across Institutional Boundaries</RefTitle> <RefYear>2018</RefYear> <RefJournal>Methods Inf Med</RefJournal> <RefPage>e66-e81</RefPage> <RefTotal>Haarbrandt B, Schreiweis B, Rey S, Sax U, Scheithauer S, Rienhoff O, Knaup-Gregori P, Bavendiek U, Dieterich C, Brors B, Kraus I, Thoms CM, Jäger D, Ellenrieder V, Bergh B, Yahyapour R, Eils R, Consortium H, Marschollek M. HiGHmed – An Open Platform Approach to Enhance Care and Research across Institutional Boundaries. Methods Inf Med. 2018 Jul;57(S 01):e66-e81. DOI: 10.3414/ME18-02-0002</RefTotal> <RefLink>https://doi.org/10.3414/ME18-02-0002</RefLink> </Reference> <Reference refNo="3"> <RefAuthor>Allwell-Brown E</RefAuthor> <RefTitle></RefTitle> <RefYear>2016</RefYear> <RefBookTitle>A Comparative Analysis of HL7 FHIR and openEHR for Electronic Aggregation, Exchange and Reuse of Patient Data in Acute Care</RefBookTitle> <RefPage></RefPage> <RefTotal>Allwell-Brown E. A Comparative Analysis of HL7 FHIR and openEHR for Electronic Aggregation, Exchange and Reuse of Patient Data in Acute Care. [last accessed 2019 Nov 15]. Stockholm: Karolinska Institutet, Stockholm University; 2016. Available from: https://ki.se/sites/default/files/migrate/eneimi_allwell_brown_a_comparative.pdf</RefTotal> <RefLink>https://ki.se/sites/default/files/migrate/eneimi_allwell_brown_a_comparative.pdf</RefLink> </Reference> <Reference refNo="4"> <RefAuthor>Bosca D</RefAuthor> <RefAuthor>Moner D</RefAuthor> <RefAuthor>Maldonado JA</RefAuthor> <RefAuthor>Robles M</RefAuthor> <RefTitle>Combining Archetypes with Fast Health Interoperability Resources in Future-proof Health Information Systems</RefTitle> <RefYear>2015</RefYear> <RefJournal>Stud Health Technol Inform</RefJournal> <RefPage>180-4</RefPage> <RefTotal>Bosca D, Moner D, Maldonado JA, Robles M. Combining Archetypes with Fast Health Interoperability Resources in Future-proof Health Information Systems. Stud Health Technol Inform. 2015;210:180-4.</RefTotal> </Reference> <Reference refNo="5"> <RefAuthor>Roehrs A</RefAuthor> <RefAuthor>da Costa CA</RefAuthor> <RefAuthor>Righi RDR</RefAuthor> <RefAuthor>Rigo SJ</RefAuthor> <RefAuthor>Wichman MH</RefAuthor> <RefTitle>Toward a Model for Personal Health Record Interoperability</RefTitle> <RefYear>2019</RefYear> <RefJournal>IEEE J Biomed Health Inform</RefJournal> <RefPage>867-73</RefPage> <RefTotal>Roehrs A, da Costa CA, Righi RDR, Rigo SJ, Wichman MH. Toward a Model for Personal Health Record Interoperability. IEEE J Biomed Health Inform. 2019 Mar;23(2):867-73. DOI: 10.1109/JBHI.2018.2836138</RefTotal> <RefLink>https://doi.org/10.1109/JBHI.2018.2836138</RefLink> </Reference> <Reference refNo="6"> <RefAuthor>Anonym</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>HL7 FHIR Release 4. Persistent Storage</RefBookTitle> <RefPage></RefPage> <RefTotal>HL7 FHIR Release 4. Persistent Storage. [last accessed 2019 Nov 28]. Available from: https://www.hl7.org/fhir/storage.html</RefTotal> <RefLink>https://www.hl7.org/fhir/storage.html</RefLink> </Reference> <Reference refNo="7"> <RefAuthor>Choi M</RefAuthor> <RefAuthor>Starr R</RefAuthor> <RefAuthor>Braunstein M</RefAuthor> <RefAuthor>Duke J</RefAuthor> <RefTitle>OHDSI on FHIR Platform Development with OMOP CDM mapping to FHIR Resources [Poster]</RefTitle> <RefYear></RefYear> <RefBookTitle>2016 OHDSI Symposium; 2016 Sep 23-24; Washington D.C., USA</RefBookTitle> <RefPage></RefPage> <RefTotal>Choi M, Starr R, Braunstein M, Duke J. OHDSI on FHIR Platform Development with OMOP CDM mapping to FHIR Resources [Poster]. In: 2016 OHDSI Symposium; 2016 Sep 23-24; Washington D.C., USA.</RefTotal> </Reference> <Reference refNo="8"> <RefAuthor>Gruendner J</RefAuthor> <RefAuthor>Schwachhofer T</RefAuthor> <RefAuthor>Sippl P</RefAuthor> <RefAuthor>Wolf N</RefAuthor> <RefAuthor>Erpenbeck M</RefAuthor> <RefAuthor>Gulden C</RefAuthor> <RefAuthor>Kapsner LA</RefAuthor> <RefAuthor>Zierk J</RefAuthor> <RefAuthor>Mate S</RefAuthor> <RefAuthor>Stürzl M</RefAuthor> <RefAuthor>Croner R</RefAuthor> <RefAuthor>Prokosch HU</RefAuthor> <RefAuthor>Toddenroth D</RefAuthor> <RefTitle>KETOS: Clinical decision support and machine learning as a service – A training and deployment platform based on Docker, OMOP-CDM, and FHIR Web Services</RefTitle> <RefYear>2019</RefYear> <RefJournal>PLoS One</RefJournal> <RefPage>e0223010</RefPage> <RefTotal>Gruendner J, Schwachhofer T, Sippl P, Wolf N, Erpenbeck M, Gulden C, Kapsner LA, Zierk J, Mate S, Stürzl M, Croner R, Prokosch HU, Toddenroth D. KETOS: Clinical decision support and machine learning as a service – A training and deployment platform based on Docker, OMOP-CDM, and FHIR Web Services. PLoS One. 2019;14(10):e0223010. DOI: 10.1371/journal.pone.0223010</RefTotal> <RefLink>https://doi.org/10.1371/journal.pone.0223010</RefLink> </Reference> <Reference refNo="9"> <RefAuthor>Khalilia M</RefAuthor> <RefAuthor>Choi M</RefAuthor> <RefAuthor>Henderson A</RefAuthor> <RefAuthor>Iyengar S</RefAuthor> <RefAuthor>Braunstein M</RefAuthor> <RefAuthor>Sun J</RefAuthor> <RefTitle>Clinical Predictive Modeling Development and Deployment through FHIR Web Services</RefTitle> <RefYear>2015</RefYear> <RefJournal>AMIA Annu Symp Proc</RefJournal> <RefPage>717-26</RefPage> <RefTotal>Khalilia M, Choi M, Henderson A, Iyengar S, Braunstein M, Sun J. Clinical Predictive Modeling Development and Deployment through FHIR Web Services. AMIA Annu Symp Proc. 2015;2015:717-26.</RefTotal> </Reference> <Reference refNo="10"> <RefAuthor>Anonym</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>ISO/TR 12300:2014(en), Health informatics - Principles of mapping between terminological systems</RefBookTitle> <RefPage></RefPage> <RefTotal>ISO/TR 12300:2014(en), Health informatics - Principles of mapping between terminological systems. [last accessed 2020 Apr 7]. Available from: https://www.iso.org/obp/ui/#iso:std:iso:tr:12300:ed-1:v1:en</RefTotal> <RefLink>https://www.iso.org/obp/ui/#iso:std:iso:tr:12300:ed-1:v1:en</RefLink> </Reference> <Reference refNo="11"> <RefAuthor>Wulff A</RefAuthor> <RefAuthor>Sommer KK</RefAuthor> <RefAuthor>Ballout S</RefAuthor> <RefAuthor> HiGHmed ConsortiumHaarbrandt B</RefAuthor> <RefAuthor>Gietzelt M</RefAuthor> <RefTitle>A Report on Archetype Modelling in a Nationwide Data Infrastructure Project</RefTitle> <RefYear>2019</RefYear> <RefJournal>Stud Health Technol Inform</RefJournal> <RefPage>146-50</RefPage> <RefTotal>Wulff A, Sommer KK, Ballout S; HiGHmed ConsortiumHaarbrandt B, Gietzelt M. A Report on Archetype Modelling in a Nationwide Data Infrastructure Project. Stud Health Technol Inform. 2019;258:146-50.</RefTotal> </Reference> <Reference refNo="12"> <RefAuthor>Ott S</RefAuthor> <RefAuthor>Rinner C</RefAuthor> <RefAuthor>Duftschmid G</RefAuthor> <RefTitle>Expressing Patient Selection Criteria Based on HL7 V3 Templates Within the Open-Source Tool ART-DECOR</RefTitle> <RefYear>2019</RefYear> <RefJournal>Stud Health Technol Inform</RefJournal> <RefPage>226-33</RefPage> <RefTotal>Ott S, Rinner C, Duftschmid G. Expressing Patient Selection Criteria Based on HL7 V3 Templates Within the Open-Source Tool ART-DECOR. Stud Health Technol Inform. 2019;260:226-33.</RefTotal> </Reference> <Reference refNo="13"> <RefAuthor>HL7 International</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Product Brief</RefBookTitle> <RefPage></RefPage> <RefTotal>HL7 International. Product Brief. [last accessed 2019 Nov 18]. Available from: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185</RefTotal> <RefLink>https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185</RefLink> </Reference> <Reference refNo="14"> <RefAuthor>Anonym</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>HL7 FHIR Release 5 Preview #3. v2 Messaging</RefBookTitle> <RefPage></RefPage> <RefTotal>HL7 FHIR Release 5 Preview #3. v2 Messaging. [last accessed 2019 Nov 28]. Available from: https://build.fhir.org/comparison-v2.html</RefTotal> <RefLink>https://build.fhir.org/comparison-v2.html</RefLink> </Reference> <Reference refNo="15"> <RefAuthor>Topaz M</RefAuthor> <RefAuthor>Seger DL</RefAuthor> <RefAuthor>Goss F</RefAuthor> <RefAuthor>Lai K</RefAuthor> <RefAuthor>Slight SP</RefAuthor> <RefAuthor>Lau JJ</RefAuthor> <RefAuthor>Nandigam H</RefAuthor> <RefAuthor>Zhou L</RefAuthor> <RefTitle>Standard Information Models for Representing Adverse Sensitivity Information in Clinical Documents</RefTitle> <RefYear>2016</RefYear> <RefJournal>Methods Inf Med</RefJournal> <RefPage>151-7</RefPage> <RefTotal>Topaz M, Seger DL, Goss F, Lai K, Slight SP, Lau JJ, Nandigam H, Zhou L. Standard Information Models for Representing Adverse Sensitivity Information in Clinical Documents. Methods Inf Med. 2016;55(2):151-7. DOI: 10.3414/ME15-01-0081</RefTotal> <RefLink>https://doi.org/10.3414/ME15-01-0081</RefLink> </Reference> </References> <Media> <Tables> <Table format="png"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Table 1: Mapping example between Archetype and Resource elements</Mark1></Pgraph></Caption> </Table> <Table format="png"> <MediaNo>2</MediaNo> <MediaID>2</MediaID> <Caption><Pgraph><Mark1>Table 2: Map quality assesment</Mark1></Pgraph></Caption> </Table> <NoOfTables>2</NoOfTables> </Tables> <Figures> <Figure format="png" height="595" width="1522"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Figure 1: Art decor screenshot</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="349" width="199"> <MediaNo>2</MediaNo> <MediaID>2</MediaID> <Caption><Pgraph> <Mark1>Figure 2: Mapping steps and main tools</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="488" width="893"> <MediaNo>3</MediaNo> <MediaID>3</MediaID> <Caption><Pgraph><Mark1>Figure 3: openEHR-FHIR-OMOP mapping</Mark1></Pgraph></Caption> </Figure> <NoOfPictures>3</NoOfPictures> </Figures> <InlineFigures> <NoOfPictures>0</NoOfPictures> </InlineFigures> <Attachments> <Attachment> <MediaNo>1</MediaNo> <MediaID filename="mibe000221.a1.pdf" mimeType="application/pdf" origFilename="Attachment1_mibe000221.pdf" size="223871" url="">1</MediaID> <AttachmentTitle>Map between openEHR, FHIR and OMOP CDM elements</AttachmentTitle> </Attachment> <NoOfAttachments>1</NoOfAttachments> </Attachments> </Media> </OrigData> </GmsArticle>