ABSTRACT
Objective: Limited capacities and ineffective care pathways result in long waiting times for patients and sporadic treatment controls in sleep medicine. As one objective of the 'Telesleep Medicine' project, a portal should be developed, which supports sleep specialists in an efficient and resource-saving patient management. On account of the limited project timeframe, the 'classical' user-centred design and evaluation methods could not be comprehensively implemented. Therefore, a pragmatic methodical framework was developed. Methods: For the iterative development of the portal, a combination of low-cost and quick-to-implement methods was used. In chronological order, these were: context interviews, personas, the development of an as-is model, a web search of design standards and good design aspects of similar systems, the development of a to-be model, the creation of an overarching mind map, and the iterative creation of mockups with simplified usability walkthroughs. Results: The feasibility of the pragmatic methodological framework for the development of a prototype for the portal was demonstrated. The used method combination resulted in a prototype based on the needs and requirements of the sleep specialists, taking into account their specific workflow and the technical implementation conditions. Conclusions: The presented pragmatic methodological framework can be a valuable resource for developers of comparable projects. The combination of methods worked well together regarding the limited timeframe and resources for concept development. For the future, we plan to implement and test the portal in the clinical field and thus enrich our framework with additional methods.
ABSTRACT
Enabling interoperability is a challenging task in medical data exchange and is often addressed by the use of versatile communication standards like HL7 FHIR. Although daily routine and scientific experiences show its suitability, the use comes with major risks regarding safety and security of data. To overcome these problems, we present an approach to enable a formal verification of medical communication use cases. We identified the Neonatal Screening as a practical example in which two process participants (physician and screening laboratory) are involved. We analyzed the FHIR specification as well as identified necessary resources in that context and formally modeled them as algebraic specifications. By that, we were able to represent the participants' behavior and data flow with help of Algebraic Petri Nets. This strategy allows to formally verify the correctness of a system by specified requirements regarding data safety and data security.
Subject(s)
Health Resources , Electronic Health Records , Humans , Infant, NewbornABSTRACT
Clinical care and research data are widely dispersed in isolated systems based on heterogeneous data models. Biomedicine predominantly makes use of connected datasets based on the Semantic Web paradigm. Initiatives like Bio2RDF created Resource Description Framework (RDF) versions of Omics resources, enabling sophisticated Linked Data applications. In contrast, electronic healthcare records (EHR) data are generated and processed in diverse clinical subsystems within hospital information systems (HIS). Usually, each of them utilizes a relational database system with a different proprietary schema. Semantic integration and access to the data is hardly possible. This paper describes ways of using Ontology Based Data Access (OBDA) for bridging the semantic gap between existing raw data and user-oriented views supported by ontology-based queries. Based on mappings between entities of data schemas and ontologies data can be made available as materialized or virtualized RDF triples ready for querying and processing. Our experiments based on CentraXX for biobank and study management demonstrate the advantages of abstracting away from low level details and semantic mediation. Furthermore, it becomes clear that using a professional platform for Linked Data applications is recommended due to the inherent complexity, the inconvenience to confront end users with SPARQL, and scalability and performance issues.
