. 2019 Feb 18;54(8):1179–1188. doi: 10.1038/s41409-019-0476-6

Table 3.

Elements of the ideal registry software^a

Donor database	Patient database	Work process	Quality and security requirements
−Donor identification: unique registry ID for the donor is the primary reference (other IDs are allowed). In 2017, WMDA implemented the GRID (Global Registration Identifier for Donors), which will facilitate standardization of donors identification globally. −HLA data: separate fields for serology and DNA typing results, typing laboratory, date of typing, primary typing data, NIMA, etc. −Demographics: name, title, gender, date of birth, ethnic group, insurance company etc. −Relationships: family or personal relations to other donors or patients, used for family reports of the patient. −Recruitment: donor center, date of recruitment, method (website, patient-draft, blood donor, indication of whether the donor is also a blood or platelet donor). −Donor status: active or no, and if not active is the withdrawal temporary or permanent? What’s the reason of withdrawal (age, medical, personal)? –Contact details: permanent, temporary, or work address, email, phone numbers, social media networks, language, preferred contact method, history of communication with the donor. –Medical questionnaire: weight, height, blood group, hemoglobin, number of pregnancies, number of blood transfusions, donor consent to different types of donations, medical history. –Infectious disease markers: CMV status, toxoplasmosis, EBV status, HIV status, HIV-p24 antigen, antibodies to HIV, hepatitis B and C status and antibodies, syphilis status with dates of tests, and laboratories that performed tests. –Products: information about the stored donor samples. –Cord blood unit data: volume of cord blood unit, total nucleated cells, CD34 + cells, mononucleated cells, white blood cells, processing methods, fractions, and maternal tests. −Collection: date and place of collection, date, and place of transplant, patient ID, source of stem cells (bone marrow, PBSC, DLI, cord blood, other). −Audit: who has created or modified the donor record and when, searchable history of changes to the donor record.	−Patient identification: unique registry ID for the patient is the primary reference (other IDs are allowed). −HLA data: separate fields for serology and DNA typing results, typing laboratory, date of typing, primary typing data. Separate fields for historical HLA results. −Demographics: name, title, gender, date of birth, ethnic group, insurance company etc. −Relationships: family or personal relations to donors, used for family reports of the patient. −Patient status: donor search status, transplantation status, closure of the case (date, reason). −Medical information: diagnosis, disease phase, weight, blood group, CMV status. −Transplants: date and place of collection, date and place of transplantation, donor ID, source of stem cells. −Quality control: the system should control quality of data according to registry policies. There should be no expired reservations of donors , no over-age donors that are marked as ‘available for transplant purposes’ on the searches, no donors missing critical data (e.g., date of birth, gender) and HLA data should always be valid according to the latest HLA nomenclature. −Regular update of reference tables: for HLA nomenclature and multiple-allele-codes. −Reports: customizable reports of donor and patient details, ability to export to PDF files, ability to send letters and emails to donors through user-defined templates. −Transplant records, donor and patient follow-up records with automated reminders of incomplete or missing records. −Audit: who has created or modified the patient record and when, searchable history of changes of the patient record.	−Donor searches: a validated donor search algorithm is the key and most difficult element of the registry software. It has to be compliant with the WMDA guidelines. −Output report: a search report displaying the donors and cord blood units in HLA matching order, as a minimum. Only active donors should appear in search reports. −Management of requests (electronic, fax, or papers): typing requests, verification typing sample requests, infectious disease marker testing requests, donor reservation requests and work-up requests. The software must be able to display the status of the request. The system should support the workflow. management of requests for different scenarios. −WMDA annual report: Many registries do not systematically collect data for the WMDA annual report. There is a huge advantage to building in this functionality to generate data automatically at the start of the IT project. This will also help to perform annual statistics and research. −Financial module: creation of invoices according to registry policy and behavior of users. Export of invoices to financial system can be integrated into the request management workflow. Integration with external financial software systems. −Management of code lists (insurance companies, diagnosis, postal codes, etc.). −Document management system: possibility to store and maintain different kinds of electronic documents, linked to donor, patient, search, and other types of records. −International interfaces: the registry should be well integrated to the international community (BMDW, EMDIS^b, EMDIS cord, NMDP, Netcord), mainly to assist with efficient donor searches. −National interfaces: the registry should be well connected with donor centers, collection centers, transplant centers, HLA laboratory. −Donors interface: it helps a registry to keep in contact with donors, Sponsors, social media networks. −HLA: regular import of the current HLA nomenclature. HLA data should always be valid according to the latest HLA nomenclature. −The software should support national names and characters. − Flexibility and availability of the company to update the software is crucial. −Generate letters and emails.	−The security of the overall data system should be compliant with WMDA Standards. −Authentication and authorization policies: to configure different user roles and limit the functionalities available to certain roles. The system should have different levels of access for different users. −Archiving of the data: including log-files, for 30 years or according to national legislation. −Traceability of changes: clear log-file of data saving, handling, changes, and removal of data, including what amendments were made, by whom, when the amendment took place and why. (Traceability is defined in the WMDA standards 1 as ‘to follow all the steps of a process from beginning to end). −Confidentiality: the access and transmission of data must be organized in a way that accidental or unauthorized access, destruction or modification of data is prevented and confidentiality is guaranteed. It is advisable at the outset of creating a new IT system to document how records will be protected from accidental or unauthorized access, destruction and modification. −Back-ups and disaster recovery planning: The registry must have a written policy on how its system is backed up. Back-ups should be performed regularly on a fixed schedule and stored off-site at some distance from the registry’s location.^c The registry should have contracts with hardware suppliers to provide replacement hardware within an agreed timeframe. −Electricity power backup system and internet backup system should be documented. −Documentation: all registries must have documents to describe key computer systems and network infrastructures. −Data quality control: the system automatically checks donor database every night and warns users about discrepancies that breaks registry policy. −All incidents should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of Corrective And Preventive Actions (CAPA). −Under GMP regulations, the registry system should be periodically evaluated to confirm the IT system remains in a valid state and is GMP-compliant.

Donor database

Patient database

Work process

Quality and security requirements

−Donor identification: unique registry ID for the donor is the primary reference (other IDs are allowed). In 2017, WMDA implemented the GRID (Global Registration Identifier for Donors), which will facilitate standardization of donors identification globally.

−HLA data: separate fields for serology and DNA typing results, typing laboratory, date of typing, primary typing data, NIMA, etc.

−Demographics: name, title, gender, date of birth, ethnic group, insurance company etc.

−Relationships: family or personal relations to other donors or patients, used for family reports of the patient.

−Recruitment: donor center, date of recruitment, method (website, patient-draft, blood donor, indication of whether the donor is also a blood or platelet donor).

−Donor status: active or no, and if not active is the withdrawal temporary or permanent? What’s the reason of withdrawal (age, medical, personal)?

–Contact details: permanent, temporary, or work address, email, phone numbers, social media networks, language, preferred contact method, history of communication with the donor.

–Medical questionnaire: weight, height, blood group, hemoglobin, number of pregnancies, number of blood transfusions, donor consent to different types of donations, medical history.

–Infectious disease markers: CMV status, toxoplasmosis, EBV status, HIV status, HIV-p24 antigen, antibodies to HIV, hepatitis B and C status and antibodies, syphilis status with dates of tests, and laboratories that performed tests.

–Products: information about the stored donor samples.

–Cord blood unit data: volume of cord blood unit, total nucleated cells, CD34 + cells, mononucleated cells, white blood cells, processing methods, fractions, and maternal tests.

−Collection: date and place of collection, date, and place of transplant, patient ID, source of stem cells (bone marrow, PBSC, DLI, cord blood, other).

−Audit: who has created or modified the donor record and when, searchable history of changes to the donor record.

−Patient identification: unique registry ID for the patient is the primary reference (other IDs are allowed).

−HLA data: separate fields for serology and DNA typing results, typing laboratory, date of typing, primary typing data. Separate fields for historical HLA results.

−Demographics: name, title, gender, date of birth, ethnic group, insurance company etc.

−Relationships: family or personal relations to donors, used for family reports of the patient.

−Patient status: donor search status, transplantation status, closure of the case (date, reason).

−Medical information: diagnosis, disease phase, weight, blood group, CMV status.

−Transplants: date and place of collection, date and place of transplantation, donor ID, source of stem cells.

−Quality control: the system should control quality of data according to registry policies. There should be no expired reservations of donors

, no over-age donors that are marked as ‘available for transplant purposes’ on the searches, no donors missing critical data (e.g., date of birth, gender) and HLA data should always be valid according to the latest HLA nomenclature.

−Regular update of reference tables: for HLA nomenclature and multiple-allele-codes.

−Reports: customizable reports of donor and patient details, ability to export to PDF files, ability to send letters and emails to donors through user-defined templates.

−Transplant records, donor and patient follow-up records with automated reminders of incomplete or missing records.

−Audit: who has created or modified the patient record and when, searchable history of changes of the patient record.

−Donor searches: a validated donor search algorithm is the key and most difficult element of the registry software. It has to be compliant with the WMDA guidelines.

−Output report: a search report displaying the donors and cord blood units in HLA matching order, as a minimum. Only active donors should appear in search reports.

−Management of requests (electronic, fax, or papers): typing requests, verification typing sample requests, infectious disease marker testing requests, donor reservation requests and work-up requests. The software must be able to display the status of the request. The system should support the workflow. management of requests for different scenarios.

−WMDA annual report: Many registries do not systematically collect data for the WMDA annual report. There is a huge advantage to building in this functionality to generate data automatically at the start of the IT project. This will also help to perform annual statistics and research.

−Financial module: creation of invoices according to registry policy and behavior of users. Export of invoices to financial system can be integrated into the request management workflow. Integration with external financial software systems.

−Management of code lists (insurance companies, diagnosis, postal codes, etc.).

−Document management system: possibility to store and maintain different kinds of electronic documents, linked to donor, patient, search, and other types of records.

−International interfaces: the registry should be well integrated to the international community (BMDW, EMDIS^b, EMDIS cord, NMDP, Netcord), mainly to assist with efficient donor searches.

−National interfaces: the registry should be well connected with donor centers, collection centers, transplant centers, HLA laboratory.

−Donors interface: it helps a registry to keep in contact with donors, Sponsors, social media networks.

−HLA: regular import of the current HLA nomenclature. HLA data should always be valid according to the latest HLA nomenclature.

−The software should support national names and characters.

− Flexibility and availability of the company to update the software is crucial.

−Generate letters and emails.

−The security of the overall data system should be compliant with WMDA Standards.

−Authentication and authorization policies: to configure different user roles and limit the functionalities available to certain roles. The system should have different levels of access for different users.

−Archiving of the data: including log-files, for 30 years or according to national legislation.

−Traceability of changes: clear log-file of data saving, handling, changes, and removal of data, including what amendments were made, by whom, when the amendment took place and why.

(Traceability is defined in the WMDA standards 1 as ‘to follow all the steps of a process from beginning to end).

−Confidentiality: the access and transmission of data must be organized in a way that accidental or unauthorized access, destruction or modification of data is prevented and confidentiality is guaranteed. It is advisable at the outset of creating a new IT system to document how records will be protected from accidental or unauthorized access, destruction and modification.

−Back-ups and disaster recovery planning: The registry must have a written policy on how its system is backed up. Back-ups should be performed regularly on a fixed schedule and stored off-site at some distance from the registry’s location.^c The registry should have contracts with hardware suppliers to provide replacement hardware within an agreed timeframe.

−Electricity power backup system and internet backup system should be documented.

−Documentation: all registries must have documents to describe key computer systems and network infrastructures.

−Data quality control: the system automatically checks donor database every night and warns users about discrepancies that breaks registry policy.

−All incidents should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of Corrective And Preventive Actions (CAPA).

−Under GMP regulations, the registry system should be periodically evaluated to confirm the IT system remains in a valid state and is GMP-compliant.

^aAdopted from WMDA handbook with permission

^bEMDIS (European Marrow Donor Information System) is an open computer network for the exchange of data between different stem cell donor registries

^cWMDA Crisis Response, Business Continuity, and Disaster Recovery Guidelines, issued by WMDA Working Group Quality and Regulation