Designing and Implementing an IT Architecture for a Digital Multicenter Dementia Registry: digiDEM Bayern

Abstract

Background  Registries are an essential research tool to investigate the long-term course of diseases and their impact on the affected. The project digiDEM Bayern will set up a prospective dementia registry to collect long-term data of people with dementia and their caregivers in Bavaria (Germany) supported by more than 300 research partners.

Objective  The objective of this article is to outline an information technology (IT) architecture for the integration of a registry and comprehensive participant management in a dementia study. Measures to ensure high data quality, study governance, along with data privacy, and security are to be included in the architecture.

Methods  The architecture was developed based on an iterative, stakeholder-oriented process. The development was inspired by the Twin Peaks Model that focuses on the codevelopment of requirements and architecture. We gradually moved from a general to a detailed understanding of both the requirements and design through a series of iterations. The experience learned from the pilot phase was integrated into a further iterative process of continuous improvement of the architecture.

Results  The infrastructure provides a standardized workflow to support the electronic data collection and trace each participant's study process. Therefore, the implementation consists of three systems: (1) electronic data capture system for Web-based or offline app-based data collection; (2) participant management system for the administration of the identity data of participants and research partners as well as of the overall study governance process; and (3) videoconferencing software for conducting interviews online. First experiences in the pilot phase have proven the feasibility of the framework.

Conclusion  This article outlines an IT architecture to integrate a registry and participant management in a dementia research project. The framework was discussed and developed with the involvement of numerous stakeholders. Due to its adaptability of used software systems, a transfer to other projects should be easily possible.

Background and Significance

With the rapid digitalization of health care, digital patient registries play an evolving role in health care and are increasingly implemented in research infrastructures. 1 2 3 4 Registries that record information or data from patients with defined, chronic diseases—such as dementia—can provide essential epidemiological data. 5 Despite the increasing burden on the health care system with currently approximately 50 million people suffering from dementia worldwide, 6 1.6 million of whom live in Germany, 7 respectively 240,000 in federal-state Bavaria, 8 only a modest number of dementia-related registries exists. The overview of Krysinska et al 9 provides a recent status of both completed and ongoing dementia registries worldwide. The Krysinska et al study identified a total of 31 dementia registries, but digital tools are not yet widely used to establish dementia registries. 9 Thus, there exists no study in the literature of how an architecture for a digital prospective, multicenter dementia registry can be realized.

To address the significant challenges in research, care, and policy, the Bavarian State Ministry of Health and Care in Germany has initiated the “Digital Dementia Registry Bavaria – digiDEM Bayern.” 10 One primary purpose of digiDEM is to establish a digital registry of data from people with mild cognitive impairment and mild-to-moderate dementia (PWD) and their family caregivers. digiDEM will collect data on the dementia care situation in all seven administrative districts of Bavaria over a period of 3 years to understand the long-term course of dementia, the care situation in rural and urban areas, and the needs of PWD and their caregivers. 10 These data findings are essential for the future development and optimization of national and regional structures in dementia care.

Such a registry study's success depends, among others, on two key factors: The recruitment of the defined number of participants 11 and their subsequent binding to the study. 12 The decreasing cognitive abilities and health of PWD during the study lead to additional barriers to follow-up interviews. 13 14 An additional challenge of dementia-related studies is that the participants are usually dyads, that is, a person affected by dementia and an informal caregiver. 15

To ensure that PWD from all over Bavaria, including rural areas, are included in the study, it is necessary to manage approximately 300 research partners (RPs) who are collecting data while conducting interviews. 10 RPs are facilities or persons involved in a dementia service like counseling centers, daycare facilities, or memory clinics. Due to the electronic data capture (EDC) from such a large group of RPs, working as “interview centers” for digiDEM distributed all over Bavaria, the participants and RPs' management means a great challenge. 9 Therefore, a clear framework for managing the study, RPs, and participants must be established to ensure the registry's success.

Objectives

Besides the EDC system for a standardized data collection process, the infrastructure should integrate the participant and RP management processes. A generic workflow for monitoring and managing the registry study is to be developed, especially for handling pseudonyms and identification data, and tracking interview schedules. Measures to ensure high data quality, study governance, as well as data privacy and security are to be included in the implementation. The objective of this article is to illustrate an information technology (IT) infrastructure that has been developed and implemented for a digital multicenter, prospective, and longitudinal dementia registry.

Methods

An early understanding of stakeholder requirements is indispensable in a user-centered development process. By involving project internal and external stakeholders, which have divergent views on what constitutes the problem and purpose of the architecture, a basis can be provided to discover requirements and constraints, evaluate the technical feasibility of a system, and determine alternative design solutions.

Therefore, the digiDEM registry architecture development involved an iterative design process inspired by the Twin Peaks Model. The Twin Peaks Model's basic idea is that the requirements and architecture are evolved and refined iteratively and in mutual interplay. 16 In this way, the requirements were formulated step by step in an incremental and agile development model to examine suitable architecture alternatives.

As a first step, extensive literature research has been conducted to identify publications that have outlined guidelines and recommendations for patient registries' IT implementations in studies. Initial interviews were also conducted with various stakeholders, including scientific research experts, specialist societies, data protection officers, ethics personnel, and RPs, that are involved in the data collection and management process. Furthermore, a survey was conducted among the RPs to obtain consensus on registry objectives and data set. 17 A workshop with project members from the preceding dementia registry project BayDem 18 19 20 was organized to take their experiences into account.

The next step was defining a set of critical activities and requirements in the processes determining the final architecture decision. The derived processes were visualized using the Business Process Model and Notation (BPMN) 21 for better understanding. Fig. 1 shows parts of the iterative development using the process “follow-up interview (t6) by the RP” as an example. Based on this, a prototypical blueprint of the architecture was developed and discussed with stakeholders. New requirements were gained from the feedback received, evaluated, and implemented into the architecture accordingly.

Fig. 1.

Development of the process “'follow-up interview (t6) by the research partner (RP)” in digiDEM Bayern.

Results

In the following, the architecture with the systems used therein, their usage in the data collection process and the participant management, implemented measures for data quality, governance, and privacy, and first experiences in the pilot phase will be described.

System Architecture

The architecture consists of three software components, as illustrated in Fig. 2 : (1) the EDC system REDCap (Research Electronic Data Capture) for the registry data and the pseudonymization allocation list, (2) the participant management system (PMS) webMODYS (Web-based modular control and documentation system) for central administration of participants and study, and (3) the videoconference software Jitsi for optional online screening and interviewing. All software components are available at no cost or free for nonprofit organizations and consortium members.

Fig. 2.

Architectural overview of the systems used in digiDEM Bayern.

The systems are hosted in a university hospital IT Infrastructure, part of the German critical information infrastructures 22 for which organizational and technical precautions apply to prevent disruptions to the availability, integrity, authenticity, and confidentiality of the IT systems, components, and processes. 23

The registry external-facing servers are located behind the firewall in a separated subnet (demilitarized zone [DMZ]). The DMZ ensures that the registry software servers are accessible from the Internet by the RPs while using the Web-based or app-based EDC client. The PMS server is in a secured internal network, which is not accessible from the Internet.

Data exchange between the EDC systems and the PMS is implemented via the REDCap application programming interface (API) in a RESTful Web service. This allows the PMS to retrieve information such as a completed interview or a participant's drop-out from the registry.

For data protection reasons, the registry data and the temporary pseudonymization allocation list must be stored separately. Therefore, two separate EDC servers are implemented, each with its own database and function.

Electronic Data Capture Software

In the digiDEM, data are collected using the EDC system REDCap, a secure Web-based software platform designed to support EDC for studies (Vanderbilt University, Nashville, Tennessee, United States). 24 25 REDCap also offers a mobile app for offline data collection if there is no Internet connectivity. Data collected offline can be synchronized with the registry server afterward.

Participant Management Software

A successful registry study requires a sustainable workflow with minimal disruption for the management of participants 9 and the overall governance process. As a result of the workshop with members of the previous dementia registry project BayDem, the need for a digital, automated monitoring process with escalation levels for nonconducted interviews was identified especially considering the high number of decentralized RPs. The PMS webMODYS plays an essential role in this. webMODYS (Leibniz Institute for Prevention Research and Epidemiology – BIPS GmbH, Bremen, Germany) was developed to control and document all administrating steps in population-based studies. The software assists with the key functions of participant management 26 : participant recruitment, monitoring and controlling the study progress, management of identifiers and pseudonyms, consent management, standardization of contact process, integrated documentation, and reporting.

webMODYS is used and managed centrally by digiDEM so that the individual RP do not need access to the system. The information necessary for conduction follow-up interviews will be communicated to them by letter.

Videoconference Software

Because of contact restrictions due to the SARS-CoV-2 (COVID-19) pandemic, lack of mobility, or long distances between RPs and participants, RPs sometimes cannot conduct interviews and neuropsychological screenings in a face-to-face setting with the PWD and caring relatives. To tackle this barrier, digiDEM offers videoconferencing software that allows RPs to conduct screenings and interviews with PWD and their family caregivers in an online setting.

The reliability of neuropsychological screenings using videoconference software has been demonstrated in several studies. 27 28 29

Following the recommendation of a German data security evaluation, 30 digiDEM provides the RPs with a server running the open-source video conferencing software Jitsi 31 (8 × 8, Inc., Campbell, California, United States).

Data Collection

Fig. 3 shows the process of electronic data collection during a baseline interview based on these systems. In digiDEM, approximately 300 local RPs, which may consist of several interviewers, conduct the recruitment and questioning of participants. The baseline interview starts after the RP has identified a potential participant. It can be conducted either in a face-to-face setting or in a videoconference setting using Jitsi.

Fig. 3.

Process of electronic data collection during baseline interview in digiDEM Bayern.

Informed Consent

If the inclusion criteria are fulfilled, participants, respectively authorized representatives, are informed about the study by the RP before the baseline interview. Informed consent is obtained for study participation, screening, permission for data procession, and further contact.

When the RP creates a new record for the participant in the EDC system, REDCap assigns a randomly generated pseudonym. The consent form is filled out by the RP together with the participants in an electronic Case Report Form (eCRF) in the EDC system. From there, the PMS retrieves the consent at regular intervals (every 4 hours) using the REDCap API.

Interview Process

In digiDEM, data collection is conducted over 3 years, beginning with the baseline interview and follow-up interviews after 6, 12, 24, and 36 months (hereafter referred to as t0, t6, t12, t24, and t36). For an interview at the RPs' institution, data collection can be done using the Web-based EDC client. REDCap also provides an app with offline data collection and subsequent synchronization for onsite interviews at the participant's home without Internet connectivity.

All participants are screened by RPs using Mini–Mental State Examination 32 and Montreal Cognitive Assessment 33 before study inclusion and later during the follow-up interviews to document the cognitive status. The screening results are documented in an eCRF. Given a positive screening result, the standardized questionnaire for the PWD and caregiver 10 is queried by the RP and recorded in corresponding eCRFs. The compilation of instruments in the digiDEM questionnaire results from the survey among the RPs, 17 experiences from BayDem, and expert interviews.

If a participant drops out, this will be documented in a separate eCRF with detailed reasons. The information about conducted interviews and documented drop-outs of participants are regularly (once a day) queried by the PMS via the REDCap API using the pseudonym as the record linkage.

Pseudonymization Allocation List

The participants' privacy in research studies is one of the core principles and has the highest priority. 34 Consequently, the participants' identity in the registry is replaced by a pseudonym assigned by the EDC system.

Nevertheless, it must be ensured that participants can be reidentified, for example, to conduct follow-up interviews. Therefore, a link between the identity and the registry data must be stored in a pseudonymization allocation list. Due to the significant number of RPs collecting data, distributed and decentralized allocation lists for which the respective RP is responsible are not practicable. The handling of the pseudonyms is of enormous importance because errors or loss during the study can lead to a complete loss of the data set.

Thus, one primary function of the PMS is the management of the identity data like names and addresses of the participants together with the storage of the allocated pseudonym to enable reidentification of the pseudonymized data in the registry. In addition to the participant's identity data, data concerning a possible legal advisor and family caregiver, and the RP conducting the interview, are assigned to the pseudonym and stored in the PMS.

For data security reasons, RPs do not have access to the PMS. To get the previously mentioned allocation list into the PMS, the RP enters his identification, the pseudonym, and the participants' identity data at the end of the baseline interview into an eCRF in a separate instance of REDCap. The PMS imports these entries in regular intervals using the REDCap API with a secure encrypted transfer. After a successful import, the entries are deleted in REDCap (EDC 2 database). After the import, the participant appears on the participant overview list in the PMS.

Participant Management

Besides the data collection, managing participants and follow-up interviews are significant challenges of a registry project. The workflows in the PMS were adapted to fulfill the policies of the digiDEM study. 10

Participant Recruitment

The PMS functionality “electronic participant recruitment” was not used in digiDEM. Technically, webMODYS could support the participant recruitment process, which was done in other studies, for example, “The German National Cohort.” 35 In digiDEM, participants affected by dementia are not recruited through impersonal letters. Instead, a decentralized and more personalized recruitment approach by local RPs, usually known to the participants and involved in their care, was chosen. Through the direct recruitment of potential participants by the RPs, participation and interview response rates can increase, 36 37 since participation in a study and follow-up interviews also depend on who is asking. 11 14 Therefore, care was taken that the communication regarding recruitment and retention respects the strong links between the RPs and participants.

Participant Monitoring

An essential function of the PMS is to notify RPs of upcoming follow-up interviews and monitor their timely conduction. Each participant follows a pathway of “stations,” which has been adapted to the digiDEM study protocol. In webMODYS, the study procedure of a participant is divided into separate process steps. These steps are mapped in the system as stations. With the help of different types of stations, specific process steps can be automated, such as generating letters or sending defined emails. This IT-supported, efficient participant and process management reduces the amount of administration and time required. The stations are connected via predecessor and successor relationships and arranged in a tree-like structure (pathway) to map the defined study process. A participant can only be in exactly one station at a time.

Fig. 4 shows the station workflow using the first follow-up interview (t6) as an example. The pathway starts with the station “baseline interview completed.” It ends after the last follow-up interview at the station “all interviews finished” or earlier at the station “drop-out” in the case of the participant's study drop out. In between, there are “waiting stations” before the respective follow-up interviews.

Fig. 4.

Participant pathway on the example of the t6-interview process in digiDEM Bayern.

After the initial import, the PMS calculates the follow-up interview schedule depending on the baseline interview date. Four weeks before the next follow-up interview, the PMS workflow automatically pushes the participant to the station “sending letter to RP.” At this station the PMS generates a letter for the RP with the upcoming interview information. By this letter, the RP has the necessary information (REDCap pseudonym, t6 interview date, participant's name, and contact information) to conduct the follow-up interview in REDCap. For data protection reasons in Germany, the letter is printed out and sent by post. By printing the letter, the participant automatically moves on to the next waiting station “waiting after letter dispatch.”

If the interview is not conducted following the predefined schedule, escalation stations are implemented. The PMS workflow engine moves the participant to the next station after either a defined waiting period or specific escalation events such as sending an email to the RP or documenting a reminder phone call. The final escalation station is the “case conference” station. Here, the study team decides whether it is still possible for the participant to be interviewed, for example, by assigning him to another RP or dropping out of the study.

Via the REDCap API, the PMS regularly checks the EDC system whether an interview has been conducted for the corresponding participants (respectively, the pseudonyms). If so, the participant moves automatically to the next waiting station before the following interview. There the participant remains until 4 weeks before the following interview. If it was the last interview (t36), the participant goes to the “all interviews completed” station. If the REDCap API reports an entry in the drop-out eCRF, the corresponding participant lands directly on the “drop-out” station, and the participant's survey ends here.

A station “resubmission” has been set up. Participants can be temporarily removed from the predefined pathway, for example, if an interview is not possible due to an extended stay in the hospital. The list of participants at the “resubmission” station can be regularly reviewed via a “to-do” function in the PMS. Depending on the situation, the participant can then be manually reassigned to a corresponding station in the pathway.

Fig. 5 shows the above-described process displayed in PMS webMODYS in the form of the “Stationsgraph.” This dashboard-like summary provides an at-a-glance view of how many participants are distributed among the various stations.

Fig. 5.

Overview of the stations and participants in the “Stationsgraph” of the participant management system (PMS) in digiDEM Bayern.

Adopted Measures

Based on experience from other registry projects 9 38 and guidelines in literature, 39 40 41 42 and collaboration with stakeholders, the following additional measures were taken to ensure the registry's success.

Data Quality

Numerous strategies have been implemented in REDCap to ensure collected data's quality, consistency, and completeness. These include strategies during data entry (e.g., built-in logic checks for data entry errors or missing values; branching logic) along with quality assurance processes directly after data entry (e.g., quality reports with own rule-based data checks). Herefore, REDCap sends an email to the study team after a conducted interview. There are also plausibility check queries pursued at regular intervals over all data sets. To improve adherence to data collection procedures and data quality sustainably, RPs receive feedback from digiDEM in reports regarding data completeness and quality.

RPs must attend an online training session via Jitsi before being granted access to the EDC system and an annual follow-up training to ensure that they are empowered to collect data. Besides, an EDC test environment is available for training.

Study Governance

As shown in Fig. 5 , the “Stationsgraph” dashboard provides a quick overview of the current number of participants per station included in the study. All interactions with participants and RPs (in- and outbound phone calls, outbound letters, and emails), along with other events (e.g., corrections of contact data or addresses), are logged by the PMS with a timestamp. The time participants spent at each station was also recorded. So, the detailed progress of every participant in the study process can be traced at any time. By using multiple escalation stations through automated workflows, compliance with study policies can be controlled.

Also, webMODYS offers various customer-specific reporting options through its integrated documentation process of all these steps. This information can be used to identify patterns of loss to follow-up and to detect participants at high risk for study drop-out at an early stage. 43 44

Data Privacy and Security

To protect the participants' privacy, a combination of organizational, legal, ethical, and technical approaches is recommended. 45

digiDEM developed a data protection concept and a data protection impact assessment according to §35 of the General Data Protection Regulation. 46 These were developed in close cooperation with the local data protection supervisor and the Bavarian data protection commissioner and approved by them.

Data privacy in the EDC system is maintained using appropriate user permissions, a role concept, and “data access groups.” This ensures that flexible data sets can be collected: RPs with different roles are assigned other predefined eCRF sets. For example, RPs from a memory clinic must fill out an additional detailed diagnostic eCRF. The use of data access groups guarantees that RPs only have access to their assigned participants' data.

All identity data are stored separately from the pseudonymized registry data in separated systems to ensure unauthorized reidentification. This separation is reflected in the organizational structure. Only a data trustee unit can access the identity data in the PMS but has no access to the registry data in the EDC system. In return, the study team and the RPs do not have access to the PMS. The exchange of information between the EDC system and the PMS via a secure API requires a REDCap API token to authenticate to REDCap on behalf of an associated, authorized user.

To ensure data security, all systems are hosted in a secured environment of a university hospital IT infrastructure with an information security management system (ISMS) based on guidelines from the German Federal Office for Information Security. 47 The ISMS specifies procedures and rules within the hospital to define, manage, control, maintain, and continuously improve data security.

Pilot Phase

During the pilot phase with a reduced number of RPs, first experiences with the architecture's feasibility could already be gathered. A total of 29 RPs has conducted 54 baseline interviews, including online screenings via Jitsi. At regular intervals, moderated online discussion meetings (“digiDEM-dialogue”) were held together with RPs to exchange experiences. Feedback from these events was evaluated and acted upon as needed in the implementation or the training material. Their suggestions for improvement, such as advanced interview notes, were integrated into the EDC system.

Discussion

The IT architecture in digiDEM was designed to provide structured procedures for collecting electronic data and supporting the study policies through a combination of an EDC system and a comprehensive PMS. Using such an IT architecture, the processes associated with the registry study can be simplified. 48

Used Methods

According to the classic waterfall model, 49 the architecture's design process starts after the requirements' analysis is finalized. This approach with strictly separated phases often leads to requirements that cannot be implemented with the available technical resources or to a poor architecture that does not meet the expectations of the stakeholders. 50 51 52 53 During the iterative, parallel phases of requirement analysis and architecture development, digiDEM stakeholders' permanent involvement was essential to understand their contexts and practices thoroughly. 16 54 This helped to detect obstacles early on and achieve higher user acceptance, or example, providing the necessary data for upcoming interviews by letter instead of an encrypted email.

The visualization of processes based on BPMN models simplified the exchange with the stakeholders. Since they are not constantly involved in the project, the models facilitate a quick familiarization with the critical issues and help to understand the processes. This approach was all the more important because the RPs are a heterogeneous group regarding age, profession, and digital skills. Most of them never worked with an EDC system before.

The close collaboration with internal and external stakeholders allows responding promptly to new functional and nonfunctional requirements regarding usability, performance, and security during the development and the pilot phase. 55 For example, based on feedback from digiDEM-dialogue, interview instructions in REDCap were given special highlighting and short video instructions were embedded. For the videoconferencing software, parameters were set in the video and audio configuration for performance optimization.

Architecture and Implementation

One essential requirement for a successful registry is providing an adequate infrastructure for the EDC process. An EDC system's benefits, such as increasing data accuracy, reducing costs, and ensuring data integrity and security, have been verified in numerous studies. 56 57 58 The recommendation in literature is to use a Web-based infrastructure as a user-friendly online technology. 56 57 59 60 This facilitates data collection, processing, and reporting. 61 Also, REDCap offers the possibility of offline data collection via a mobile app, which can also help increase data completion. 62

Many prospective registries struggle with consistently lower follow-up rates. 63 Thus, the PMS supports an automated escalation process in the case of nonexecuted follow-up interviews. To avoid significant bias and low data quality, inconsistent tracking measures and delayed interviews have to be minimized at all costs. 44 64 Therefore, a central feature of the architecture is its dedicated participant and study management realized in the PMS. The PMS workflow-triggered contact management functions are specially tailored to track all contacts with participants and RPs. The possibility of automatically generating serial letters or emails for certain events simplifies the study process's central management.

Implementation as an electronic health record-based registry, where data can be derived directly from clinical data and electronic health records, 65 66 is not purposeful in the early dementia setting. A previous study showed that PWD received their initial diagnosis at an advanced stage of the disease in many cases (16 months after the perception of the first symptoms in median 67 ). Data and knowledge from the disease's preclinical stages are important to understand the disease and slow down the progression. 68

Due to strict data protection requirements of the Bavarian data protection commissioner, a trade-off has to be accepted in the architectural design. To prevent an unauthorized reidentification of the participants, the register data and the identity data must be stored separately. Therefore, the RP must switch the REDCap system after the baseline interview and enter the pseudonym, identity, and contact information of the participants in another REDCap instance from where the PMS imports the data (see Fig. 3 ).

Comparison with Other Studies

As part of our research, we identified numerous publications on dementia registry studies, but descriptions of the respective IT solution's functionalities are rare. In many publications, isolated aspects of an EDC system or a PMS are described, but never the interaction in a dementia registry research project in practice. Comparing the literature on what constitutes the development of a successful registry for other diseases, 69 we applied a set of recommended activities, like close collaboration among key stakeholders, dedicated registry management, or involvement and awareness of legal factors throughout the development process. While most literature mainly covers core EDC processes, 70 71 they do not offer a customizable workflow solution for the participants' study pathway. The IT-supported interview scheduling, reminding, and monitoring can help reducing drop-outs.

The recently published review by Pung and Rienhoff 26 confirms the critical processes of participant management, which should be supported by IT, as outlined in our framework: recruitment, consent, identity, and study management.

This article focuses on the retention of participants rather than the recruitment process. There are enough studies, for example, recruitment via direct mail 72 or online social media campaign 73 and online enrollment of potential participants. 74 75 The retention and the reduction of loss to follow-up are crucial in studies with a long follow-up period. 76 77 Special attention must be paid to keep these rates as low as possible. 78 79

Limitations

As described above, the RPs are informed about upcoming follow-up interviews in a paper-based letter. This decision may represent a disruption in the framework's digital workflow design, but it contributes to the project's success. To comply with data protection regulations, sending the information electronically to the RPs would only be possible in encrypted form, with subsequent decryption by the RP, or providing the information in a secure online portal with user-specific access. In conversations with our RPs, the paper-based method has proven to be more feasible, but this may differ for other studies.

By providing the videoconferencing software, the RPs can conduct the screening and interview online. This requires specific technical equipment and skills on the side of the RPs and the participants, which certainly cannot be fulfilled in all cases. Current circumstances like Covid-19 and therefore the increasing number of telemedicine offerings 80 81 will help start the necessary digital revolution in dementia care. 82

Conclusion

Patient registries are fundamental to health care research projects. This study demonstrates an architecture for integrating a registry and a PMS in a research study with more than 300 RPs collecting data. The implementation's advantages can be seen in the various stakeholders' involvement in the development process up to the pilot phase. Furthermore, the proof of feasibility in practice has been gathered during the first data collection interviews. Due to its adaptability of the used software systems, a transfer to other projects should be possible.

Clinical Relevance Statement

This article demonstrates a generic solution integrating a registry and participant management in a dementia registry study. This facilitates the use of EDC and participant management solutions, thus promoting their dissemination and use of registry studies in the dementia setting.

Multiple Choice Questions

1. Why does digiDEM not perform its recruitment with the PMS?

   1. webMODYS does not offer a recruitment function.

   2. The function has to be licensed for each recruited participant.

   3. Recruitment is performed decentrally and personally by the research partners.

   4. Participants are recruited by newspaper advertisements.

   Correct Answer : The correct answer is option c. In digiDEM, we have chosen a more personal recruitment method by the research partners in the community. This may increase the chances of study participation.

2. Why do the research partners not store the pseudonymization allocation list decentrally in their institutions?

   1. The research partners do not know the pseudonym of the participant.

   2. The research partners do not have the appropriate IT equipment for this.

   3. For data protection reasons, decentralized storage is not permitted.

   4. The risk of losing the pseudonymization allocation list is too high.

   Correct Answer: The correct answer is option d. If the allocation list is lost, the participants' corresponding data would also be lost as long as surveys are still pending. Therefore, the pseudonymization allocation list is stored centrally and backed up regularly.

3. What is the basic idea of the Twin Peaks Model?

   1. The requirements and architecture of a system are developed iteratively and parallel to each other.

   2. Requirements are developed iteratively based on the architecture of existing systems.

   3. The architecture is developed based on the existing requirements and systems.

   4. It is an enhancement of the waterfall model with stakeholder involvement.

   Correct Answer: The correct answer is option a. The Twin Peaks Model's basic idea is that the requirements and architecture are evolved and refined iteratively and in mutual interplay. In this way, the requirements were formulated step by step in an incremental and agile development model to examine suitable architecture alternatives.

Funding Statement

Funding The project is funded by the Bavarian State Ministry of Health and Care as part of the funding initiative BAYERN DIGITAL II ' (funding code: G42d-G8300–2017/1606–83).