Table 4.
Requirements for HSV registry design.
| Category | Requirement/Issue | HSV Medical Registry Design Implications |
|---|---|---|
| Interoperability, population-level data | Data exchange | • API [29], FHIR [26] |
| • Consider open-source platforms | ||
| • Consider CERNER FHIR integrations | ||
| Data analysis | Data collection, processing and analysis | |
| Common terminologies | Develop the system using the common and accepted standards and terminology for data schema definitions: | |
| International Classification of Diseases and its clinical modifications | ||
| International Classification of Primary Care | ||
| Medical Dictionary for Regulatory Activities (MedDRA) | ||
| Cross-border integrations | PARENT [20] | |
| Accessibility | Selection bias | Accessibility according to standards (across socio-demographic, geographical location, language groups, also split by familiarity with technology, ability to communicate, etc.) |
| Patient-centricity, privacy, patient goals and engagement | Roles of stakeholders are not defined | Define the roles of stakeholders via use cases [31] |
| Security | Patient access to data and content | Design user-friendly dashboards, updated with real-time information [16] |
| Legislative requirements | Ensure GDPR, HIPAA compliance and on the EU level, adhere to the cross-border healthcare directive (CBHD). Consider anonymising the data before it is shared | |
| Personal privacy | Investigate pseudo-anonymization and interviews cases | |
| User experience (trust and openness) | Use common frameworks and templates [32] for: | |
| Design principles | ||
| Look and feel—grid, colours and typography | ||
| Reusable components and design patterns that solve common problems | ||
| Content style guide—how to write | ||
| Accessibility | ||
| Security of technology | Consider encryption, server location, SSL, Database | |
| Sustainability and extendability | Maintenance of the technology platform and operations | Holistic strategy for the system implementation, support and development |
| No dependency on proprietary tech platforms (open-source, widely adopted tech). Low dependence on future tech maintenance [33] | ||
| Long-term sustainability and development | Flexibility in allowing additional fields if there are new diagnostic methods | |
| Architecture allowing adding new data sources | ||
| Low-maintenance technology and architecture |