Background Within the German “Network University Medicine,” a portal is to be developed to enable researchers to query on novel coronavirus disease 2019 (COVID-19) data from university hospitals for assessing the feasibility of a clinical study. Objectives The usability of a prototype for federated feasibility queries was evaluated to identify design strengths and weaknesses and derive improvement recommendations for further development. Methods In the course of a remote usability test with the thinking-aloud method and posttask interviews, 15 clinical researchers evaluated the usability of a prototype of the Feasibility Portal. The identified usability problems were rated according to severity, and improvement recommendations were derived. Results The design of the prototype was rated as simple, intuitive, and as usable with little effort. The usability test reported a total of 26 problems, 8 of these were rated as “critical.” Usability problems and revision recommendations focus primarily on improving the visual distinguishability of selected inclusion and exclusion criteria, enabling a flexible approach to criteria linking, and enhancing the free-text search. Conclusion Improvement proposals were developed for these user problems which will guide further development and the adaptation of the portal to user needs. This is an important prerequisite for correct and efficient use in everyday clinical work in the future. Results can provide developers of similar systems with a good starting point for interface conceptualizations. The methodological approach/the developed test guideline can serve as a template for similar evaluations.

Background An essential step in any medical research project after identifying the research question is to determine if there are sufficient patients available for a study and where to find them. Pursuing digital feasibility queries on available patient data registries has proven to be an excellent way of reusing existing real-world data sources. To support multicentric research, these feasibility queries should be designed and implemented to run across multiple sites and securely access local data. Working across hospitals usually involves working with different data formats and vocabularies. Recently, the Fast Healthcare Interoperability Resources (FHIR) standard was developed by Health Level Seven to address this concern and describe patient data in a standardized format. The Medical Informatics Initiative in Germany has committed to this standard and created data integration centers, which convert existing data into the FHIR format at each hospital. This partially solves the interoperability problem; however, a distributed feasibility query platform for the FHIR standard is still missing. Objective This study described the design and implementation of the components involved in creating a cross-hospital feasibility query platform for researchers based on FHIR resources. This effort was part of a large COVID-19 data exchange platform and was designed to be scalable for a broad range of patient data. Methods We analyzed and designed the abstract components necessary for a distributed feasibility query. This included a user interface for creating the query, backend with an ontology and terminology service, middleware for query distribution, and FHIR feasibility query execution service. Results We implemented the components described in the Methods section. The resulting solution was distributed to 33 German university hospitals. The functionality of the comprehensive network infrastructure was demonstrated using a test data set based on the German Corona Consensus Data Set. A performance test using specifically created synthetic data revealed the applicability of our solution to data sets containing millions of FHIR resources. The solution can be easily deployed across hospitals and supports feasibility queries, combining multiple inclusion and exclusion criteria using standard Health Level Seven query languages such as Clinical Quality Language and FHIR Search. Developing a platform based on multiple microservices allowed us to create an extendable platform and support multiple Health Level Seven query languages and middleware components to allow integration with future directions of the Medical Informatics Initiative. Conclusions We designed and implemented a feasibility platform for distributed feasibility queries, which works directly on FHIR-formatted data and distributed it across 33 university hospitals in Germany. We showed that developing a feasibility platform directly on the FHIR standard is feasible.

Clinical trials are carried out to prove the safety and effectiveness of new interventions and therapies. As diseases and their causes continue to become more specific, so do inclusion and exclusion criteria for trials. Patient recruitment has always been a challenge, but with medical progress, it becomes increasingly difficult to achieve the necessary number of cases. In Germany, the Medical Informatics Initiative is planning to use the central application and registration office to conduct feasibility analyses at an early stage and thus to identify suitable project partners. This approach aims to technically adapt/integrate the envisioned infrastructure in such a way that it can be used for trial case number estimation for the planning of multicenter clinical trials. We have developed a fully automated solution called APERITIF that can identify the number of eligible patients based on free-text eligibility criteria, taking into account the MII core data set and based on the FHIR standard. The evaluation showed a precision of 62.64 % for inclusion criteria and a precision of 66.45 % for exclusion criteria.

Background Biobanks ensure the long-term storage and accessibility of biospecimens and corresponding data sets. Thus, they form the foundation for many research projects which may contribute to improving medical care. With the establishment of the German Biobank Node and Alliance, expertise in biobanking is bundled and strengthened. An important component within this research infrastructure is the set-up of an information technology (IT) network for allowing feasibility requests across individual biobanks. Objective We aim to describe relevant aspects that have shaped the journey to interconnect biobanks, to enhance their visibility within the research-community, to harmonize data, and to enable feasibility searches to support access to available data and biosamples. Methods To achieve this task, we resorted to a wide variety of methods: we ran a requirement analysis, decided on the mode of operation for the federated team of IT-developers and on the development approach itself, took related national and international initiatives into account, and concluded with evaluations of the developed software artefacts and the operation of the entire chain of applications. Results We drew an IT framework including all heterogeneous data aspects derived from our requirement analysis and developed a comprehensive IT infrastructure. The successful implementation benefited from a smooth interaction of a federated IT team distributed across all participating sites that was even able to manage a major technology change mid-project. Authentication and project management services from associated partners could be integrated and the graphic user interface for an intuitive search tool for biospecimens was designed iteratively. The developed code is open source to ensure sustainability and the local implementation is concluded and functioning. The evaluation of the components was positive. Conclusions The entire project had given ample opportunity for challenges, predictable and unpredictable—from the mode of operation to changing some of the initial ideas. We learned our lessons concerning personnel, budget planning and technical as well as manual monitoring as well as some requirements arising only during the process of the project. Nevertheless, we can here report a success story of a network infrastructure, highly agile and much easier in local installation than initially anticipated.

Background The COVID-19 pandemic highlighted the importance of making research data from all German hospitals available to scientists to respond to current and future pandemics promptly. The heterogeneous data originating from proprietary systems at hospitals' sites must be harmonized and accessible. The German Corona Consensus Dataset (GECCO) specifies how data for COVID-19 patients will be standardized in Fast Healthcare Interoperability Resources (FHIR) profiles across German hospitals. However, given the complexity of the FHIR standard, the data harmonization is not sufficient to make the data accessible. A simplified visual representation is needed to reduce the technical burden, while allowing feasibility queries. Objective This study investigates how a search ontology can be automatically generated using FHIR profiles and a terminology server. Furthermore, it describes how this ontology can be used in a user interface (UI) and how a mapping and a terminology tree created together with the ontology can translate user input into FHIR queries. Methods We used the FHIR profiles from the GECCO data set combined with a terminology server to generate an ontology and the required mapping files for the translation. We analyzed the profiles and identified search criteria for the visual representation. In this process, we reduced the complex profiles to code value pairs for improved usability. We enriched our ontology with the necessary information to display it in a UI. We also developed an intermediate query language to transform the queries from the UI to federated FHIR requests. Separation of concerns resulted in discrepancies between the criteria used in the intermediate query format and the target query language. Therefore, a mapping was created to reintroduce all information relevant for creating the query in its target language. Further, we generated a tree representation of the ontology hierarchy, which allows resolving child concepts in the process. Results In the scope of this project, 82 (99%) of 83 elements defined in the GECCO profile were successfully implemented. We verified our solution based on an independently developed test patient. A discrepancy between the test data and the criteria was found in 6 cases due to different versions used to generate the test data and the UI profiles, the support for specific code systems, and the evaluation of postcoordinated Systematized Nomenclature of Medicine (SNOMED) codes. Our results highlight the need for governance mechanisms for version changes, concept mapping between values from different code systems encoding the same concept, and support for different unit dimensions. Conclusions We developed an automatic process to generate ontology and mapping files for FHIR-formatted data. Our tests found that this process works for most of our chosen FHIR profile criteria. The process established here works directly with FHIR profiles...