Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper offers a thoughtful and timely examination of how technology can enhance access to second opinions for patients with rare diseases—an area where diagnostic uncertainty and a shortage of specialists are common. The authors clearly explain the challenges faced by rare disease patients, including diagnostic delays and fragmented care, and convincingly show how digital platforms, telemedicine, and algorithm-supported decision tools can help close these gaps. Overall, the paper is a well-crafted and insightful contribution that highlights both the potential and the limitations of digital tools in providing accurate, equitable second opinions for people with rare diseases.

Author Response

Comments 1: This paper offers a thoughtful and timely examination of how technology can enhance access to second opinions for patients with rare diseases—an area where diagnostic uncertainty and a shortage of specialists are common. The authors clearly explain the challenges faced by rare disease patients, including diagnostic delays and fragmented care, and convincingly show how digital platforms, telemedicine, and algorithm-supported decision tools can help close these gaps. Overall, the paper is a well-crafted and insightful contribution that highlights both the potential and the limitations of digital tools in providing accurate, equitable second opinions for people with rare diseases.

Response 1: We sincerely thank the reviewer for this positive and encouraging assessment of our scoping review. We appreciate the recognition of the paper’s focus and the balanced appraisal of both the potential and the limitations of digital tools. Although no specific revisions were requested in this comment, we carefully re-reviewed the manuscript to ensure that our framing of opportunities and constraints remains consistent across the Introduction, Results, and Conclusions.

Reviewer 2 Report

Comments and Suggestions for Authors

Manuscript Title : Second-Opinion Systems for Rare Diseases: A Scoping Review of Digital Workflows and Networks

The authors conducted a scoping review of digital second-opinion (SO) systems for rare diseases across European, national, regional, and international settings. The review highlights governance models, workflow structures, participation modalities, and implementation challenges. The topic is very much relevant to medical informatics and digital health.

However, from a computer science / health informatics perspective, the manuscript provides insufficient technological depth. To overcome this weakness, authors may address the following suggestions carefully. So , I recommend for a major revision and need to verify that the suggestions are carried out in the revised manuscript efficiently.

 

• In the entire paper, good explanation of clinical workflow is seen. But paper appear lacking technological backbone like APIs, messaging protocols, storage.

• Abstract mentions “digital workflows” but does not specify any technological features in keywords section. So, some related keywords such as interoperability, platform architecture can be added.
• Although multiple digital SO systems are reviewed, no architectural diagrams are The architecture diagram may include

• Backend architecture (cloud/on-prem, modularity, microservices).
• System components and their interactions.
• Data flow models between hospitals, experts, and central platforms.
• Role of communication servers, imaging servers, workflow engines, and identity services.

• To explain the terminology and avoid overlaps, can a glossary be added?
• Authors may think of including  comparative technology table of platforms and technologies, digital architectures as the outcome of surveying the related works.

• Can authors comment on  tele-expertise software challenges including latency, identity management, data exchange under the application considered.

• No protocol is  registered / justified.
• What are all the technical keywords used in the search strategy?
• Authors may include at least 1–2 system diagrams to illustrate data flow, authentication, case submission, triage, expert review, and feedback.

• Any additional information on user authentication and audit logs ?.
• To improve the performance and scalability, I suggest to consider the metrics like uptime, server load handling, response times, imaging upload latency, case routing efficiency, scalability across regions also.
• Interoperability is described vaguely. Can the authors state explicit examples (FHIR resources, REST endpoints).
• What are all the possible security constraints in cross-border systems. Can authors add the same?

• The digital maturity assessment is missing. So authors can think of adding WHO Digital Health Maturity Model, HIMSS EMRAM, Telemedicine Maturity Index as well as FAIR data principles
• What do the authors mean by maturity of scoping review; pl add some tech-specific metrics.
• Can the authors consider and discuss the potential of AI/Automation in this study?

Author Response

Comments 1: The authors conducted a scoping review of digital second-opinion (SO) systems for rare diseases across European, national, regional, and international settings. The review highlights governance models, workflow structures, participation modalities, and implementation challenges. The topic is very much relevant to medical informatics and digital health.

Response 1: We thank the reviewer for the acknowledgement and supportive summary of our work and for highlighting the relevance of digital second opinion systems for rare diseases to medical informatics and digital health.

 

Comments 2: However, from a computer science / health informatics perspective, the manuscript provides insufficient technological depth. To overcome this weakness, authors may address the following suggestions carefully. So , I recommend for a major revision and need to verify that the suggestions are carried out in the revised manuscript efficiently.

Response 2: Thank you for this overarching comment. We agree that the initial submission emphasized clinical workflow and governance more strongly than the informatics implementation perspective. In the revised manuscript, we strengthened the technological depth in a structured and verifiable manner, while remaining faithful to what is actually reported in the included evidence base. We hope the targeted revisions address the concern about technological depth while preserving the review’s focus on health service implementation.

 

Comments 3: In the entire paper, good explanation of clinical workflow is seen. But paper appear lacking technological backbone like APIs, messaging protocols, storage.

Abstract mentions “digital workflows” but does not specify any technological features in keywords section. So, some related keywords such as interoperability, platform architecture can be added.

Response 3: We agree that the manuscript places stronger emphasis on clinical workflow, governance, and implementation, which reflects the primary objective of the scoping review and the level of technical detail typically reported in the included sources. To address your point without overextending beyond the available evidence, we made two targeted revisions. First, we expanded the keywords to include informatics-oriented terms, such as interoperability and platform architecture, to reflect the technological dimension better and improve discoverability for computer science and health informatics audiences. Second, we added a brief statement in the limitations clarifying that low and heterogeneous reporting of APIs, messaging protocols, and storage details constrained deeper technical characterization.

 

Comments 4: Although multiple digital SO systems are reviewed, no architectural diagrams are The architecture diagram may include

• Backend architecture (cloud/on-prem, modularity, microservices).
• System components and their interactions.
• Data flow models between hospitals, experts, and central platforms.
• Role of communication servers, imaging servers, workflow engines, and identity services.

Response 4: Thank you for this suggestion. We agree that an architectural view can improve clarity for readers with a computer science and health informatics perspective. Because the included studies do not consistently report deployable backend details, we could not reconstruct accurate “as-built” architectures on a per-system basis without introducing assumptions beyond the evidence. Instead, we added a single reference architecture diagram (Figure 2) that synthesizes the recurring functional components and interactions described or implied across implementations. The diagram explicitly includes identity and access management, consent and data minimization, a workflow engine for case submission, triage and routing, clinical documentation handling, imaging exchange, communication modalities, audit logging for traceability, and interoperability connectors. We clarify in the caption that Figure 2 is a conceptual reference model intended to support implementation-oriented discussion rather than a system-specific backend depiction.

 

Comments 5: To explain the terminology and avoid overlaps, can a glossary be added?

Response 5: Thank you for the suggestion. We agree that terminology can overlap across clinical and informatics domains. In the revised manuscript, we reviewed the text to improve terminological clarity and consistency, and we ensured that all abbreviations and acronyms are defined at first use before they appear elsewhere in the manuscript. Given these revisions and to avoid unnecessary length and redundancy, we did not add a separate glossary.

 

Comments 6: Authors may think of including comparative technology table of platforms and technologies, digital architectures as the outcome of surveying the related works.Response 6: We agree that a comparative view is helpful for readers. In the revised manuscript, we make explicit that Supplementary Spreadsheet S1 provides a comparative per study table for all included sources of evidence, including technology-relevant fields that are consistently extractable across the literature, such as technological modality, workflow and governance features, and interoperability or integration signals with registries and, when mentioned, EHR connectivity.

We did not add a detailed architecture table at the level of specific APIs, endpoints, or storage design because such low level implementation artifacts are not reported consistently across the included studies, which would preclude an evidence-based, comparable synthesis. Therefore, we provide the comparative table at the highest common level supported by the corpus.

 

Comments 7: Can authors comment on  tele-expertise software challenges including latency, identity management, data exchange under the application considered.

Response 7: These challenges are central to tele-expertise implementations, and we address them in the revised manuscript on governance, data protection, and interoperability, as well as in the discussion of implementation and evaluation needs. Specifically, identity management is covered at the level reported by the included systems, for example, role-based access control, consent aligned with GDPR, and auditable access patterns in ERN-style deployments. Data exchange challenges are discussed through concrete interoperability examples, including DICOM-enabled imaging exchange, integration with imaging repositories or PACS, and linkage to registries, while noting that direct EHR integration is less commonly implemented and is often described as a goal. Finally, latency and related performance constraints are framed as operational evaluation priorities for future work because infrastructure level metrics are not consistently reported in the included sources, and we avoid inferring details that are not evidence-based.

 

Comments 8: No protocol is  registered / justified.

Response 8: Thank you for raising this point. While protocol registration is not mandatory for scoping reviews, the absence of a registered protocol should be transparently justified, given potential concerns about methodological drift. This has been addressed in the revised manuscript, including a brief acknowledgement in the limitations to transparently reflect the absence of prospective registration and the mitigation steps implemented.

 

Comments 9: What are all the technical keywords used in the search strategy?

Response 9: In our search strategy, we used technical terms at the level of the service model and digital modality rather than low-level computer science implementation keywords. This choice was intentional and aligned with the review objective of mapping digital second opinion service models, governance, and workflows in healthcare settings. In this literature, detailed engineering terminology such as APIs, messaging protocols, or storage architectures is inconsistently reported and often not indexed in titles and abstracts. Including such keywords would likely decrease sensitivity and systematically miss clinically described implementations that do not explicitly report their technical stack. We partially mitigated this by searching both biomedical and technology-focused databases.

 

Comments 10: Authors may include at least 1–2 system diagrams to illustrate data flow, authentication, case submission, triage, expert review, and feedback.

Response 10: Thank you for the suggestion. We agree that visualizing the end-to-end process improves interpretability. To avoid redundancy and because low-level architectural reporting is heterogeneous across primary sources, we address this request using the same Figure 2 introduced in response to Comment 4. Figure 2 presents a single, system-level diagram that highlights the core data flow and process steps consistently described across digital second opinion pathways, including authentication and access control, case submission, triage and routing, expert review and discussion, and the documented recommendation returned to the referring site. The figure also makes cross-cutting governance and traceability elements explicit (consent, minimization, and audit logging), aligning the workflow view with implementation-relevant controls.

 

Comments 11: Any additional information on user authentication and audit logs ?.

Response 11: Within the included evidence base, security reporting is typically provided at the level of governance features rather than detailed implementation artifacts. In the manuscript, we already summarize that ERN-style deployments share role-based access control, GDPR-aligned consent, and audit trails, alongside traceable documentation of outcomes. Beyond these elements, the primary sources rarely specify authentication mechanisms (e.g., MFA, identity federation, or SSO) or operational parameters of audit logging (e.g., retention, monitoring, or alerting). Therefore, we did not expand the manuscript with low-level authentication or log configuration details, as doing so would require assumptions not supported by the included studies.

 

Comments 12: To improve the performance and scalability, I suggest to consider the metrics like uptime, server load handling, response times, imaging upload latency, case routing efficiency, scalability across regions also.

Response 12: We agree that operational performance and reliability metrics are essential to support scalability planning for digital second opinion services. However, this scoping review focused on mapping service models, governance, workflows, and implementation challenges, and the included sources do not report infrastructure-level metrics consistently or comparably. In addition, these indicators were not part of our predefined charting domains, so we do not synthesize them as outcomes. To address your point, we added a short paragraph in the Discussion highlighting a set of operational metrics that future prospective evaluations should report.

 

Comments 13: Interoperability is described vaguely. Can the authors state explicit examples (FHIR resources, REST endpoints).

Response 13: We agree that interoperability benefits from more concrete examples. In the revised manuscript, we strengthened the interoperability discussion by explicitly stating the types of integration reported in the included systems, including DICOM-based image upload and sharing, integration with imaging repositories and PACS, and linkage to disease registries. We also clarify that direct EHR connectivity is less commonly implemented and is more often described as a near-term goal, including via open standards such as HL7 FHIR. Regarding the request for specific FHIR resources and REST endpoints, the included sources do not consistently report such low-level implementation artifacts to support a comparable, evidence-based listing across initiatives.

 

Comments 14: What are all the possible security constraints in cross-border systems. Can authors add the same?

Response 14: Thank you for emphasizing security, which is indeed a critical dimension in cross-border second-opinion services. We agree with the intent of the comment, but note that an exhaustive list of all possible constraints is not feasible within the scope of a scoping review, and the included sources do not consistently report security architectures and controls to support a system-by-system technical assessment. To address the comment rigorously and in an implementation-relevant way, we enhanced the Discussion section to summarize key security and governance constraints for cross-border services. 

 

Comments 15: The digital maturity assessment is missing. So authors can think of adding WHO Digital Health Maturity Model, HIMSS EMRAM, Telemedicine Maturity Index as well as FAIR data principles

Response 15: We agree that digital maturity frameworks and data stewardship principles are relevant to the long term evaluation and scale up of digital health services. However, we did not include a formal digital maturity assessment in this scoping review because it was outside our predefined charting domains and because the unit of analysis and required indicators of the cited frameworks do not consistently align with the included evidence base. For example, WHO-oriented maturity approaches are typically framed at the level of national digital health capability and governance. At the same time, HIMSS EMRAM is primarily designed to benchmark hospital-wide electronic medical record adoption and does not directly translate into interinstitutional second opinion workflows. In addition, the primary sources report heterogeneous and often incomplete technical and operational indicators, which would make cross-initiative scoring unreliable.

To address your point without overextending beyond the evidence, we added a concise Discussion note acknowledging the potential utility of maturity models and the FAIR principles as lenses for future prospective evaluations, emphasizing the need for standardized reporting and indicator collection to enable meaningful maturity assessment.

 

Comments 16: What do the authors mean by maturity of scoping review; pl add some tech-specific metrics.

Response 16: We understand that the term maturity was ambiguous and could be misread as referring to the scoping review itself. We have clarified the wording to make explicit that we refer to implementation maturity, meaning the stage of deployment and operationalization of the second opinion service as described in the primary sources, not a validated maturity score of the review or of the underlying technology. We also revised statements in the Discussion and Conclusions to avoid implying strong claims about readiness for scale beyond what a scoping review without formal quality appraisal can support.

Regarding the request for tech-specific metrics, we did not add new technical performance measures as outcomes because the included sources do not consistently or comparably report such metrics, and they fall outside our predefined charting domains. Instead, we added a brief limitation highlighting the lack of standardized technical reporting.

 

Comments 17: Can the authors consider and discuss the potential of AI/Automation in this study?

Response 17: We agree that AI and automation are increasingly relevant to digital second opinion services. However, in the systems captured in our included evidence base, explicit AI-driven automation is not commonly reported as a core operational feature. To address your comment without overstating the evidence, we added a paragraph in the Discussion outlining where AI-enabled automation could plausibly support these workflows.

Reviewer 3 Report

Comments and Suggestions for Authors

The authors note that no protocol was registered. While acceptable for scoping reviews, this raises concerns about methodological drift.

• Were the research questions, inclusion criteria, and data extraction domains finalized before screening began?

• Were any eligibility criteria refined iteratively after reviewing the literature?

  The review excludes “isolated individual requests” in favor of “structured systems,” but the operational definition of structured remains subjective.

  • Does a system require a dedicated digital platform, or can standardized workflows via email/shared documents qualify?

  • Was there a minimum threshold for case volume, institutions, or duration of operation?

  • How were borderline cases handled during screening

• Were non-English abstracts screened and excluded at full text, or excluded at the search stage?
• Add a short reflective note on potential disciplinary bias introduced by database selection.

• The absence of formal quality appraisal is consistent with scoping review methodology. However, the manuscript draws relatively strong conclusions regarding feasibility, maturity, and readiness for scale.

  Concern: Reported outcomes (e.g., diagnostic revision rates, cost figures) are program-reported and not independently validated.

Author Response

Comments 1: The authors note that no protocol was registered. While acceptable for scoping reviews, this raises concerns about methodological drift.

Response 1: We thank the reviewer for raising this important methodological point. We agree that the absence of a prospectively registered protocol can raise concerns about methodological drift. To address this, we strengthened the Methods section to explicitly describe the safeguards used to minimize drift, including predefined PCC framing, eligibility criteria, and research questions before screening; piloting of the data charting form; independent, dual screening and extraction; and documentation of full-text exclusion reasons, consistent with PRISMA ScR reporting. We also added a clarifying statement in the limitations to acknowledge this risk and the mitigation steps implemented.

 

Comments 2: Were the research questions, inclusion criteria, and data extraction domains finalized before screening began?

Response 2: Yes. The research questions were finalized before database searching and screening, and were used to define the PCC-based eligibility criteria. Eligibility criteria were established a priori and applied consistently during title and abstract screening and full text screening. The data extraction domains were also defined a priori from the research questions and the charting framework, and the charting form was piloted to clarify operational definitions and improve consistency before complete extraction. We have added explicit wording in the Methods section to make this chronology transparent.

 

Comments 3: Were any eligibility criteria refined iteratively after reviewing the literature?

Response 3: The eligibility criteria were defined a priori using the PCC framework and were applied consistently throughout title and abstract screening and full text screening. We did not iteratively refine the inclusion or exclusion criteria after screening began. The only iterative element was piloting the data charting form, which was used to clarify operational definitions and improve consistency among reviewers, without expanding or narrowing the scope of eligible studies. We have added explicit wording in the Methods section to make this distinction transparent.

 

Comments 4: The review excludes “isolated individual requests” in favor of “structured systems,” but the operational definition of structured remains subjective.

Response 4: We agree that the initial wording could be interpreted subjectively. In the revised manuscript, we have added an explicit operational definition of a structured second opinion system and ‘isolated individual requests’, and aligned the eligibility criteria accordingly. 

 

Comments 5: Does a system require a dedicated digital platform, or can standardized workflows via email/shared documents qualify?

Response 5: We agree that the initial wording could be read as implying that a dedicated digital platform is required. In the revised manuscript, we clarify that a bespoke platform is not a necessary condition. We include both purpose-built platforms and standardized digital workflows implemented using secure institutional tools, provided that the initiative meets the operational definition of a structured system. In contrast, informal, ad hoc email exchanges without standardized procedures, governance, or documented outputs remain excluded.

 

Comments 6: Was there a minimum threshold for case volume, institutions, or duration of operation?

Response 6: We did not impose minimum thresholds for case volume, number of participating institutions, or duration of operation because our scoping aim was to map service models, governance arrangements, and workflow characteristics across digital second-opinion initiatives, including pilots and early implementations. We also clarified that these maturity indicators were not systematically extracted. Across the included literature, reporting of volumes, participating sites, and operational duration is heterogeneous and often incomplete, which would make comparative synthesis unreliable and potentially misleading. We have added explicit wording in the Methods and limitations to clarify this scope decision.

 

Comments 7: How were borderline cases handled during screening

Response 7: We clarified our approach to borderline cases in the Methods. Records were considered borderline when eligibility could not be determined from the title and abstract alone, or when reporting was insufficient to apply the eligibility criteria with confidence. In these instances, we retained records for full-text review rather than excluding them at the abstract stage. Borderline decisions at full text were discussed among reviewers and resolved by consensus or by a third reviewer.

 

Comments 8: Were non-English abstracts screened and excluded at full text, or excluded at the search stage?

Response 8: Records were primarily excluded at the search stage, as we applied language limits to retrieve studies in English, Portuguese, or Spanish using database filters and, where applicable, language operators in the search syntax. We have clarified this explicitly in the Search strategy section and noted the potential implication of language restriction as a limitation.

 

Comments 9: Add a short reflective note on potential disciplinary bias introduced by database selection.

Response 9: We agree that database selection can introduce disciplinary bias by privileging literature indexed in specific outlets. Although we intentionally combined biomedical and technology-focused databases to broaden coverage, relevant evidence may still be underrepresented if published in venues with limited indexing. We have added a short note to the Methods and to the limitations to acknowledge this risk.

 

Comments 10: The absence of formal quality appraisal is consistent with scoping review methodology. However, the manuscript draws relatively strong conclusions regarding feasibility, maturity, and readiness for scale.

Response 10: Thank you for this important point. We agree that, in a scoping review without formal quality appraisal, conclusions should avoid implying stronger certainty than the underlying evidence supports. In response, we revised the Discussion and Conclusions to recalibrate the strength of inference. We now frame feasibility and scale-related statements as signals reported in specific implementations, while emphasizing that the evidence base is heterogeneous, largely descriptive, and, in some cases, prospective. We also removed or softened wording that could be interpreted as asserting maturity or general readiness for scale.

 

Comments 11: Concern: Reported outcomes (e.g., diagnostic revision rates, cost figures) are program-reported and not independently validated.

Response 11: We agree. In this scoping review, outcomes were extracted as reported in the included sources, which are predominantly programmatic evaluations rather than independently audited studies. We therefore cannot treat these metrics as externally validated estimates of effectiveness or economic value. To address this, we revised the manuscript to explicitly state in the Methods that reported outcomes are presented as program-reported figures, and we strengthened the limitations to note the absence of independent validation and the heterogeneity of outcome definitions.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have satisfactorily addressed all major reviewer comments. So, I recommend acceptance ( minor editorial revision can be taken care during production stage)